<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">actually, I have
a couple of questions/comments about this:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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). </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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, </span>
<br>
<br><span style=" font-size:11pt;font-family:Calibri">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?</span>
<br>
<br><span style=" font-size:11pt;font-family:Calibri">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.</span>
<br>
<br><span style=" font-size:11pt;font-family:Calibri">Regards,</span>
<br><span style=" font-size:11pt;font-family:Calibri">Felix</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Dr.
Keith L Scott" <kscott@mitre.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"sis-dtn@mailman.ccsds.org"
<sis-dtn@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">30/06/2021
13:13</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[Sis-dtn]
FW: [EXT] Details on LTP Orange</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SIS-DTN"
<sis-dtn-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Forwarding
this thread back to the entire mailing list so we can come to closure.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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’.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
--keith</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>sburleig.sb@gmail.com <sburleig.sb@gmail.com><b><br>
Date: </b>Monday, June 28, 2021 at 5:27 PM<b><br>
To: </b>Dr. Keith L Scott <kscott@mitre.org>, 'Carlo Caini' <carlo.caini@unibo.it><b><br>
Subject: </b>RE: [EXT] Details on LTP Orange</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Exactly.
But if you don’t impose that limit, one way or another, you risk
blowing out your storage.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
Dr. Keith L Scott <kscott@mitre.org> <b><br>
Sent:</b> Monday, June 28, 2021 5:38 AM<b><br>
To:</b> sburleig.sb@gmail.com; 'Carlo Caini' <carlo.caini@unibo.it><b><br>
Subject:</b> Re: [EXT] Details on LTP Orange</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Because
of the limitation on the number of open transmission sessions, right? (the
flow control mechanism)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
--keith</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b></span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">
<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Date: </b>Friday, June 25, 2021 at 10:28 PM<b><br>
To: </b>Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,
'Carlo Caini' <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Subject: </b>RE: [EXT] Details on LTP Orange</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<b><br>
Sent:</b> Friday, June 25, 2021 11:50 AM<b><br>
To:</b> Carlo Caini <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;
</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>
Subject:</b> Re: [EXT] Details on LTP Orange</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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’ (?)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">So
yeah, I agree that FEC will reduce the probability of block loss with Orange,
but I’d compare that against (Red + FEC).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
--keith</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>Carlo Caini <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Date: </b>Tuesday, June 22, 2021 at 7:58 PM<b><br>
To: </b>Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,
</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">
<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Subject: </b>RE: [EXT] Details on LTP Orange</span></p>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri">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: </span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri">;
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: </span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri">
<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri">><br>
Date: Monday, June 21, 2021 at 6:26 PM<br>
To: Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">><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>
* 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.)<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 <</span><a href=mailto:kscott@mitre.org><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">><br>
Sent: Monday, June 21, 2021 7:46 AM<br>
To: </span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri"><br>
Subject: FW: [EXT] Details on LTP Orange<br>
<br>
In case it interests you </span><span style=" font-size:11pt">?</span><span style=" font-size:11pt;font-family:Calibri"><br>
<br>
--keith<br>
<br>
<br>
From: Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org%3cmailto:kscott@mitre.org><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org<mailto:kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><br>
Date: Monday, June 21, 2021 at 4:34 PM<br>
To: Carlo Caini <</span><a href=mailto:carlo.caini@unibo.it%3cmailto:carlo.caini@unibo.it><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>carlo.caini@unibo.it<mailto:carlo.caini@unibo.it</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><br>
Cc: </span><a href=mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<</span><a href=mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</u></span></a><span style=" font-size:11pt;font-family:Calibri">>>,
Burleigh, Scott C (312G) <</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov%3cmailto:scott.c.burleigh@jpl.nasa.gov><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><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 <</span><a href=mailto:carlo.caini@unibo.it%3cmailto:carlo.caini@unibo.it><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>carlo.caini@unibo.it<mailto:carlo.caini@unibo.it</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><br>
Date: Monday, June 21, 2021 at 10:45 AM<br>
To: Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org%3cmailto:kscott@mitre.org><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>kscott@mitre.org<mailto:kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><br>
Cc: </span><a href=mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<</span><a href=mailto:tomaso.decola@dlr.de%3cmailto:tomaso.decola@dlr.de><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>tomaso.decola@dlr.de<mailto:tomaso.decola@dlr.de</u></span></a><span style=" font-size:11pt;font-family:Calibri">>>,
Burleigh, Scott C (312G) <</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov%3cmailto:scott.c.burleigh@jpl.nasa.gov><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">>><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>
</span><tt><span style=" font-size:10pt">_______________________________________________<br>
SIS-DTN mailing list<br>
SIS-DTN@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt></p>
<p style="margin-top:0px;margin-Bottom:240px"></p>
<p style="margin-top:0px;margin-Bottom:240px"></p>