[Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum

Thu Jun 1 15:42:41 UTC 2023

Ah, good point.  Thanks, Felix, this makes plenty of sense; no problem if
every client data unit is a bundle, but of course the spec does not require
this.

Scott

From: Felix Flentge <Felix.Flentge at esa.int> 
Sent: Thursday, June 1, 2023 8:26 AM
To: sburleig.sb at gmail.com; 'Torgerson, J. Leigh (US 332C)'
<jordan.l.torgerson at jpl.nasa.gov>; 'Sanchez Net, Marc (US 332H)'
<marc.sanchez.net at jpl.nasa.gov>; 'Dr. Keith L Scott via SIS-DTN'
<sis-dtn at mailman.ccsds.org>; keithlscott at gmail.com
Cc: 'Gao, Jay L (US 332C)' <jay.l.gao at jpl.nasa.gov>; 'Richard, Nate J (US
332C)' <nathaniel.j.richard at jpl.nasa.gov>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

No,

The issue is that there is no generic way to determine the length of an SDA
client data capsule (or I am overlooking something).

Of course, it works for a lot of specific client data units if the client
data units themselves allow to determine the lengths (as it is the case for
bundles) and the receiver knows the format of each client data.

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>
<sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: Thursday, June 1, 2023 5:18 PM
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >;
'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >; 'Sanchez Net, Marc (US 332H)'
<marc.sanchez.net at jpl.nasa.gov <mailto:marc.sanchez.net at jpl.nasa.gov> >;
'Dr. Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >; keithlscott at gmail.com
<mailto:keithlscott at gmail.com> 
Cc: 'Gao, Jay L (US 332C)' <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; 'Richard, Nate J (US 332C)'
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Felix, I am neutral on the utility of service data aggregation, but can you
say a little bit about what makes it non-interoperable?  It's formally
defined in the current LTP blue book, in normative language (7.2), right?
Are you just saying that existing implementations of LTP don't all implement
this element of the specification and therefore do not interoperate?

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Thursday, June 1, 2023 7:38 AM
To: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >; Sanchez Net, Marc (US 332H)
<marc.sanchez.net at jpl.nasa.gov <mailto:marc.sanchez.net at jpl.nasa.gov> >;
sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Dr. Keith L Scott
via SIS-DTN' <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>
>; keithlscott at gmail.com <mailto:keithlscott at gmail.com> 
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; Richard, Nate J (US 332C)
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

I think the point is that Service Data Aggregation is that it is
not-interoperable. As such it should not be used (at least in
interoperability scenarios). We don't need to hint at the new protocol. [I
would think that this is a true corrigendum].

Regards,

Felix

From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> > 
Sent: Wednesday, May 31, 2023 6:01 PM
To: Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov
<mailto:marc.sanchez.net at jpl.nasa.gov> >; sburleig.sb at gmail.com
<mailto:sburleig.sb at gmail.com> ; Felix Flentge <Felix.Flentge at esa.int
<mailto:Felix.Flentge at esa.int> >; 'Dr. Keith L Scott via SIS-DTN'
<sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >;
keithlscott at gmail.com <mailto:keithlscott at gmail.com> 
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; Richard, Nate J (US 332C)
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Looks OK but at the end it says "service IDs are agreed. It is expected that
Service Data Aggregation will be removed from LTPv2 and that eventual
aggregation shall be performed by upper layers if deemed necessary."

If the fpga/asic version isn't going to be called LTP2, this will have to be
revised.

Leigh

From: "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov
<mailto:marc.sanchez.net at jpl.nasa.gov> >
Date: Tuesday, May 30, 2023 at 1:18 PM
To: "sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> "
<sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> >, "Torgerson, Jordan
L (332M)" <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >, 'Felix Flentge'
<Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >, "'Dr. Keith L Scott
via SIS-DTN'" <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>
>, "keithlscott at gmail.com <mailto:keithlscott at gmail.com> "
<keithlscott at gmail.com <mailto:keithlscott at gmail.com> >
Cc: "Gao, Jay L (US 332C)" <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >, "Richard, Nate J (US 332C)"
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

All,

A quick update to the draft LTP corrigendum with a few more items to make
sure some of the issues being brought up in this email chain don't fall
through the cracks. 

Also, a minor note on Scott's comment that "the arrival of the first segment
of the next "green" block is a simpler and perhaps more accurate
(configuration-free) means of determining that it is time to deliver the
current block": How does the receiving LTP engine handle the very last LTP
block of a pass? Without a timer, would it ever be released to the
application? I hate to add new timers, but I do not see how to get around it
in this this corner case.

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

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: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>
<sburleig.sb at gmail.com> 
Sent: Tuesday, May 30, 2023 8:13 AM
To: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >; 'Felix Flentge'
<Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; Sanchez Net, Marc
(US 332H) <marc.sanchez.net at jpl.nasa.gov
<mailto:marc.sanchez.net at jpl.nasa.gov> >; 'Dr. Keith L Scott via SIS-DTN'
<sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; Richard, Nate J (US 332C)
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Guys, a thought on this.

In "red" transmission you expect out-of-order segment arrival on a routine
basis, because every retransmitted bundle will arrive out of order.  There
are timers in the protocol to support the operation of the retransmission
procedures.

In "green" transmission you cannot have out-of-order segment arrival if you
size your blocks in such a way that each block is transmitted in a single
segment.  I believe users will typically adopt this model, as "green" data
will normally be data for which minimized delay is more important than
reliability (otherwise they would use "red" transmission).

In "green" transmission where the blocks are large enough to require
transmission in multiple segments you have to wait for an entire block to
arrive - or until you are confident that any missing segments were actually
lost rather than simply forwarded out of order - before delivering the
contents of the block.  But there's no re-transmission to avoid, because the
transmission is "green", right?  If you wanted retransmission you would have
used "red".

So in that event I would suggest that the arrival of the first segment of
the next "green" block is a simpler and perhaps more accurate
(configuration-free) means of determining that it is time to deliver the
current block - complete or incomplete - and let the application figure out
what to do about the missing data.

Scott

From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> > 
Sent: Tuesday, May 30, 2023 7:54 AM
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >;
sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; Sanchez Net, Marc (US
332H) <marc.sanchez.net at jpl.nasa.gov <mailto:marc.sanchez.net at jpl.nasa.gov>
>; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; Richard, Nate J (US 332C)
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Thanks Felix - 

Agreed - A statement warning about how implementations should be wary of
out-of-order deliveries would be useful in the corrigendum..

regards,

Leigh

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Date: Monday, May 29, 2023 at 11:47 PM
To: "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >, "sburleig.sb at gmail.com
<mailto:sburleig.sb at gmail.com> " <sburleig.sb at gmail.com
<mailto:sburleig.sb at gmail.com> >, "Sanchez Net, Marc (US 332H)"
<marc.sanchez.net at jpl.nasa.gov <mailto:marc.sanchez.net at jpl.nasa.gov> >,
"'Dr. Keith L Scott via SIS-DTN'" <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >
Cc: "Gao, Jay L (US 332C)" <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >, "Richard, Nate J (US 332C)"
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Hi Leigh,

Yes, we also have systematic out-of-order in EO or L2 missions as different
physical channels may be used (with maybe different rates and different PDU
sizes). With 'implementation issue' I don't mean that it is not important
but I would like to avoid making it normative as we want to avoid 'changing
the standard' which would require interop testing.

By any means, we should have a statement that in case you may have
out-of-order delivery it is recommended to implement timer to wait for
out-of-order segments to avoid re-transmission (we will add a similar
statement to CFDP for the next release).

Regards,

Felix

From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> > 
Sent: Thursday, May 25, 2023 6:22 PM
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >;
sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; Sanchez Net, Marc (US
332H) <marc.sanchez.net at jpl.nasa.gov <mailto:marc.sanchez.net at jpl.nasa.gov>
>; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov
<mailto:jay.l.gao at jpl.nasa.gov> >; Richard, Nate J (US 332C)
<nathaniel.j.richard at jpl.nasa.gov <mailto:nathaniel.j.richard at jpl.nasa.gov>
>
Subject: Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Thanks Felix - 

One comment is that in deep space use of DTN, we would expect that
out-of-order delivery would be the rule, rather than the exception - if it
takes 40 min RTT to recover a missing segment from Mars, waiting for it to
ensure in-order delivery to some application would make ops impossible. (One
must design one's applications to be "aware" of the operational environment
of course..)

We haven't used both LTP red/green at the same time in our testing and
real-world ops as far as I know, but I suspect that recommending that red
and green be in different sessions would be a good idea, if nothing else but
to make troubleshooting easier!  (Nate and Jay may have some thoughts based
on our lunar ops with KPLO so I cc:d them..)

regards

Leigh

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Date: Thursday, May 25, 2023 at 4:56 AM
To: "sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> "
<sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> >, "Sanchez Net, Marc
(US 332H)" <marc.sanchez.net at jpl.nasa.gov
<mailto:marc.sanchez.net at jpl.nasa.gov> >, "'Dr. Keith L Scott via SIS-DTN'"
<sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Cc: "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >
Subject: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Hi,

I agree with the modifications below.

Some additional points:

*         I would propose to also deprecate Service Data Aggregation (it is
currently mandatory). Unless, I am overlooking something, it is not an
interoperable mechanism as there is no generic way to determine the length
of a client data capsule. Also, for BP/LTP the updated BP standard will
describe an aggregation mechanism (CBOR length information + bundle IIRC).

*         Should we discourage use of mixed sessions (on the other hand LTP
green is optional anyway)?

*         For the two additional issues, we could add that this is an
implementation issue and that implementation may want to introduce these
additional timers in case they (routinely) expect out-of-order delivery

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: Thursday, May 18, 2023 1:23 AM
To: 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net at jpl.nasa.gov
<mailto:marc.sanchez.net at jpl.nasa.gov> >; 'Dr. Keith L Scott via SIS-DTN'
<sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Cc: 'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >
Subject: Re: [Sis-dtn] New version of LTP Corrigendum

Marc, FWIW, I agree about deprecating LTP security and I am likewise
skeptical that adding more timers is a good idea; that sounds like a way to
work around a design element that hasn't been thought through completely.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of Sanchez Net, Marc
(US 332H) via SIS-DTN
Sent: Tuesday, May 16, 2023 7:05 PM
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >
Cc: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov
<mailto:jordan.l.torgerson at jpl.nasa.gov> >
Subject: [Sis-dtn] New version of LTP Corrigendum

All,

Please find attached a new version of the LTP corrigendum with some
modifications including:

*         Comparison between LTP and "the new protocol" has been reduced.
This in part motivated by the fact that we have demonstrated ~4 Gbps rates
with ION's LTP implementation, which is more than sufficient for deep space
links (e.g., even in future trunk lines between Earth and Mars, data rates
of 4 Gbps are never exceeded).

*         I have added two possible additions to the technical corrigendum
based on work done by Brian and people at GRC. They are all optional (MAY)
statements and I believe can be implemented without additional managed
parameters (and timers).

*         Brian has commented on two additional issues (see here
<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$>  and here
<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$> ), but those seem to require
additional timers that would need to be managed, so I am unconvinced it is
worth the extra complexity. Brian, please correct me if I am wrong.

Finally, I think the note at the beginning of Section 3.9 of the current
CCSDS LTP spec should be modified to explicitly state that LTP security
should not be used and, instead, implementers should rely on security
mechanisms provided by other parts of the CCSDS protocol stack, be it SDLS
or BPSec. Thoughts on this point? 

<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$> 

<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$> Defer data retransmission with
out-of-order report segments . Issue #24 . nasa/HDTN

When the network is causing out-of-order segment reception it is possible
that one or more synchronous reception reports are received either
out-of-order or within a short time window, possibly fol...

github.com

<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$> 

<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto
6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_A
VxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$> Defer synchronous reception report
with out-of-order data segments . Issue #22 . nasa/HDTN

When red part data is segmented and delivered to the receiving engine
out-of-order, the checkpoint(s) and EORP can be received before the
earlier-in-block data segments. If a synchronous report is ...

github.com

Thanks,

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

Marc Sanchez Net (332H)

Telecommunications Engineer

Jet Propulsion Laboratory

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

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

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/20230601/f0d056bd/attachment-0001.htm>