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

Thu Jun 1 16:24:31 UTC 2023

this sounds like a useful exploration of "CLA configuration requirements"
(or recommendations?)

v

On Thu, Jun 1, 2023 at 12:12 PM Sipos, Brian J. <Brian.Sipos at jhuapl.edu>
wrote:

> Bob,
>
> There was a small survey last year to try to harmonize understanding of
> different aspects and interfaces of CLAs. Section 2 of a draft document [1]
> describes different aspects of a CL, as provided by a CLA, that would
> inform how a BPA chooses to utilize each CL available to it. The draft has
> since expired, but if it seems like there is value here and if there is any
> feedback it can be revived and continued to be edited.
>
>
>
> A couple things not mentioned in that section are the notation that a CL
> has an envelope of aspects that can be further restricted by an actual CLA
> use (e.g. the UDPCL may support up to 65k size but *my implementation* or *my
> network* limits to something smaller), and similar discussion of security
> aspects of CLs.
>
>
>
> It would also be interesting to get feedback from some of the terminology
> and API unifying between different BPA implementations that has been
> happening by Josh and others.
>
>
>
> [1]
> https://www.ietf.org/archive/id/draft-sipos-dtn-bpv7-cla-services-00.html#section-2
>
>
>
> *From:* Robert C Durst <durst at mitre.org>
> *Sent:* Wednesday, May 31, 2023 1:54 PM
> *To:* sburleig.sb at gmail.com; Cerf, Vinton <vint at google.com>
> *Cc:* Sipos, Brian J. <Brian.Sipos at jhuapl.edu>; 'Sanchez Net, Marc (US
> 332H)' <marc.sanchez.net at jpl.nasa.gov>; Jeremy.Mayer at dlr.de; 'Torgerson,
> J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov>;
> Felix.Flentge at esa.int; keithlscott at gmail.com; sis-dtn at mailman.ccsds.org
> *Subject:* [EXT] RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP
> Corrigendum
>
>
>
> Thanks, Scott!
>
>
>
> Indeed, fragmentation and reassembly are (and have always been)
> challenging, sometimes necessary, and the source of many bad words.
>
>
>
> For the near-ish term future, it’s reasonable to assume that BPAs know or
> can be informed of the limitations of the CLAs in the system.  And still,
> design matters.  These two excerpts from RFC 7122 are relevant, and perhaps
> the RID response should point to this section of RFC7122:
>
>
>
> 3.1. How and Where to Deal with Fragmentation
>
>
>
> The Bundle Protocol allows bundles with sizes limited only by node
>
> resource constraints. In IPv4, the maximum size of a UDP datagram is
>
> nearly 64 KB. In IPv6, when using jumbograms [RFC2675], UDP
>
> datagrams can technically be up to 4 GB in size [RFC2147], although
>
> this option is rarely used. (Note: RFC 2147 was obsoleted by RFC
>
> 2675.) It is well understood that sending large IP datagrams that
>
> must be fragmented by the network has enormous efficiency penalties
>
> [Kent87]. The Bundle Protocol specification provides a bundle
>
> fragmentation concept [RFC5050] that allows a large bundle to be
>
> divided into bundle fragments. If the Bundle Protocol is being
>
> encapsulated in DCCP or UDP, it therefore SHOULD create each fragment
>
> of sufficiently small size that it can then be encapsulated into a
>
> datagram that will not need to be fragmented at the IP layer.
>
>
>
> IP fragmentation can be avoided by using IP Path MTU Discovery
>
> [RFC1191] [RFC1981], which depends on the deterministic delivery of
>
> ICMP Packet Too Big (PTB) messages from routers in the network. To
>
> bypass a condition referred to as a black hole [RFC2923], a newer
>
> specification is available in [RFC4821] to determine the IP Path MTU
>
> without the use of PTB messages. This document does not attempt to
>
> recommend one fragmentation avoidance mechanism over another; the
>
> information in this section is included for the benefit of
>
> implementers.
>
>
>
> And
>
>
>
> 3.1.2. UDP
>
>
>
> When an LTP CL is using UDP for datagram delivery, it SHOULD NOT
>
> create segments that will result in UDP datagrams that will need to
>
> be fragmented, as discussed above.
>
>
>
> 3.2. Bundle Protocol over a Datagram Convergence Layer
>
>
>
> In general, the use of the Bundle Protocol over a datagram CL is
>
> discouraged in IP networks. Bundles can be of (almost) arbitrary
>
> length, and the Bundle Protocol does not include an effective
>
> retransmission mechanism. Whenever possible, the Bundle Protocol
>
> SHOULD be operated over the TCP Convergence Layer or over LTP.
>
>
>
> Best,
>
> Bob
>
>
>
>
>
> *From:* sburleig.sb at gmail.com <sburleig.sb at gmail.com>
> *Sent:* Wednesday, May 31, 2023 1:35 PM
> *To:* Cerf, Vinton <vint at google.com>; Robert C Durst <durst at mitre.org>
> *Cc:* 'Sipos, Brian J.' <Brian.Sipos at jhuapl.edu>; 'Sanchez Net, Marc (US
> 332H)' <marc.sanchez.net at jpl.nasa.gov>; Jeremy.Mayer at dlr.de; 'Torgerson,
> J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov>;
> Felix.Flentge at esa.int; keithlscott at gmail.com; sis-dtn at mailman.ccsds.org
> *Subject:* RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum
>
>
>
> The convergence layer adapter is expected (7.2 of RFC 9171) to notify the
> BPA when it fails to forward the bundle, for whatever reason; among those
> reasons might well be “bundle is too big for this CL protocol”.  Depending
> on implementation, the BPA might respond to this notice by fragmenting the
> bundle; ION currently does this for the UDP CLA.  But certainly another
> implementation expedient might be for the BPA to know in advance the
> limitations of all available CLAs and choose the CLA for a given bundle on
> that basis.
>
>
>
> Reassembly of a bundle from fragments, at the destination endpoint node,
> is certainly somewhat complicated.  But we discussed the alternatives at
> length, and what’s in the RFC is what we agreed on.  Reassembly of
> segmented LTP blocks and reassembly of fragmented IP packets is likewise
> complicated.  Ideally you always want this to be Somebody Else’s Problem.
>
>
>
> Scott
>
>
>
> *From:* Vint Cerf <vint at google.com>
> *Sent:* Wednesday, May 31, 2023 9:55 AM
> *To:* Robert C Durst <durst at mitre.org>
> *Cc:* Sipos, Brian J. <Brian.Sipos at jhuapl.edu>; Sanchez Net, Marc (US
> 332H) <marc.sanchez.net at jpl.nasa.gov>; Jeremy.Mayer at dlr.de;
> sburleig.sb at gmail.com; Torgerson, J. Leigh (US 332C) <
> jordan.l.torgerson at jpl.nasa.gov>; Felix.Flentge at esa.int;
> keithlscott at gmail.com; sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum
>
>
>
> briefly, fragmentation, re-transmission, alternative convergence layers
> can result in non-uniform and overlapping receipt of fragmented bundles.
> That can make for a pretty messy reassembly at bundle layer. Of course,
> alternative routing through different CLAs can also result in partially
> reassembled bundles or bundle fragments at the receiving end of a CLA.
> We've encountered a lot of that in the Internet in its various
> incarnations.
>
>
>
> Is is a good assumption that the bundle maker layer knows about
> limitations of the CLA with regard to maximum bundle size to avoid
> fragmentation?
>
>
>
> v
>
>
>
>
>
> On Wed, May 31, 2023 at 12:39 PM Robert C Durst via SIS-DTN <
> sis-dtn at mailman.ccsds.org> wrote:
>
> Folks, on a note that’s somewhat related to Brian’s message below, so far
> I’ve received precisely one Agency RID on BPv7, which is attached, FYI.  It
> deals with the BPv7 Minimum Supported Bundle Size (sec 3.6):
>
>
>
> *3.6 MINIMUM SUPPORTED BUNDLE SIZE*
>
>
>
> Conformant CCSDS implementations shall be able to forward and/or deliver
> bundles whose total size, including all extension blocks, is less than or
> equal to 10*220 bytes (10 MB).
>
> NOTE - Disposition of larger bundles is implementation-specific.
>
>
>
> The RID says:
>
>
>
> “Add details that show considerations for minimum size have been
> considered for network implementation.
>
> The Note that disposition of larger bundles is implementation-specific
> needs to be augmented to show that
>
> the impacts of this large bundle size have been considered for the various
> ways that networks could meet
>
> this requirement with the convergence layers.  It’s difficult to
> understand how an UDP or SPP Convergence-Layer
>
> would satisfy this requirement.  It would be helpful to provide examples
> based on the CLAs specified in this document.”
>
>
>
> In Normative Annex B, we specify 5 CLAs, and assert that a compliant BP
> implementation shall implement at least one of them.  As a result, a
> compliant implementation need implement *no more* than one of them.  By
> implication, since any of the CLAs specified might be the *only* CLA
> available, the requirement from Section 3.6 must be able to be met by any
> of the CLAs.
>
>
>
> B2.1.2:  TCP CL – stream-oriented CL; no inherent limitations on Bundle
> Size.
>
>
>
> B2.1.3:  UDP CL – Note on B2.1.3.2 says “It is desirable that BP agents
> endeavor to send bundles of such a size as not to require fragmentation by
> the IP (Internet Protocol) layer. In practice this generally means keeping
> the size of the IP datagram (including the IP and UDP headers, plus the
> bundle) to no more than 1500 bytes.”
>
> Probably not the answer he wants, particularly in the context of a 10MB
> bundle.  How does a UDP CL meet the requirement specified in 3.6?  If the
> UDP CL **cannot** meet the requirement specified in 3.6, how should we
> proceed?  Must the Bundle be fragmented into some number of fragmentary
> bundles that fit into a sequence of 150+ 65507-byte UDP payloads (or 6700+
> 1472-byte UDP payloads)?
>
>
>
> B2.1.4:  LTP CL – is there a length limitation on LTP ADUs (Blocks)? I
> didn’t see one in the RFC or the Blue Book
>
>
>
> B2.1.5:   SPP – B2.1.5.1 notes that the maximum size of a bundle is <=
> 65535.  Is Bundle fragmentation therefore the only way to accommodate the
> requirement of section 3.6?
>
>
>
> B2.1.6:  EPP – 4GB MTU meets the section 3.6 requirement.
>
>
>
> So, for TCP, LTP, and EPP there’s no issue with the requirement in 3.6.
> For UDP and SPP, is Bundle Fragmentation the only feasible approach?
>
>
>
> RFC 9171 section 5.9 permits in-transit reassembly (“an ADU also be
> reassembled at some other node on the path to the destination.”).  The
> motivator for that might be to remove redundant bundle headers in order to
> reduce overhead before forwarding a large bundle over a (potentially
> not-yet-available) constrained link.
>
>
>
> Is it the sense of this group that this is correct?  Would an appropriate
> response to the RID be to add to the note on 3.6 a sentence to the effect
> of the following:  “…is implementation-specific.  For CLAs that have
> maximum size limits that are less than this 10MB requirement (e.g., UDP,
> B2.1.3 and SPP, B2.1.5), Bundle Fragmentation and Reassembly (refer to RFC
> 9171 sections 5.8 and 5.9) are available to mitigate the limitation.”
>
>
>
> Any sense of the reaction to this not-so-satisfying response?
>
>
>
> Thanks,
> Bob
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Sipos,
> Brian J. via SIS-DTN
> *Sent:* Wednesday, May 31, 2023 11:04 AM
> *To:* Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov>;
> Jeremy.Mayer at dlr.de; sburleig.sb at gmail.com; Torgerson, J. Leigh (US 332C)
> <jordan.l.torgerson at jpl.nasa.gov>; Felix.Flentge at esa.int;
> keithlscott at gmail.com
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum
>
>
>
> Marc, for my own purposes the one reason for using unreliable LTP is to
> take advantage of the segmentation of larger-than-MTU blocks. It’s a useful
> thing on its own separate from other capabilities of LTP. Similar to some
> of these other recommendations, it would be helpful for implementations to
> know “if you are able to choose block sizes then here is a recommendation …
> Otherwise if you are using green block segmentation then here are some
> considerations (about timing and resource leaks) …”
>
>
>
> I think it’s better for an designer/implementer to be aware of potential
> issues and head them off than to try to ignore or impose restrictions on
> the service which would prohibit existing use cases.
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Sanchez
> Net, Marc (US 332H) via SIS-DTN
> *Sent:* Wednesday, May 31, 2023 8:55 AM
> *To:* Jeremy.Mayer at dlr.de; sburleig.sb at gmail.com; Torgerson, J. Leigh (US
> 332C) <jordan.l.torgerson at jpl.nasa.gov>; Felix.Flentge at esa.int;
> sis-dtn at mailman.ccsds.org; keithlscott at gmail.com
> *Subject:* [EXT] Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP
> Corrigendum
>
>
>
> *APL external email warning: *Verify sender
> sis-dtn-bounces at mailman.ccsds.org before clicking links or attachments
>
>
>
> I am unconvinced either way, to be honest. I agree with Jeremy forcing the
> LTP engine to know the contact plan is not great, but having another “stale
> session timeout” seems an equally non-ideal solution. Would all these
> problems “go away” if we force in the spec that a green block always be
> transmitted as a single green segment? But then the block size must be
> matched to the underlying link MTU (or transmission size used by the
> mission) which is <=65 kB for transfer frames, I believe. Would that be too
> restrictive if we sent streaming video over LTP green?
>
>
>
>
> -----------------------------------------------------------------------------------------------------------------------
>
> Marc Sanchez Net (332H)
>
> Telecommunications Engineer
>
> Jet Propulsion Laboratory
>
> Cell: (617) 953-7977 | Email: marc.sanchez.net at jpl.nasa.gov
>
>
> -----------------------------------------------------------------------------------------------------------------------
>
>
>
> *From:* Jeremy.Mayer at dlr.de <Jeremy.Mayer at dlr.de>
> *Sent:* Wednesday, May 31, 2023 1:05 AM
> *To:* sburleig.sb at gmail.com; Sanchez Net, Marc (US 332H) <
> marc.sanchez.net at jpl.nasa.gov>; Torgerson, J. Leigh (US 332C) <
> jordan.l.torgerson at jpl.nasa.gov>; Felix.Flentge at esa.int;
> sis-dtn at mailman.ccsds.org; keithlscott at gmail.com
> *Subject:* RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum
>
>
>
> Hi,
>
> Realistically, I agree, the LTP engine should probably be aware of either
> the contact plan OR the status of the downlink. That being said, I don’t
> think that’s a dependency which we want to force, due to the “perpetual
> downlink” use-case (ISS). There’s nothing stopping me from running a single
> LTP link from now until the end of time, unaware of the status of the
> underlying link. Of course, there’s the caveat that green sessions may be
> transmitted into the void, never to be seen again.
>
>
>
> That being said, the “last green block” problem is insidious: In a nominal
> downlink (e.g. with minimal out-of-order arrival and loss), we can use the
> EOB as a signal that the block should be delivered. However, if the EOB is
> out-of-order, there’s a problem: the application shouldn’t have to expect
> that data from the same session may arrive twice. The only way to really
> deal with this in the face of out-of-order/missing arrivals is to track the
> completeness of a green session. If the EOB block is delivered while data
> is still missing, we ignore it and “hold” the session until a
> user-specified timeout. In LTPv2, we called this the “stale session
> timeout”. If more data is delivered into one of these pending sessions, it
> can still be enqueued and delivered upon timeout. This allows us to treat
> out of order sessions and those where the EOB is missed in the same way.
>
>
>
> Thanks,
>
> Jeremy
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *sburleig.sb---
> via SIS-DTN
> *Sent:* Tuesday, May 30, 2023 11:55 PM
> *To:* 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net at jpl.nasa.gov>;
> 'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov>; 'Felix
> Flentge' <Felix.Flentge at esa.int>; 'Dr. Keith L Scott via SIS-DTN' <
> sis-dtn at mailman.ccsds.org>; keithlscott at gmail.com
> *Subject:* Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum
>
>
>
> Marc, good question.  My thought on this is that LTP needs to be aware of
> the “contact plan” in order to know when to pause and resume the “red”
> timers.  Given this, the LTP engine should be able to infer that cessation
> of green block segment reception is due to the termination of the pass.  At
> that point we have a matter of policy.  If it’s known that green block
> transmission is always supposed to happen far enough before the end of the
> pass to enable complete reception, then the end of the pass signifies that
> any currently incomplete block is not going to be completed and the block’s
> current incomplete contents can be delivered.  If not, then maybe the
> current state of that incomplete final block should be sustained until the
> start of the next pass enables further reception of that block’s segments.
>
>
>
> Of course, sticking to small green blocks that are transmitted in single
> green segments makes the whole issue go away.
>
>
>
> Scott
>
>
>
> *From:* Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov>
> *Sent:* Tuesday, May 30, 2023 1:18 PM
> *To:* sburleig.sb at gmail.com; Torgerson, J. Leigh (US 332C) <
> jordan.l.torgerson at jpl.nasa.gov>; 'Felix Flentge' <Felix.Flentge at esa.int>;
> '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
>
>
>
> 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: (617) 953-7977 | Email: marc.sanchez.net at jpl.nasa.gov
>
>
> -----------------------------------------------------------------------------------------------------------------------
>
>
>
> *From:* 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>;
> 'Felix Flentge' <Felix.Flentge at esa.int>; 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>
> *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
>
>
>
> 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>
> *Sent:* Tuesday, May 30, 2023 7:54 AM
> *To:* Felix Flentge <Felix.Flentge at esa.int>; sburleig.sb at gmail.com;
> 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>
> *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
>
>
>
> 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>
> *Date: *Monday, May 29, 2023 at 11:47 PM
> *To: *"Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov>, "
> sburleig.sb at gmail.com" <sburleig.sb at gmail.com>, "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>
> *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
>
>
>
> 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>
> *Sent:* Thursday, May 25, 2023 6:22 PM
> *To:* Felix Flentge <Felix.Flentge at esa.int>; sburleig.sb at gmail.com;
> 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>
> *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
>
>
>
> 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>
> *Date: *Thursday, May 25, 2023 at 4:56 AM
> *To: *"sburleig.sb at gmail.com" <sburleig.sb at gmail.com>, "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>
> *Cc: *"Torgerson, Jordan L (332M)" <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> *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>; 'Dr.
> Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org>
> *Cc:* 'Torgerson, J. Leigh (US 332C)' <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> *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>
> *Cc:* Torgerson, J. Leigh (US 332C) <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__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$> and
> here
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_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?
>
>
>
> Defer data retransmission with out-of-order report segments · Issue #24 ·
> nasa/HDTN
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> 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...
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> github.com
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Defer synchronous reception report with out-of-order data segments · Issue
> #22 · nasa/HDTN
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> 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 ...
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> github.com
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
>
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Thanks,
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
>
> -----------------------------------------------------------------------------------------------------------------------
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Marc Sanchez Net (332H)
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Telecommunications Engineer
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Jet Propulsion Laboratory
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Cell: (617) 953-7977 | Email: marc.sanchez.net at jpl.nasa.gov
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
>
> -----------------------------------------------------------------------------------------------------------------------
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
>
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> 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).
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> 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).
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
>
>
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> --
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Please send any postal/overnight deliveries to:
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Vint Cerf
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Google, LLC
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> 1900 Reston Metro Plaza, 16th Floor
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> Reston, VA 20190
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> +1 (571) 213 1346
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>
> until further notice
> <https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230601/81554e21/attachment-0001.htm>