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

Thu Jun 22 11:42:05 UTC 2023

Yes, but the only concern I have is that removing the SDA feature currently appearing in Section 7.2 will have also an impact on the PICS section that shows SDA as mandatory currently. As such I'm afraid that it won't just be a corrigendum but really a pink sheet. According to the CCSDS yellow book about the processes, a corrigendum is about minor technical changes, whatever it may mean. I can check again with Tom what are the boundaries of "minor technical changes" just not to waste too much time.

Regards,

Tomaso

Von: Felix Flentge <Felix.Flentge at esa.int>
Gesendet: Donnerstag, 22. Juni 2023 10:50
An: sburleig.sb at gmail.com; 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net at jpl.nasa.gov>; 'Keith Scott' <keithlscott at gmail.com>; de Cola, Tomaso <Tomaso.deCola at dlr.de>
Cc: sis-dtn at mailman.ccsds.org
Betreff: RE: [Sis-dtn] [EXTERNAL] Re: Updates on LTPv2 Corrigendum and BPv7 RID database

We may be back to the discussion what happens if we remove a feature. IMHO, the clean solution would be to remove the SDA from current LTP because it is not sufficient to specify an interoperable mechanism (furthermore, I believe the design that LTP SDA needs to know something about the different types of service data which may be aggregated is not a good one). We can also argue that for BPv7 there is no problem and that the BPv7 BB will specify aggregation of bundles in LTP (and updated CFDP magenta book will do as well). Existing implementations will remain fully LTP compliant it is just that using BP(v6) / LTPCL may be viewed as BP(v6) / SDACL / LTP with a not-standardised SDACL.

Regards,
Felix

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 9:18 PM
To: 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>; '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: Re: [Sis-dtn] [EXTERNAL] Re: Updates on LTPv2 Corrigendum and BPv7 RID database

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<mailto:marc.sanchez.net at jpl.nasa.gov>>
Sent: Wednesday, June 21, 2023 12:05 PM
To: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; '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: 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: (617) 953-7977<mailto:(617)%20953-7977> | Email: marc.sanchez.net at jpl.nasa.gov<mailto: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}&file=Draft%20LTP%20corrigendum%20-%20JPL%20edits%20(1).docx&action=default<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$>)
*       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

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230622/50ff2713/attachment-0001.htm>