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

Thu Jun 22 13:02:37 UTC 2023

I thought we'd finalized this. As I understand it, removal of a feature is
a change that would trigger at least agency review if not interoperability
tests.  I think we'll be much better to stick to noon-normative changes.

Think of the folks who've already implemented ltpv1 for refps or other
commercial purposes. If we change the spec then all of a sudden they're
non-compliant.

  - keith

On Thu, Jun 22, 2023, 10:49 AM Felix Flentge <Felix.Flentge at esa.int> wrote:

> 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> *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>;
> 'Keith Scott' <keithlscott at gmail.com>; 'Tomaso de Cola' <
> Tomaso.deCola at dlr.de>
> *Cc:* 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>
> *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: (617) 953-7977 <(617)%20953-7977> | Email:
> marc.sanchez.net at jpl.nasa.gov
>
>
> -----------------------------------------------------------------------------------------------------------------------
>
>
>
> *From:* SIS-DTN <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>; 'Tomaso de Cola' <
> Tomaso.deCola at dlr.de>
> *Cc:* 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> *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>
> *Cc:* 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> 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> *Im Auftrag von *Keith
> Scott via SIS-DTN
> *Gesendet:* Dienstag, 20. Juni 2023 18:35
> *An:* 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230622/5bc1049b/attachment-0001.htm>