$)C<span style=" font-size:10pt;font-family:sans-serif">Thanks Cheol,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">thanks for pointing
this out (I am mostly occupied with high-data rate downlinks so I may sometimes
overlook these scenarios). Indeed, optimal Bundle/LTP segment sizes (and
maybe even more packet/frame sizes) are depending on on-board resources,
mission requirements and the communication characteristics (bandwidth-delay
but also the probabilistic distribution of errors). Of course, these sizes
have to be traded of with protocol and processing overheads (smaller sizes
and non-alignment with transport structure such as packets typically mean
more processing). I definitely believe that we need to maintain sufficient
flexibility in bundle/ltp segment sizes to cover all different situations.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">regards,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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">"Burleigh,
Scott C\(US 312B\) via SIS-DTN" <sis-dtn@mailman.ccsds.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">"18C6H8"
<chkoo@kari.re.kr>, "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">05/03/2021
21:54</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[Sis-dtn] LTP High, Medium, Low Data Rate Profiles</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">Hi,
Cheol. For extremely large bandwidth-delay products we do need to
do something different, but I would propose using a larger number of concurrent
transmission sessions (i.e., blocks) rather than increasing the sizes of
the blocks. The larger a block is, the greater than chance that some
part of it will need to be transmitted, resulting in increased delivery
latency.</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>
SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>???<b><br>
Sent:</b> Monday, March 1, 2021 11:58 PM<b><br>
To:</b> sis-dtn@mailman.ccsds.org<b><br>
Subject:</b> [EXTERNAL] Re: [Sis-dtn] LTP High, Medium, Low Data Rate Profiles</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<br><span style=" font-size:10pt">Greetings all,<br>
<br>
Let me have a note to a situational difference when bundle sizes or ltp
block sizes are being discussed.<br>
1) I think bundle sizes/ltp block sizes can be (really) big between dtn
relay nodes that are supposed to have enough resources, e.g., high speed
processor, big storage and fast comm, that normally ground stations equip.
Huge bundle sizes or ltp block sizes make sense and can be supported by
specification document.<br>
2) However, a rover or lander on a long-distance planet like Mars have
different situation. Simply, there are chances that the rover and lander
can't service the retransmission request of a really huge bundles regardless
of CFDP or bundle blocks because of lack of on-board resources supporting
telecommunications with the most adjacent dtn nodes (relay orbiter or ground
station).<br>
<br>
Please consider low power, or temporarily handicapped (processor power
or radio power) system in space segment during specification update.<br>
<br>
Best,<br>
Cheol<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 2 Mar 2021 07:56:27 +0100<br>
From: </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt"><br>
To: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt"><br>
Subject: [Sis-dtn] LTP High, Medium, Low Data Rate Profiles<br>
Message-ID:<br>
<</span><a href="mailto:OF1E55830F.B2C9A54F-ONC125868C.002433AD-C125868C.002620EF@esa.int"><span style=" font-size:10pt;color:blue"><u>OF1E55830F.B2C9A54F-ONC125868C.002433AD-C125868C.002620EF@esa.int</u></span></a><span style=" font-size:10pt">><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Dear All,<br>
<br>
I had a first go at defining some profiles for high, medium and low data
rates.<br>
<br>
<br>
<br>
There a certainly some choices to discuss. In particular, I have limited<br>
the client ID and the service ID to just one byte each as it seemed more<br>
then sufficient for a protocol operating on a single link.<br>
I am also wondering whether the medium profile makes sense or whether it<br>
would be enough to have the low and the high one.<br>
I think we shall discuss in one of the next meetings (maybe after we have<br>
started the BP/BPSEC discussions).<br>
<br>
Related to the points below:<br>
1) LTP Block Size: I assume that Bundle / LTP Blocks can be rather large<br>
(4 GB for the high data rate). This is to reduce overheads, limit the<br>
number of bundles (eg, if we want to have reports or custody transfer)
and<br>
just seems typically easier to handle. Also, as we have seen for CFDP,<br>
on-board implementations may have rather low limits on the number of<br>
parallel sessions.<br>
2) The CFDP point is an important one: it seems that CFDP over BP is not<br>
formally specified in CCSDS (please correct me if I am wrong). The<br>
straight-forward approach to encapsulate each CFDP PDU in a separate<br>
bundle is not ideal because of the overheads (I will never be able to<br>
convince our missions to do something like that). I see two options here:<br>
a) aggregating several CFDP PDU (possibly also from different<br>
transactions) in a single bundle; I think we would need to define this<br>
somewhere (similar to the CFDP / Encapsulation book)<br>
b) we would allow really large file segments in CFDP; however, this would<br>
require a change in the CFDP standard<br>
I personally would tend to 2)a). I would not like to put DTCP in here as<br>
its services (besides aggregation) are not required and it would add yet<br>
another protocol.<br>
[maybe this discussion would belong more to the CFDP WG]<br>
<br>
Regards,<br>
Felix<br>
<br>
<br>
<br>
From: <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
To: <</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov><span style=" font-size:10pt;color:blue"><u>scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:10pt">>,
<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">><br>
Cc: <</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">>,
<</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt">><br>
Date: 26/02/2021 17:38<br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
<br>
<br>
Hi Scott,<br>
<br>
You are right. In principle one could even use DTPC, I think, to aggregate<br>
multiple ADUs (i.e., CFDP PDUs in this case) to have a larger bundle. I<br>
was just reasoning on the scenario described from Felix, requiring a large<br>
session that I?ve translated into large block, to scope it in view of the<br>
discussion we did early today about the retransmission cycle concept of<br>
LTP.<br>
<br>
Best,<br>
<br>
Tomaso<br>
<br>
From: Burleigh, Scott C (US 312B) <</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov><span style=" font-size:10pt;color:blue"><u>scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:10pt">><br>
Sent: Freitag, 26. Februar 2021 17:16<br>
To: Cola, Tomaso de <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">>;
</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">;
</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt"><br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
I don?t think that?s a constraint. First, we expect CFDP normally
to run<br>
over BP, and BP to be the LTP client; in that formulation, LTP blocks<br>
could be quite large because multiple CFDP file data PDUs might be<br>
aggregated into a single bundle payload. (ION CFDP/BP doesn?t work
that<br>
way, but it probably should; it?s usually advantageous for bundles to be<br>
large.) Second, even if CFDP were the LTP client, the CFDP UT adapter
for<br>
LTP might well aggregate multiple CFDP file data PDUs into a single LTP<br>
block ? an application-defined ?service data aggregation? mechanism as<br>
we?ve been discussing.<br>
<br>
Scott<br>
<br>
From: SIS-DTN <</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">>
On Behalf Of</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt"><br>
Sent: Friday, February 26, 2021 5:02 AM<br>
To: </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">;
</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt"><br>
Subject: [EXTERNAL] Re: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Ok about the large session duration, but how big would LTP blocks be if
we<br>
take into considerations that CFDP PDUs can carry at most 64kybtes (if
I?m<br>
not mistaken)?<br>
<br>
Tomaso<br>
<br>
From: </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">
<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">><br>
Sent: Freitag, 26. Februar 2021 12:29<br>
To: Cola, Tomaso de <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
Cc: </span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt">;
</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt"><br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Yes,<br>
<br>
the scenario I had in mind is deep space to Earth (RTT in the order of<br>
minutes). Here, on-board implementations might want to have rather large<br>
session durations to limit the number of parallel sessions (the on-board<br>
CFDP implementations I have seen allow only a few parallel transactions<br>
which requires to reduce the latency for completing the transactions).<br>
<br>
The idea of sending RS without an CP is interesting (similar to CFDP async<br>
NAK), it could maybe even triggered after some "inactivity" timeout.<br>
<br>
Regards,<br>
Felix<br>
<br>
<br>
<br>
From: <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
To: <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt">>,
<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">><br>
Cc: <</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">><br>
Date: 26/02/2021 11:37<br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
<br>
<br>
<br>
Hi Carlo,<br>
<br>
My understanding from Felix's comment was about a long session duration,<br>
i.e. if we have to transfer a very long LTP block (say 10 seconds duration<br>
against 1s RTT), then probably waiting too long for the retransmission
may<br>
be problematic if the sender is resource-constrained. The receiver side,<br>
if on ground, probably does not have too many problems in keeping some<br>
buffer allocated for long. If we are referring to space-to-space the<br>
situation can certainly be different, but in such a case I'm tempted to<br>
assumed almost error-free transmission. I'm in any case waiting for Felix<br>
clarification on the scenario he had in mind here ?<br>
<br>
Regards,<br>
<br>
Tomaso<br>
<br>
-----Original Message-----<br>
From: Carlo Caini <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt">><br>
Sent: Freitag, 26. Februar 2021 11:31<br>
To: </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">;
Cola, Tomaso de <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Dear Felix,<br>
intermediate CPs can be useful, in theory, if radiation time >>
RTT, as<br>
interpreted by Tomaso. Assuming as a rule of thumb that the radiation time<br>
of one bundle does not exceeds 1s, intermediate CPs have no advantages<br>
starting from Moon communications and on. You could still have some<br>
advantages on shorter RTTs, as with LEOs.<br>
However you cannot release anything at Rx side, until the whole block has<br>
been received, which means that in the best case you can save only the<br>
time elapsed between the intermeiate CP (let me assume for the sake of<br>
similicity we have only one at a half of the block) and the last. This
is<br>
equal to a half radiation time, and this only under the conditions that<br>
you have lasses only on the first half of the block and not on the second<br>
one. This bacause in the latter case you should wait for the RS triggered<br>
by the final CP to start retx of losses, thus the first intermediate CP<br>
would be useless in this case. This is why I think these intermediate CPs<br>
are not implemented in ION, but of course I am not sure...<br>
<br>
Concerning the session timer, I happy to know that we share the same<br>
vision. By the way, I suppose it should be easy to implement. This time<br>
could also be "advertised" to the Rx side, by means of
a segment<br>
extension, inserted on the first segment (or on all). On the same line,
I<br>
think that it could be useful to let the Rx know the dimension of the<br>
block asap. This could allow the Rx to cancel a too long (in size) session<br>
in a proactive way, without waiting to have received too many segments.
To<br>
know the lenght in advance could also help to reserve to the Rx session<br>
buffer the right amount of space (provided that there is sufficient<br>
space), etc. Last, it could also help when the last segment, that flagged<br>
as a CP, is lost. In this case the session stalls for an RTO, because the<br>
receiver do nothing until the retranmitted CP arrives (after one RTO, as<br>
said, i.e. 6 minutes from Earth to Mars in the best case). By knowing in<br>
advance the block lenght, it would be strightforward to force the<br>
transmission of a gratuitous RS after a much shorter inter-segment timer<br>
has elapsed (it could be be set equal to the expected radiation time of<br>
the block).<br>
Yours,<br>
Carlo<br>
<br>
<br>
________________________________________<br>
Da: </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">
[Felix.Flentge@esa.int]<br>
Inviato: venerdi 26 febbraio 2021 10:05<br>
A: Carlo Caini<br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">;
</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt"><br>
Oggetto: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Hi Carlo,<br>
<br>
I assume there could be advantages of intermediate checkpoints in cases<br>
where the duration of the session >> RTT (could reduce overall latency,<br>
on-board memory could be freed).<br>
<br>
I certainly like the idea of a blocklifetime. It could maybe even be an<br>
optional parameter of the Transmission.request (which might need some<br>
changes anyway because of the removal of mixed sessions).<br>
<br>
Regards,<br>
Felix<br>
<br>
<br>
<br>
From: "Carlo Caini" <</span><a href=mailto:carlo.caini@unibo.it><span style=" font-size:10pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:10pt">><br>
To: "</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">"
<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">>,
"</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">"
<</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
Cc: "</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">"
<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">><br>
Date: 26/02/2021 09:01<br>
Subject: RE: [Sis-dtn] Telecon Notes 20210224<br>
________________________________<br>
<br>
<br>
<br>
Dear Felix,<br>
I agree with you that the text is difficult to understand, but I
would<br>
ascribe the problem to the protocol, which is maybe too complex. In<br>
particular, 1) the possibility of inserting CP before of the final segment<br>
of a block and 2) the possibility of sending multiple RS in response to<br>
the same CP, make the the protocol most likely more complex than<br>
necessary, and in turn, also difficult to describe.<br>
My interpretation of the text (I am not sue too) is that at the first Tx<br>
attempt, the oustanding CPs are 1) the compulsory CP that flags the latest<br>
segment; 2) any other gratuitous CP that may be inserted before the latest<br>
segment. Each of these CP triggers one or more RS, depending on the number<br>
of claims; these RSs, one recived, trigger data ReTx and new CPs,<br>
belonging to the first Re-Tx cycle and so on. It is diffiucult to explain<br>
and to implement.<br>
Now, if you remove the possibility of inserting intermediate CPs<br>
(actually, they are never inserted by ION), things start to improve. By<br>
the way, with a propagation delay that is dominant on the "radiation<br>
time", in my opinion there is not any advantage in using intermediate
CPs.<br>
Let us assume that the RTT is 6 minutes and that the radiationtime is 1s.<br>
What is the advantage of receiving an intermediate CP at, say 500ms before<br>
the last segment flagged as CP? It would just generate an RS 500ms before<br>
the last, thus reTx could start 500ms before, which seems of little help,<br>
considering the 3600 s RTT.<br>
The possibility of spreading claims on multiple RS is manageable (ION<br>
does), but it makes once again maybe more complex than necesary the<br>
algorithm, as multiple RSs means multiple CPs (the "oustanding ones"
in my<br>
interpretation) for each Re-Tx cycle.<br>
Last comment, I agree once again with you that many conditions could<br>
suggest the closing of an ongoing sessions. To those you mentioned I would<br>
add the duration of a session. I mean that in my opinion a session should<br>
have a time limit. Suppose that an RS is followed by an RAS (RS ACK), but<br>
not by any retranmissions for whatever reason (the Tx is lazy or<br>
worse...). On the Rx side a buffer plenty of data would be kept forever
as<br>
the RS was confirmed by the RAS...<br>
A second reson for a time limit, is that a block should have a lifetime,<br>
as bundles. Otherwise is pefectly possible, in the presence of a scheduled<br>
intermittent link, that a session stay frozen for hours and that during<br>
this time the content of the block, i.e. a bundle, expires. Is a non-sense<br>
that, at the next, contact LTP carry on a session whose content is to be<br>
discarded as soon as passed to BP. This could be easily avoided by<br>
associating a blocklifetime (<=bundle_lifetime) to every session.<br>
Yours,<br>
carlo<br>
<br>
<br>
<br>
________________________________________<br>
Da: SIS-DTN [sis-dtn-bounces@mailman.ccsds.org] per conto di</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">
[Felix.Flentge@esa.int]<br>
Inviato: venerdi 26 febbraio 2021 08:08<br>
A: </span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt"><br>
Oggetto: Re: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Hi Tomaso,<br>
<br>
maybe I am just confused but I have some difficulties to understand what<br>
this text actually means (in particular, what is meant by all outstanding<br>
CP segments?). It also seems dependent on the sender's strategy when to<br>
send CPs.<br>
<br>
Actually, looking at 6.13 I am wondering whether we need this at all. 6.13<br>
allows to cancel a session with RLEXC if the number of transmission<br>
problems exceeds an established limit. Maybe this could also cover<br>
re-transmission cycle limits?<br>
<br>
Thinking about this, I believe we need to leave some room for<br>
implementation-specific limits which could come in a lot of different<br>
flavours (absolute re-transmitted amount of data, relative re-transmitted<br>
amount of data, number of queued segments for re-transmission, ....). It<br>
just seems strange that for one of these 'implementation-specific' limits<br>
we have a specific error code (RXMTCYCEXC).<br>
<br>
Regards,<br>
Felix<br>
<br>
<br>
<br>
From: <</span><a href=mailto:Tomaso.deCola@dlr.de><span style=" font-size:10pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:10pt">><br>
To: <</span><a href=mailto:kscott@mitre.org><span style=" font-size:10pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:10pt">>,
<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">>,
<</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">><br>
Date: 25/02/2021 14:17<br>
Subject: RE: Telecon Notes 20210224<br>
________________________________<br>
<br>
<br>
<br>
Hi All,<br>
<br>
<br>
<br>
Concerning the point on the retransmission cycle limit, this is first<br>
appearing on RFC 5326 at the end of section 6.2.2 (beginning of page 34)<br>
and copied here below for your convenience:<br>
<br>
<br>
<br>
There may be other implementation-specific limits that may cause an<br>
<br>
LTP implementation to initiate session-cancellation procedures. One<br>
<br>
such limit is the maximum number of retransmission-cycles seen. A<br>
<br>
retransmission cycle at the LTP Sender comprises the two related<br>
<br>
events: the transmission of all outstanding CP segments from the<br>
<br>
sender, and the reception of all RS segments issued from the receiver<br>
<br>
in response to those CP segments. A similar definition would apply<br>
<br>
at the LTP Receiver but relate to the reception of the CP segments<br>
<br>
and transmission of all RS segments in response. Note that the<br>
<br>
retransmitted CP and RS segments remain part of their original<br>
<br>
retransmission-cycle. Also, a single CP segment may cause multiple<br>
<br>
RS segments to be generated if a reception report would not fit in a<br>
<br>
single data link-MTU-sized RS segment; all RS segments that are part<br>
<br>
of a reception report belong to the same retransmission cycle to<br>
<br>
which the CP segment belongs. In the presence of severe channel<br>
<br>
error conditions, many retransmission cycles may elapse before red-<br>
<br>
part transmission is deemed successful; an implementation may<br>
<br>
therefore impose a retransmission-cycle limit to shield itself from a<br>
<br>
resource-crunch situation. If an LTP sender notices the<br>
<br>
retransmission-cycle limit being exceeded, it SHOULD initiate the<br>
<br>
Cancel Session procedure (Section 6.19<</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5326*section-6.19__;Iw!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0Of3C3XV$"><span style=" font-size:10pt;color:blue"><u>https://tools.ietf.org/html/rfc5326#section-6.19</u></span></a><span style=" font-size:10pt">>),
queuing a CS segment<br>
with<br>
<br>
reason-code RXMTCYCEXC and sending a transmission-session<br>
<br>
cancellation notice (Section 7.5<</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5326*section-7.5__;Iw!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0HEpwK1l$"><span style=" font-size:10pt;color:blue"><u>https://tools.ietf.org/html/rfc5326#section-7.5</u></span></a><span style=" font-size:10pt">>)
to the client service.<br>
<br>
<br>
<br>
@Felix.Flentge@esa.int<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:10pt;color:blue"><u>mailto:Felix.Flentge@esa.int</u></span></a><span style=" font-size:10pt">>:
which aspects did<br>
you want to make normative?<br>
Best Regards,<br>
<br>
Tomaso<br>
<br>
<br>
<br>
<br>
<br>
From: SIS-DTN <</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:10pt">>
On Behalf Of Dr. Keith L<br>
Scott<br>
Sent: Mittwoch, 24. Februar 2021 17:52<br>
To: </span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:10pt"><br>
Subject: [Sis-dtn] Telecon Notes 20210224<br>
<br>
<br>
<br>
SIS-DTN Telecon<br>
<br>
<br>
<br>
LTP<br>
<br>
Took some notes in the SharePoint List here:<br>
</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/protect2.fireeye.com/v1/url?k=e9180ad5-b68360dd-e91d7b5b-ac1f6bdccbcc-1644037160e6f445&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https*3A*2F*2Fcwe.ccsds.org*2Ffm*2Fwiki*2FLists*2FSISDTN*2520LTP*2520Update*25202021*2FAllItems.aspx__;JSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0H7_IYFb$"><span style=" font-size:10pt;color:blue"><u>https://protect2.fireeye.com/v1/url?k=e9180ad5-b68360dd-e91d7b5b-ac1f6bdccbcc-1644037160e6f445&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https%3A%2F%2Fcwe.ccsds.org%2Ffm%2Fwiki%2FLists%2FSISDTN%2520LTP%2520Update%25202021%2FAllItems.aspx</u></span></a><span style=" font-size:10pt"><br>
<br>
<br>
What testing / experimentation to drive out issues?<br>
<br>
? LTP Extension Header vs. small Green Blocks to signal adaptive coding<br>
and modulation.<br>
<br>
? ESA looking to use LTP for optical; no experimentation expected for 8-12<br>
months<br>
<br>
ReTx cycle limit & Discretionary Checkpoints<br>
<br>
People to come up with draft clarifying language and we?ll review. Consult<br>
the RFC5326 text to see if we want to ?normativeize? it. Keith to
collect<br>
text from RFC5326 to provide context.<br>
<br>
BPv7<br>
<br>
Keith to build a list of items like the LTP list for discussion at next<br>
meeting.<br>
<br>
BPSec<br>
<br>
In Security WG processing; we need to notify them of status of BPSec doc<br>
in IETF.<br>
<br>
<br>
<br>
People need to review current draft and we?ll work any proposed changes
to<br>
the SEA-SEC WG ASAP:<br>
</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/tools.ietf.org/html/draft-ietf-dtn-bpsec-27__;!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0PFcyYIw$"><span style=" font-size:10pt;color:blue"><u>https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27</u></span></a><span style=" font-size:10pt"><br>
<br>
<br>
<br>
Default security context from IETF is probably not what we want in CCSDS;<br>
we might need to define our own set.<br>
<br>
<br>
<br>
ESA to start an activity on security.<br>
<br>
NM Books<br>
<br>
Links to I-Ds<br>
<br>
NM books going through IETF, about to become WG documents, changes as a<br>
result of reviews may be coming over the next 8-12 months.<br>
<br>
<br>
<br>
ICPA Need Dates for NM updated to 2028, we can prioritize the other<br>
efforts above these.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</span><a href="https://urldefense.us/v3/__https:/protect2.fireeye.com/v1/url?k=9709b22f-c892d827-970cc3a1-ac1f6bdccbcc-f25791d27360f7fe&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http*3A*2F*2Fmailman.ccsds.org*2Fpipermail*2Fsis-dtn*2Fattachments*2F20210302*2Fd9d76705*2Fattachment.htm__;JSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0JqxUv9u$"><span style=" font-size:10pt;color:blue"><u>https://protect2.fireeye.com/v1/url?k=9709b22f-c892d827-970cc3a1-ac1f6bdccbcc-f25791d27360f7fe&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.htm</u></span></a><span style=" font-size:10pt">><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: LTP_Revision_FieldLength.xlsx<br>
Type: application/octet-stream<br>
Size: 13032 bytes<br>
Desc: not available<br>
URL: <</span><a href="https://urldefense.us/v3/__https:/protect2.fireeye.com/v1/url?k=bccae9a6-e35183ae-bccf9828-ac1f6bdccbcc-7b54979228781fa5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http*3A*2F*2Fmailman.ccsds.org*2Fpipermail*2Fsis-dtn*2Fattachments*2F20210302*2Fd9d76705*2Fattachment.obj__;JSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0PFkw3YQ$"><span style=" font-size:10pt;color:blue"><u>https://protect2.fireeye.com/v1/url?k=bccae9a6-e35183ae-bccf9828-ac1f6bdccbcc-7b54979228781fa5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.obj</u></span></a><span style=" font-size:10pt">><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/x-pkcs7-signature<br>
Size: 11918 bytes<br>
Desc: S/MIME Cryptographic Signature<br>
URL: <</span><a href="https://urldefense.us/v3/__https:/protect2.fireeye.com/v1/url?k=bff2adc0-e069c7c8-bff7dc4e-ac1f6bdccbcc-9b508f0b9d5cffd5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http*3A*2F*2Fmailman.ccsds.org*2Fpipermail*2Fsis-dtn*2Fattachments*2F20210302*2Fd9d76705*2Fattachment.bin__;JSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0BKItu3v$"><span style=" font-size:10pt;color:blue"><u>https://protect2.fireeye.com/v1/url?k=bff2adc0-e069c7c8-bff7dc4e-ac1f6bdccbcc-9b508f0b9d5cffd5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.bin</u></span></a><span style=" font-size:10pt">><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list</span><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="mailto:SIS-DTN@mailman.ccsds.org"><span style=" font-size:10pt;color:blue"><u>SIS-DTN@mailman.ccsds.org</u></span></a><span style=" font-size:10pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/protect2.fireeye.com/v1/url?k=6aec0843-3577624b-6ae979cd-ac1f6bdccbcc-d9e5a427bdf963e1&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https*3A*2F*2Fmailman.ccsds.org*2Fcgi-bin*2Fmailman*2Flistinfo*2Fsis-dtn__;JSUlJSUlJQ!!PvBDto6Hs4WbVuu7!cL3DsE2xS9xz2_TRbtEyfLQVXWoa5aWdzUTkBJL6HAWXwdtXadMD7FGMImNP074_0Mlq9V3V$"><span style=" font-size:10pt;color:blue"><u>https://protect2.fireeye.com/v1/url?k=6aec0843-3577624b-6ae979cd-ac1f6bdccbcc-d9e5a427bdf963e1&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</u></span></a><span style=" font-size:10pt"><br>
<br>
<br>
------------------------------<br>
<br>
End of SIS-DTN Digest, Vol 117, Issue 3<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>
<br>
<br>