<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Forwarding this thread back to the entire mailing list so we can come to closure.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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’.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> --keith<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">sburleig.sb@gmail.com <sburleig.sb@gmail.com><br>
<b>Date: </b>Monday, June 28, 2021 at 5:27 PM<br>
<b>To: </b>Dr. Keith L Scott <kscott@mitre.org>, 'Carlo Caini' <carlo.caini@unibo.it><br>
<b>Subject: </b>RE: [EXT] Details on LTP Orange<o:p></o:p></span></p>
</div>
<p class="MsoNormal">Exactly. But if you don’t impose that limit, one way or another, you risk blowing out your storage.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dr. Keith L Scott <kscott@mitre.org> <br>
<b>Sent:</b> Monday, June 28, 2021 5:38 AM<br>
<b>To:</b> sburleig.sb@gmail.com; 'Carlo Caini' <carlo.caini@unibo.it><br>
<b>Subject:</b> Re: [EXT] Details on LTP Orange<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Because of the limitation on the number of open transmission sessions, right? (the flow control mechanism)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> --keith<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black"><a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><br>
<b>Date: </b>Friday, June 25, 2021 at 10:28 PM<br>
<b>To: </b>Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, 'Carlo Caini' <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>><br>
<b>Subject: </b>RE: [EXT] Details on LTP Orange</span><o:p></o:p></p>
</div>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Scott<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>
<br>
<b>Sent:</b> Friday, June 25, 2021 11:50 AM<br>
<b>To:</b> Carlo Caini <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a><br>
<b>Subject:</b> Re: [EXT] Details on LTP Orange<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">No, wait, it’s (“reception of a segment for another session is treated as an implicit EOB” is in your original email (<span style="background:yellow;mso-highlight:yellow">yellow highlight below</span>).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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’ (?)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">So yeah, I agree that FEC will reduce the probability of block loss with Orange, but I’d compare that against (Red + FEC).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> --keith<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Carlo Caini <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>><br>
<b>Date: </b>Tuesday, June 22, 2021 at 7:58 PM<br>
<b>To: </b>Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>,
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><br>
<b>Subject: </b>RE: [EXT] Details on LTP Orange</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Dear Keith,<br>
Thank you for relaying my e-mail to Scott and let me know his new address.<br>
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.
<br>
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.
<br>
<br>
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.
<br>
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.
<br>
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.<br>
<br>
Yours,<br>
Carlo<br>
<br>
<br>
<br>
________________________________________<br>
Da: Dr. Keith L Scott [kscott@mitre.org]<br>
Inviato: lunedì 21 giugno 2021 19:10<br>
A: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Carlo Caini<br>
Oggetto: Re: [EXT] Details on LTP Orange<br>
<br>
Bringing this back together with Scott’s gmail address.<br>
<br>
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.<br>
<br>
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)<br>
<br>
<br>
So the use case question:<br>
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.<br>
<br>
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).<br>
<br>
Can we take this back to the whole list? I think Jeremy had thoughts/opinions on use cases.<br>
<br>
<br>
v/r,<br>
<br>
--keith<br>
<br>
<br>
NOTE: From the Encapsulation Packet Protocol Book:<br>
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.<br>
So if there’s only the one SAP for LTP using the Encapsulation Protocol that should work.<br>
<br>
From: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><br>
Date: Monday, June 21, 2021 at 6:26 PM<br>
To: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><br>
Subject: RE: [EXT] Details on LTP Orange<br>
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.<br>
<br>
My own thoughts on LTP Orange:<br>
<br>
* I think only one flag is needed, as I think “Orange” just means “Green with acknowledgments”; same flag whether EOB or not.<br>
* I think the simplest and most useful Orange mechanism is similar to what we currently do on the Unreliable channel in BSSP:<br>
* 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.)<br>
* Receiver receives segments and reassembles block.<br>
* 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.<br>
<span style="background:yellow;mso-highlight:yellow">* Reception of a segment for another session is treated as an implicit EOB</span>. (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.)<br>
* At the sender:<br>
* 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.<br>
* 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.<br>
* In either case, the sending client is then responsible for dispositioning the client data for that block.<br>
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.<br>
<br>
Scott<br>
<br>
From: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><br>
Sent: Monday, June 21, 2021 7:46 AM<br>
To: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a><br>
Subject: FW: [EXT] Details on LTP Orange<br>
<br>
In case it interests you <span style="font-family:"Apple Color Emoji"">😊</span><br>
<br>
--keith<br>
<br>
<br>
From: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org%3cmailto:kscott@mitre.org">kscott@mitre.org<mailto:kscott@mitre.org</a>>><br>
Date: Monday, June 21, 2021 at 4:34 PM<br>
To: Carlo Caini <<a href="mailto:carlo.caini@unibo.it%3cmailto:carlo.caini@unibo.it">carlo.caini@unibo.it<mailto:carlo.caini@unibo.it</a>>><br>
Cc: <a href="mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</a>> <<a href="mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</a>>>, Burleigh,
Scott C (312G) <<a href="mailto:scott.c.burleigh@jpl.nasa.gov%3cmailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov</a>>><br>
Subject: Re: [EXT] Details on LTP Orange<br>
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.<br>
<br>
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).<br>
<br>
I think the buffer x time requirements work out something like:<br>
<br>
Orange<br>
Red w/ no retransmissions<br>
Minimum time the sender has to maintain a buffer<br>
block transmission time<br>
block transmission time + time to reliably send EORP and RS (could be as little as block transmission time + 1 x owlt)<br>
Maximum time the sender has to maintain a buffer<br>
block transmission time<br>
block transmission time + time to reliably send EORP and RS (could be as little as block transmission time + 1 x owlt)<br>
Minimum time the receiver has to maintain a buffer<br>
block transmission (reception) time<br>
block transmission time + time needed to reliably send the EORP, RS, and a CR (BTT + at least 1RTT).<br>
Maximum time the receiver has to maintain a buffer<br>
(# segments) x (segment timeout)<br>
Block transmission (reception) + time needed to reliably send the EORP, RS, and a CR (BTT + at least one RTT)<br>
<br>
So yes, orange requires less buffer resources than red with no retransmissions. Cool.<br>
<br>
------------------------<br>
<br>
How do we propose to use this service? If the LTP client is BP, what’s going to happen?<br>
<br>
1. If the Orange block is successfully received, great.<br>
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).<br>
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.<br>
<br>
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?<br>
<br>
<br>
<br>
So my questions:<br>
<br>
1. Does the above seem right (especially the ‘how BP could use orange’?)<br>
2. What am I missing from the use case, I’m pretty sure there’s something I’m missing there.<br>
<br>
v/r,<br>
<br>
--keith<br>
<br>
<br>
<br>
From: Carlo Caini <<a href="mailto:carlo.caini@unibo.it%3cmailto:carlo.caini@unibo.it">carlo.caini@unibo.it<mailto:carlo.caini@unibo.it</a>>><br>
Date: Monday, June 21, 2021 at 10:45 AM<br>
To: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org%3cmailto:kscott@mitre.org">kscott@mitre.org<mailto:kscott@mitre.org</a>>><br>
Cc: <a href="mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</a>> <<a href="mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</a>>>, Burleigh,
Scott C (312G) <<a href="mailto:scott.c.burleigh@jpl.nasa.gov%3cmailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov</a>>><br>
Subject: [EXT] Details on LTP Orange<br>
Dear Keith,<br>
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.<br>
Let me summarize a few key points about the orange color:<br>
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.<br>
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.<br>
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).<br>
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).<br>
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:<br>
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.<br>
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.<br>
In BOTH cases the Rx buffer is cleaned, which is one key advantage of orange on very large BDP links<br>
5)<br>
a) at reception of RS, the upper protcol (BP) is notified a success and a RAS is sent<br>
b) at reception of a CR the tranmission session is closed and the upper protocol is notified a failure and a CAR is sent<br>
6)<br>
a) at RAS arrival the reception session is closed.<br>
b) at CAR arrival the reception session is closed.<br>
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.<br>
<br>
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.<br>
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.<br>
Yours,<br>
Carlo<br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
</body>
</html>