[Sis-dtn] FW: [EXT] Details on LTP Orange
Carlo Caini
carlo.caini at unibo.it
Wed Jun 30 16:05:45 UTC 2021
Dear Keith and Felix,
Ilet me add a few comments in line.
Yours,
Carlo
________________________________________
Da: SIS-DTN [sis-dtn-bounces at mailman.ccsds.org] per conto di Dr. Keith L Scott [kscott at mitre.org]
Inviato: mercoledì 30 giugno 2021 16:02
A: Felix.Flentge at esa.int
Cc: sis-dtn at mailman.ccsds.org
Oggetto: Re: [Sis-dtn] FW: [EXT] Details on LTP Orange
FEC: right, I think that the use of FEC is probably a good idea, but the real input parameter to evaluations of Orange vs. (something, like RED w/ no retransmissions) is probably segment loss rate (and to some degree loss distribution).
If we don’t assume in-order delivery and/or allow interleaving of sessions, we need to sort out what the inter-orange-segment arrival timeout value should be in order to terminate a receiving Orange session.
CC>I agree with you Keith. However, let me point out to other readers that normally there is not any problem in recognizing the end of a green or orange block, because this is signalled by the orange or green EOB. However, to cope with the possible loss of the EOB segment, the inter-segment timer would be necessary. This timer is therefore a back-off mechanism that should be used only rarely. If PER is =1% this means that in 99% of cases you would receive the EOB and only in 1% of cases you should rely on tyhe inter-segment timer. The assumption of in order delivery can help, no doubt, but the inter-segment timer is however necessary, as the EOB could be lost in the last block. I mean that if the block of which the EOB is lost is not followed by others, you cannot rely on the arrival by segments of other sessions. OK, you must be super unlucky, but it may happen.
I’m more worried about this from the interleaving standpoint than the in-order arrival standpoint, and maybe this isn’t really an issue, we just set the timeout value to be quite large (like half a round trip time, or an RTT?). The issue there is that if we’re multiplexing LOTS of sessions, and especially if we don’t want to say HOW the sender is supposed to interleave segments from those sessions.
Storage: If you know your retransmission count is zero for a red block, hm. Yes, I suppose you could clear the storage for transmitted segments immediately. That’s still a ‘one-off’ change to the red IMPLEMENTATION (i.e. it’s a special case in the implementation if the retry count is zero), but yeah. If one did that, is it effectively an Orange block at that point? There would be some small differences:
1. With Orange you don’t have to transmit the End-of-Block / report request reliably (as the receiver will kill the session after timeout).
Canceling on the receiver side: yeah, I think that’s part of the plan. That was in Scott’s proposal to cancel on reception of a segment from some other session in the middle of an Orange reception session (I think).
CC>I agree again with you on previous comments. Let me add that in some cases, i.e. for some bundles, we could prefer to use red, in other orange in other green, depending on the declared QoS of the bundle (and on other factors), the same way now "unrelaible" bundles are sent as LTP green instaed of red. If we set the max reTx limit of red to zero, we would have a red that looks like (wityhout being) orange, but this setting would basically make impossible to send bundles with a "real" red service, I mean with a non-zero number of retransmissions. The aim of orange is not to replace red, but to complement it.
>>The key is to consider only monochrome blocks, which greatly simplifies the code. This also means that one session would have one color, i.e. it would provide one QoS (either reliable, or notified, or unreliable). TYhe choice of the color, i.e. of the desired QoS, should be carried out on the basis of the bundle characteristics and, possibly, of local information (i.e. if from X to Y the link is unidirectional, the only possible choice is green).
I think your point 4 more directly expresses my question: if we do red with no retransmissions (and maybe with modifications as you point out) – is that effectively orange? Scott raised the point about the number of allowed open LTP sessions providing flow control on the sender in ION. There’s nothing in the LTP spec about that, as far as I know, but it’s something to consider.
--keith
From: Felix.Flentge at esa.int <Felix.Flentge at esa.int>
Date: Wednesday, June 30, 2021 at 2:46 PM
To: Dr. Keith L Scott <kscott at mitre.org>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] FW: [EXT] Details on LTP Orange
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<mailto:sburleig.sb at gmail.com> <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>
Date: Friday, June 25, 2021 at 10:28 PM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, 'Carlo Caini' <carlo.caini at unibo.it<mailto: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<mailto:kscott at mitre.org>>
Sent: Friday, June 25, 2021 11:50 AM
To: Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; sburleig.sb at gmail.com<mailto: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<mailto:carlo.caini at unibo.it>>
Date: Tuesday, June 22, 2021 at 7:58 PM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com> <sburleig.sb at gmail.com<mailto: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<mailto: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<mailto:sburleig.sb at gmail.com> <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>
Date: Monday, June 21, 2021 at 6:26 PM
To: Dr. Keith L Scott <kscott at mitre.org<mailto: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<mailto:kscott at mitre.org>>
Sent: Monday, June 21, 2021 7:46 AM
To: sburleig.sb at gmail.com<mailto: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<mailto:kscott at mitre.org%3cmailto: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<mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it>>>
Cc: tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de%3cmailto:tomaso.decola at dlr.de>> <tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de%3cmailto:tomaso.decola at dlr.de>>>, Burleigh, Scott C (312G) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov%3cmailto: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<mailto:carlo.caini at unibo.it%3cmailto: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<mailto:kscott at mitre.org%3cmailto:kscott at mitre.org>>>
Cc: tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de%3cmailto:tomaso.decola at dlr.de>> <tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de%3cmailto:tomaso.decola at dlr.de>>>, Burleigh, Scott C (312G) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov%3cmailto: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
More information about the SIS-DTN
mailing list