[Sis-dtn] ION and in-order delivery

Sun Feb 18 17:42:08 UTC 2024

A very quick search yielded a couple studies that claim anything between 3
and 56 percent (yes, quite a range,  but I can't really review things right
now: in a car).

Remember also that many things we think of as Streaming (eg Netflix,
youtube) use tcp.

However. I think the points are:

1. IP can reorder packets
2. BP can reorder packets

As a consequence, applications should not assume that packets / bundles
will arrive in transmission order.

Another consequence of 2 is that even if YOUR network maintains fifo order,
somebody else's may not.

    Keith

On Fri, Feb 16, 2024, 10:05 PM <sburleig.sb at gmail.com> wrote:

> Right, that’s why I said “rare”.  That is, from what I’ve been hearing
> about streaming I’m guessing it’s relatively rare.
>
>
>
> Scott
>
>
>
> *From:* Keith Scott <keithlscott at gmail.com>
> *Sent:* Friday, February 16, 2024 9:08 AM
> *To:* sburleig.sb at gmail.com
> *Cc:* 구철회 <chkoo at kari.re.kr>; sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] ION and in-order delivery
>
>
>
> But IP will deliver things out of order, just for different reasons.
> Generally it's due to routing or link bonding or something like that.
>
>
>
>     --keith
>
>
>
>
>
> On Fri, Feb 16, 2024 at 3:25 PM <sburleig.sb at gmail.com> wrote:
>
> My sense is that this issue would never have come up if the implementation
> of bplib had not optimized for storage management by storing bundles in
> non-contiguous locations (as space became available) but clocking them out
> in ascending location order rather than in reception/storage time order.
>
>
>
> This is behavior that you’ll never see in IP because IP never stores
> packets at all, it simply forwards them immediately upon reception.  In
> this sense IP itself is non-delay-tolerant, i.e., it doesn’t compensate for
> unplanned lapses in connectivity by retaining data for transmission when
> connection is restored.  The mis-ordering of data will be routine in the
> bplib implementation of BP but (suitably) rare in any implementation of IP.
>
>
>
> We call BP a store-and-forward or store-carry-forward protocol, but there
> actually isn’t any language that I can find in RFC 9171 that requires that
> bundles be stored at all; we just assume that we all know it has to
> happen.  That’s an assumption that a developer picking up the specification
> might not share, so some sort of note pointing this out might be helpful.
>
>
>
> Scott
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Keith
> Scott via SIS-DTN
> *Sent:* Thursday, February 15, 2024 11:11 PM
> *To:* 구철회 <chkoo at kari.re.kr>
> *Cc:* sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] ION and in-order delivery
>
>
>
> Carlo: yeah, it's a very simple scenario; I took an existing test and
> plotted bundle sequence number against receive order.
>
>
>
> Cheol + Carlo: yes, I believe the misordering behavior is entirely allowed
> by the sentiment and letter of and specification.  The way I understand BP,
> the service provided by BP is similar to that provided by IP:
>
>   - Delivery of (bundles / datagrams) to the destination (name / address)
>
>
>
> In particular, in both BP and IP, (bundles / datagrams) may be lost,
> duplicated, delayed, and/or misordered during delivery.
>
>
>
>
>
> Context
>
> =======
>
> Sorry I didn't provide context for the first message.  We were discussing
> in the SIS-DTN telecon implementations that might want to impose a
> requirement along the lines of:
>
>
>
>     "All other things being equal, a bundle node should forward bundles in
> FIFO order."
>
>
>
> That's not a requirement in any of the BP specs, but in general it's
> probably beneficial to applications if things don't arrive too much out of
> order if they don't have to.  Really this stems from folks who want to be
> able to:
>
>     - In bpv6, set timers like custodial retransmission timers or timers
> associated with DTPC, etc.
>
>     - Do something intelligent with application-layer timers related to
> lost chunks of a stream
>
>
>
> I think the above guidance to implementers is probably good, though
> there's (IMHO) a world of complexity hiding under "All other things being
> equal", especially when we consider QoS and the group's desire to be able
> to dynamically modify QoS treatments of bundles via policy.
>
>
>
>     --keith
>
>
>
> On Fri, Feb 16, 2024 at 1:40 AM 구철회 <chkoo at kari.re.kr> wrote:
>
> Hi, Keith.
>
> I think that's the normal operational behavior in LTP and TCPCL even in
> the absence of packet loss during connection because there are
> discontinuity events between A-B and B-C.
>
> When a discontinuity event occurs during a transaction of a LTP session,
> the LTP session could possibly not be ended successfully and may pause to
> await the Report segment from the receiving entity. Upon reconnecting, the
> affected LTP session must resume interrupted session processing (e.g.,
> RS-DS retransmit-RS-RAS), while other LTP sessions can continue smoothly.
>
> Considering that an LTP session typically holds a bundle, in this
> scenario, out-of-order bundle delivery can occur even without packet loss.
> *NOTE* Discontinuity effectively simulates packet loss. TCPCL just acts
> like LTPCL. I think you could check it in a wireshark captured packet by
> seeing a Report segment.
>
> In your scenario, discontinuity events occurred 8 times (4 times for A-B,
> 4 times for B-C). I can observe 8 times of bundle arrival fluctuation
> events in the figure.
>
> Maybe there could be other issues originating this phenomenon, but above
> is my thought. HTH.
>
> Best,
> Cheol
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Feb 2024 20:59:24 +0100
> From: Keith Scott <keithlscott at gmail.com>
> To: sis-dtn at mailman.ccsds.org
> Subject: [Sis-dtn] ION and in-order delivery
> Message-ID:
>         <CAHdkBBmXz6sQrY50p6Ob3ThO005132Ph9KZOiSgW+=
> C-8J5Y0w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I ran a quick test with a 3-node ION network A-B-C where for the first
> minute A is connected to B (via LTP) and B is connected to C (via TCP).
> After that the topology repeats every two minutes; during the first minute
> A is connected to B and during the second B is connected to C.  At t=540s
> full connectivity (A-B and B-C) is restored for one minute.  There is no
> artificially induced loss in this scenario.  The max aggregation size for
> LTP was 100kbytes and the max aggregation time was 1s, e.g.:
> *    a span 2 10 10 64000 100000 1 'udplso 10.44.3.2:1113
> <
> https://protect2.fireeye.com/v1/url?k=ce37f0ae-91ac9aa6-ce328120-ac1f6bdccbcc-797d3695053eff4c&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2F10.44.3.2%3A1113%2F>
> 1000000'*
>
>
> [image: image.png]
>
> I ran bping (will do a unidirectional test later).  The chart below shows
> the received bping sequence number as a function of the order in which
> bpings were received.
>
> [image: image.png]
>
> So yeah, it looks like ION will occasionally misorder bundles.  I think
> that's not ideal, but I strongly believe that it is compliant with both the
> spec and the intent of the service (bundle delivery) BP purports to
> provide.  (And most bundles were in order, which is a feat considering that
> between 60 and 540s the network is never end-to-end connected).
>
>     --keith
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://protect2.fireeye.com/v1/url?k=f133e8de-aea882d6-f1369950-ac1f6bdccbcc-aa39b8d587d0d7dd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.htm
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image.png
> Type: image/png
> Size: 48080 bytes
> Desc: not available
> URL: <
> https://protect2.fireeye.com/v1/url?k=5a238e22-05b8e42a-5a26ffac-ac1f6bdccbcc-ee06a4af1da35812&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.png
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image.png
> Type: image/png
> Size: 79905 bytes
> Desc: not available
> URL: <
> https://protect2.fireeye.com/v1/url?k=c83cc342-97a7a94a-c839b2cc-ac1f6bdccbcc-17dd8d887bfde0f4&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment-0001.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
>
> https://protect2.fireeye.com/v1/url?k=ac25f3ab-f3be99a3-ac208225-ac1f6bdccbcc-2472f80e5d5dbacd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn
>
>
> ------------------------------
>
> End of SIS-DTN Digest, Vol 152, Issue 3
> ***************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240218/6ce68623/attachment-0001.htm>