[Sis-dtn] [EXTERNAL] Re: Updates on LTPv2 Corrigendum and BPv7 RID database

Wed Jun 21 19:17:48 UTC 2023

No, the issue is not the block size; that’s clearly defined in the specification.  The issue is being able to determine the lengths of all the individual client data units that are aggregated in the block.

That is easily determined if the client is BP, because each bundle’s size is self-identifying.  But suppose the client is Email?  How does the LTP engine that receives this LTP block figure out where one of the aggregated emails ends and the next one begins?  That method must be defined somewhere, and the receiving engine can use the client ID – once it is registered with SANA – to look up the parsing method.  But that’s beyond the scope of this specification.

What Felix is suggesting is, more or less, that each client data unit in the block could be preceded by a 32-bit unsigned integer giving the length of that client data unit, regardless of client ID.  This would be a general mechanism, imposing some additional overhead cost, which is NOT included in the LTP spec.  We need not talk about it.

Scott

From: Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov> 
Sent: Wednesday, June 21, 2023 12:05 PM
To: sburleig.sb at gmail.com; 'Keith Scott' <keithlscott at gmail.com>; 'Tomaso de Cola' <Tomaso.deCola at dlr.de>
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database

Looking at table C-1, it seems that there are two parameters related to SDA aggregation, size and time. If I understand this correctly, the problem with the current spec only applies when the LTP block is released because the SDA Aggregation timer expires (if the size limit is reached, then no problem, the size of the block is already specified in Table C-1 and thus is a managed parameters known to the receiver). Is that the correct interpretation? If so, I am not sure we can simply say “that the information needed to delimit the aggregated data units in the SDA structure is beyond the scope of the specification” because it is at least partially already in the specification MIB.

Maybe the solution is to add a note in 7.2.3.4.1.3 saying that implementations may find it useful to pad all LTP blocks released due to time limit reached with enough zeros to complete the LTP block size as specified in Table C-1? But does that really solve the problem? How will the rx know when data ends and padding zeroes start…

-----------------------------------------------------------------------------------------------------------------------

Marc Sanchez Net (332H)

Telecommunications Engineer

Jet Propulsion Laboratory

Cell:  <mailto:(617)%20953-7977> (617) 953-7977 | Email:  <mailto:marc.sanchez.net at jpl.nasa.gov> marc.sanchez.net at jpl.nasa.gov

-----------------------------------------------------------------------------------------------------------------------

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org <mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of sburleig.sb--- via SIS-DTN
Sent: Wednesday, June 21, 2023 7:08 AM
To: 'Keith Scott' <keithlscott at gmail.com <mailto:keithlscott at gmail.com> >; 'Tomaso de Cola' <Tomaso.deCola at dlr.de <mailto:Tomaso.deCola at dlr.de> >
Cc: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> 
Subject: [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database

Right, I think it’s not that the specification is not interoperable, only that the nature of the client data units – including the information needed to delimit the aggregated data units in the SDA structure – is identified by the client ID; that registration is beyond the scope of the specification.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org <mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of Keith Scott via SIS-DTN
Sent: Wednesday, June 21, 2023 2:36 AM
To: Tomaso de Cola <Tomaso.deCola at dlr.de <mailto:Tomaso.deCola at dlr.de> >
Cc: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> 
Subject: Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database

Mmmm.... will try to find the right words. 

  -keith

On Wed, Jun 21, 2023, 10:48 AM <Tomaso.deCola at dlr.de <mailto:Tomaso.deCola at dlr.de> > wrote:

Hi Keith,

Thank you for the summarized discussion on LTP-corrigendum. 

Just one consideration about SDA aggregation (point 7 in the list). The description seems to point about the fact that the current specification of the mechanism does not allow interoperability because of the lack of information of the client data unit, which is I think agreed and well understood. I’d however try to find a “smarter” way to say this, since having a specification which has a non-interoperable feature will not be accepted by CESG and this will cause endless iterations and discussions there before getting the green light.

Regards,

Tomaso

Von: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org <mailto:sis-dtn-bounces at mailman.ccsds.org> > Im Auftrag von Keith Scott via SIS-DTN
Gesendet: Dienstag, 20. Juni 2023 18:35
An: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> 
Betreff: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database

LTP Corrigendum (from the telecon last Thursday):

*	Discussed the latest JPL collection of issues here (https://cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc={A52D5D6D-7A66-4CCD-AB61-B215AA2B8C36} <https://urldefense.us/v3/__https:/cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc=*7bA52D5D6D-7A66-4CCD-AB61-B215AA2B8C36*7d&file=Draft*20LTP*20corrigendum*20-*20JPL*20edits*20(1).docx&action=default__;JSUlJSUlJSU!!PvBDto6Hs4WbVuu7!LCeuTfHRA-LEWR-KvEDLe0i6i_hNmJSv6s71tkiKsE8GF9G2WuONw5VgyJ3VhoHWAzOx4uoYfTZbeHQbcqsxLE9Ue77kmlg$> &file=Draft%20LTP%20corrigendum%20-%20JPL%20edits%20(1).docx&action=default)
*	We definitely want a CORRIGENDUM (non-normative, no changes to the protocol) NOT a set of Pink sheets or a Pink Book (which would/could be normative and would require agency review).  So, all proposed text should be in the form of non-normative suggestions to implementers.
*	We discussed putting all of the proposed changes into a single location or spreading them throughout the document.  The consensus was that it would be better for implementers to put the suggestions proximate to the places in the document that discuss the protocol mechanisms (i.e. mixed throughout).  Should ask Tom what he thinks of this...
*	Blue text in the document reflects the WG consensus on the telecon; we agreed that folks would propose final "copy-ready" text in green together with the location where that text should go.

Added the CNES RIDs to the spreadsheet.

    --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230621/92b735bf/attachment-0001.htm>