[Sis-dtn] FW: [EXT] Details on LTP Orange
Felix.Flentge at esa.int
Felix.Flentge at esa.int
Wed Jun 30 12:46:34 UTC 2021
Dear All,
actually, I have a couple of questions/comments about this:
1) FEC: I see this applied on the coding & sync layer, so I don't see why
we are even discussing this here. From LTP point of view, what is
important is the distribution of packet losses(or frame losses if we would
use frames directly).
2) I think we shall not assume in-order delivery because we see the use of
parallel multiple physical channels at high data rates. I assume that
could cause out-of-order delivery (in particular, if we have varying
segment sizes).
3) I think we shall not prevent interleaving of sessions (again, could be
useful for multiple bands; we could have one red session and use green
in-between for ancillary data).
4) I don't see the point regarding the storage. If I know that my
retransmission limit is zero, I could clear my storage as soon as I have
sent a segment out like I would do with orange,
5) What about cancelling on the receiver side? As soon as the receiver
sees a missing segment, it can cancel a red session. This would also
provide the sender a signal that the transmission has not been successful.
Would this be sufficient (together with maybe setting the sender
retransmission limit to zero) to cover the intended use cases for orange?
I am not against defining a new (optional) orange session type but that
should not impose any limitations on the other session types. I also would
like to better understand the scenarios where one would use the orange
sessions. Also, we should be very careful not to jump to changes in the
protocol because of the way specific implementations work.
Regards,
Felix
From: "Dr. Keith L Scott" <kscott at mitre.org>
To: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date: 30/06/2021 13:13
Subject: [Sis-dtn] FW: [EXT] Details on LTP Orange
Sent by: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>
Forwarding this thread back to the entire mailing list so we can come to
closure.
I now believe that ?orange + red? (one orange attempt followed by red if
the orange fails) nearly always has lower storage requirements at the
transmitter and roughly equivalent storage requirements at the receiver as
?just do red?.
I do think we should be clear on some of the ancillary concepts, like
Scott?s suggestion that maybe we require that orange blocks not be
interleavable with other orange blocks ? I think that might mean we?re
limited to a single ?streaming? (if that?s the primary use for Orange)
session per link (?) If we allow interleaving of multiple Orange blocks
(or even an Orange block with other colored blocks) then I think it gets
harder to set the segment timeout timer at the receiver ? what should we
do about that?
--keith
From: sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Monday, June 28, 2021 at 5:27 PM
To: Dr. Keith L Scott <kscott at mitre.org>, 'Carlo Caini'
<carlo.caini at unibo.it>
Subject: RE: [EXT] Details on LTP Orange
Exactly. But if you don?t impose that limit, one way or another, you risk
blowing out your storage.
From: Dr. Keith L Scott <kscott at mitre.org>
Sent: Monday, June 28, 2021 5:38 AM
To: sburleig.sb at gmail.com; 'Carlo Caini' <carlo.caini at unibo.it>
Subject: Re: [EXT] Details on LTP Orange
Because of the limitation on the number of open transmission sessions,
right? (the flow control mechanism)
--keith
From: sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Friday, June 25, 2021 at 10:28 PM
To: Dr. Keith L Scott <kscott at mitre.org>, 'Carlo Caini' <
carlo.caini at unibo.it>
Subject: RE: [EXT] Details on LTP Orange
Using all-Red for streaming is fine so long as you don?t impose any flow
control that could delay transmission of the next service data unit. ION
currently doesn?t work that way.
Scott
From: Dr. Keith L Scott <kscott at mitre.org>
Sent: Friday, June 25, 2021 11:50 AM
To: Carlo Caini <carlo.caini at unibo.it>; sburleig.sb at gmail.com
Subject: Re: [EXT] Details on LTP Orange
No, wait, it?s (?reception of a segment for another session is treated as
an implicit EOB? is in your original email (yellow highlight below).
Regardless, I?m fine with assuming an in-order delivery service underneath
LTP, let?s just make sure that that meshes with the various CCSDS link
services (including USLP).
Somebody should probably do the trade study to determine the relative
merits of Orange vs. just using Red (esp. if the goal is Scott?s streaming
solution). With Red and streaming, if I multiplex multiple (Red) blocks
together, I sort of get the same behavior with lower bandwidth costs (I
think, because I can retransmit a single LTP segment rather than a whole
block).
I THINK from this that the question is: for a given block/segment size and
given segment error rate (SER) [with or without FEC might not really
matter; but we can just do ?with?], what are the (time x bytes of storage)
and (total # of bytes transmitted) for ?just Red? and ?Orange + Red if
Orange fails? (?)
So yeah, I agree that FEC will reduce the probability of block loss with
Orange, but I?d compare that against (Red + FEC).
--keith
From: Carlo Caini <carlo.caini at unibo.it>
Date: Tuesday, June 22, 2021 at 7:58 PM
To: Dr. Keith L Scott <kscott at mitre.org>, sburleig.sb at gmail.com <
sburleig.sb at gmail.com>
Subject: RE: [EXT] Details on LTP Orange
Dear Keith,
Thank you for relaying my e-mail to Scott and let me know his new
address.
Sorry, but I cannot remember where I have written that the "reception of
a segment for another session is treated as an implicit EOB?. At present
in Unibo-LTP this condition is not enforced, but I agree with you that it
could make sense if segments could not arrive out of order. In Internet,
however, they may, even if it is quite rare. Thus, if we assume that LTP
could be used on top of UDP we cannot use this condition, otherwise we
can. I know that in RFC5326 there are a lot of caveats against a possible
use of LTP on Internet, but this does not mean that in specific
circumstances it could be useful.
FIFO delivery with orange could simplify the recognition of a failure, as
after the first missing segment you could safely cancel the session. With
red maybe you can gain something in speed by inserting all incoming
segments into a list/buffer without looking at offsets; after the EOB
reception the list/bufer should appear ordered (but possibly with gaps).
In Unibo-LTP we do not require FIFO; however, segments are inserted in a
list and if they arrive in order the insertion is faster.
It is true that even with FEC you can still have a failure, thus the need
of retranmitting a bundle. However, FEC has changed the game rules. Let me
assume that we use red or orange without FEC. The probability of having at
least one loss among the N segment of a block increases with N. If this
happens, you either need a re-Tx cycle (red) or a bundle reTx (orange).
This sensitivity to the block lenght is quite annoying. In brief, as
suggested by Scott in the other e-mail, you need to keep N low, i.e. to
introduce fragmentation and so on. The probability of at least one loss,
however, depends also on the segment PER (Packete erasure rate). The
higher the PER, the shorter should be the block lenght N.
Now, if we introduce FEC, to recover losses is enough to have more
redundancy segments than losses on the coded block. If the code rate is
Rc=8/9, this means that you have one redundancy segment every 8
information segments. You can recover one loss every 9 segments sent. Thus
the probability of failure does not increase with N, which eliminates the
need of using small bundles or of fragmenting them. A great advantage
provided by FEC.
That said, given a PER, you can set the Rc so that to keep the possibility
of a FEC failure as low as you like, without being obliged to reduced tyhe
block dimension. That said, it is true that if you have to retranmit a
fuill bundle you waste capacity, but with FEC this event, altuogh
possible, can be made negligible.
Yours,
Carlo
________________________________________
Da: Dr. Keith L Scott [kscott at mitre.org]
Inviato: lunedì 21 giugno 2021 19:10
A: sburleig.sb at gmail.com; Carlo Caini
Oggetto: Re: [EXT] Details on LTP Orange
Bringing this back together with Scott?s gmail address.
Yeah, we did have a DTN telecon last week, dunno what happened, apologies.
We MAY NOT have one next week, but I?ll send email.
So your ?reception of a segment for another session is treated as an
implicit EOB? means no interleaving of other LTP sessions w/ an Orange
session, right? OK, just checking. That would make setting the timers
easier (if you know you don?t have to share the link w/ other blocks). I
wonder what else in the Red service specification gets easier if we assume
FIFO delivery of LTP segments by the underlying transmission service? I?ll
bet it could make the reassembly implementation a boatload simpler? I
think it works out over the Encapsulation Service if there?s only one LTP
SAP into Encap (see note below)
So the use case question:
If the bundle layer is using Orange to send bundles for which it wants
reliability, then if there is (non-recoverable, e.g. beyond the ability of
the erasure coding to correct) loss, then I think it?s likely an overall
loss in terms of efficiency since the bundle layer will have to retransmit
the entire bundle.
If the bundle layer is using Orange to send bundles for which it doesn?t
necessarily require reliability, just an indication of success then OK,
but I?m not clear on the utility there (not that there isn?t one, I just
don?t get it yet).
Can we take this back to the whole list? I think Jeremy had
thoughts/opinions on use cases.
v/r,
--keith
NOTE: From the Encapsulation Packet Protocol Book:
The point at which an instance of this protocol is provided to a user is
called a Service Access Point (SAP) (reference [6]). Data units submitted
to a SAP are processed in the order of submission. No processing order is
maintained for data units submitted to different SAPs.
So if there?s only the one SAP for LTP using the Encapsulation Protocol
that should work.
From: sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Monday, June 21, 2021 at 6:26 PM
To: Dr. Keith L Scott <kscott at mitre.org>
Subject: RE: [EXT] Details on LTP Orange
I am interested. Was there a DTN WG meeting last week? I dimly remember
trying to log in but not succeeding. I?d gladly sit in, but since I am no
longer affiliated with a member space agency that may not be doable; if it
is, I think you would need to send me a new invitation.
My own thoughts on LTP Orange:
* I think only one flag is needed, as I think ?Orange? just means
?Green with acknowledgments?; same flag whether EOB or not.
* I think the simplest and most useful Orange mechanism is similar to
what we currently do on the Unreliable channel in BSSP:
* Sender transmits all segments of the block and sets a timer to 1
RTT per the contact plan. (Like all LTP timers, this timer is subject to
pause and resume when contacts end and restart.)
* Receiver receives segments and reassembles block.
* On reception of EOB, the receiver sends a Report back to the
sender (complete or incomplete, just as for Red), delivers block contents
to the client if the block is complete (discards block contents
otherwise), terminates the import session.
* Reception of a segment for another session is treated as an
implicit EOB. (Segments can theoretically arrive out of transmission
order but in practice I think this will be vanishingly rare; this is just
above link layer, so in space transmission I don?t see how it happens.)
* At the sender:
* On reception of a Report that says complete ? prior to timer
expiration ? the sender tells the client that all block contents were
successfully received and terminates the export session.
* On timer expiration, on reception of a Report that says
Incomplete, or on loss of a Report that says complete, the sender tells
the client that block contents were not successfully received and
terminates the export session.
* In either case, the sending client is then responsible for
dispositioning the client data for that block.
This is not very efficient if there is heavy data loss on the link, but I
think that can be mostly mitigated by erasure coding at the link service
layer, which we should probably be doing in that case anyway.
Scott
From: Dr. Keith L Scott <kscott at mitre.org>
Sent: Monday, June 21, 2021 7:46 AM
To: sburleig.sb at gmail.com
Subject: FW: [EXT] Details on LTP Orange
In case it interests you ?
--keith
From: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Date: Monday, June 21, 2021 at 4:34 PM
To: Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>
Cc: tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de> <
tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>>, Burleigh, Scott C
(312G) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov
>>
Subject: Re: [EXT] Details on LTP Orange
In your description below it seems like you?re assuming in-order delivery
by the underlying service (so that when the EOB is received, you can
immediately make a decision as to whether or not the entire block was
received). That?s not a requirement of the current LTP spec (it allows
for out-of-order delivery of segments). You could get around this by just
waiting for the segment timeout if the receiver gets and EOB and doesn?t
yet have everything.
Orange segments would likely require some implementation decisions at the
sender, like maybe constraints on interleaving of segments from orange
blocks and other segments (so that interleaving segments from N flows
doesn?t inadvertently cause an orange session to time out).
I think the buffer x time requirements work out something like:
Orange
Red w/ no retransmissions
Minimum time the sender has to maintain a buffer
block transmission time
block transmission time + time to reliably send EORP and RS (could be as
little as block transmission time + 1 x owlt)
Maximum time the sender has to maintain a buffer
block transmission time
block transmission time + time to reliably send EORP and RS (could be as
little as block transmission time + 1 x owlt)
Minimum time the receiver has to maintain a buffer
block transmission (reception) time
block transmission time + time needed to reliably send the EORP, RS, and a
CR (BTT + at least 1RTT).
Maximum time the receiver has to maintain a buffer
(# segments) x (segment timeout)
Block transmission (reception) + time needed to reliably send the EORP,
RS, and a CR (BTT + at least one RTT)
So yes, orange requires less buffer resources than red with no
retransmissions. Cool.
------------------------
How do we propose to use this service? If the LTP client is BP, what?s
going to happen?
1. If the Orange block is successfully received, great.
2. If the entire Orange block is NOT received and BP is willing to drop
the bundle, ok (now at least BP knows that the bundle didn?t get through,
which it wouldn?t have known if we?d used LTP green).
3. If the entire Orange block is NOT received and BP wants to
retransmit the bundle, it can do so at the cost of having to retransmit
the whole bundle when only one or a few LTP segments might have been lost
out of the orange block. This seems like a potential loss of efficiency.
We were talking about this as a way to support semi-reliability of
streaming services, but if you intend to eventually retransmit lost
bundles, that?s a whole extra round of resource (buffer x time) that we
have to pay. Maybe I?m not getting the use case right?
So my questions:
1. Does the above seem right (especially the ?how BP could use
orange??)
2. What am I missing from the use case, I?m pretty sure there?s
something I?m missing there.
v/r,
--keith
From: Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>
Date: Monday, June 21, 2021 at 10:45 AM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Cc: tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de> <
tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>>, Burleigh, Scott C
(312G) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov
>>
Subject: [EXT] Details on LTP Orange
Dear Keith,
Unfortunately I could not attend last Wedenesday meeting, because
of concurrent engagements (lots of exams). Tomaso de Cola (in CC) told me
that LTP Orange was discussed again, which is pleasant to me.
Let me summarize a few key points about the orange color:
1) we assume that only monochrome sessions are possible, i.e. either red,
or green, or orange. This is an important point, because it introduces a
one-to-one correspondence between color (i.e. service) and session.
2) orange service is "notified" (bot positive and negative notifications
are used), which can be seen as intermediate between a reliable (red) and
an unreliable (green) service.
3) orange works this way: a block is sent, consisting of "orange data"
segments (we will use one of the two LTP segment codes "reserved" in
RFC5326), and, last, one "orange data segment with EOB" (we will use the
second code reserved).
By contrast to green, the transmission session is not immediately closed,
while by contrast to red, there is no need of keeping a Tx buffer (we will
never resend data at LTP layer with Orange).
4) at the arrival of the first orange data segment, a reception session
("import session" in ION) is opened. At EOB arrival (or after an
inter-segment timer expires, should the EOB get lost) the content of the
current session Rx buffer is checked. From now on, we must distinguish
between two cases:
a) If all data have arrived, the buffer content is passed to upper protcol
(BP). An RS confirming all data is sent. This RS plays the role of a
positive notification.
b) if some data are missing, in orange there is no point in keeping the
session open. The session is thus immediately cancelled and consequently a
CR is sent. This CR works as a negative notification.
In BOTH cases the Rx buffer is cleaned, which is one key advantage of
orange on very large BDP links
5)
a) at reception of RS, the upper protcol (BP) is notified a success and a
RAS is sent
b) at reception of a CR the tranmission session is closed and the upper
protocol is notified a failure and a CAR is sent
6)
a) at RAS arrival the reception session is closed.
b) at CAR arrival the reception session is closed.
7) the duration of both the transmission and reception session is 1 RTT.
Let me stress one again that both the session Tx and the Rx buffers are
used for the time strictly necessary to send or receive a block, i.e.
usually a tiny fraction of RTT. This means that only one buffer is
necessary.
Note that in case of losses, the alternative of sending an RS with
multiple claims and setting to zero the retransmission limit on the
sender, would lead the the same final result of the original proposal, but
the Tx session would last two, instead of one RTT, which iis acceptable,
but also suboptimal.
I have deliberatley skipped a discussion on pros and cons and possible use
cases not to make this mail too long (they were discussed during the CCSDS
meeting). However, I would be pleased to provide you with further
information on these points, if necessary.
Yours,
Carlo
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210630/e2c61285/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210630/e2c61285/attachment-0001.bin>
More information about the SIS-DTN
mailing list