<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">my views on the
topics below:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Intermediate CPs:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">I would agree
to remove those. In cases where you might want to use those, you could
probably also just use shorter LTP Blocks (with eventual bundle fragmentation
if you are running as a BP convergence layer).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Session Timer/Cancellation:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">CCSDS LTP already
has the CancelTransmission.request and CancelReception.request which can
be used by the protocol layer above (eg, BP once TTL is reached).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Block Length:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">While I see the
value to have the block length available to reserve the right amount of
memory there might also be other options for implementation (eg, store
segments and reconstruct full block once everything is received or just
'stream' it to the upper layer). To me it does not seem strictly necessary
for high-performance implementations and it is probably very much related
to the memory architecture and the specific way you can access it. </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">"Vint
Cerf" <vint@google.com></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Burleigh,
Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Carlo
Caini" <carlo.caini@unibo.it>, "Felix.Flentge@esa.int"
<Felix.Flentge@esa.int>, "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">08/04/2021
14:24</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] Telecon Notes 20210224</span>
<br>
<hr noshade>
<br>
<br>
<br><span style=" font-size:12pt">be careful with pooling - can get into
some lockup scenarios (experience with ARPANET).</span>
<br>
<br><span style=" font-size:12pt">v</span>
<br>
<br>
<br><span style=" font-size:12pt">On Wed, Apr 7, 2021 at 6:52 PM Burleigh,
Scott C (US 312B) via SIS-DTN <</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>
wrote:</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Hi,
Carlo. Excellent point on the simpler session timeout mechanism:
LTP could simply expose a session cancellation function in its API, which
BP could invoke upon the TTL expiration of the last remaining bundle in
the block. In a sense this is just moving the problem around rather
than solving it, because it leaves open the question of selecting an appropriate
TTL interval for each bundle. But I think the bundle delivery time
estimation algorithm is a good way to select TTL intervals as well!<br>
<br>
I see what you're saying about pooling block retention resources and I
agree it could be valuable. One of the extension mechanisms we discussed
this morning could be used for this purpose. I'm still bothered by
the potential for losing the segment(s) carrying this information and thereby
defeating the optimization, but maybe that's an engineering trade-off that
ends up being harmless.<br>
<br>
Scott<br>
<br>
-----Original Message-----<br>
From: Carlo Caini <</span><a href=mailto:carlo.caini@unibo.it target=_blank><span style=" font-size:12pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:12pt">>
<br>
Sent: Wednesday, April 7, 2021 1:15 PM<br>
To: Burleigh, Scott C (US 312B) <</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov target=_blank><span style=" font-size:12pt;color:blue"><u>scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:12pt">>;
</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><br>
Subject: [EXTERNAL] RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Dear Scott, <br>
Thank you for your informative remarks. I fully agree with
the possible removal of intermediate CPs. We too have not implemented them
in the LTP version we are developing.<br>
I agree also on session timer, which would protect also against possible
stalls, should one of the two node stop operating (e.g. if the sender crashes
after having sent an intemediate RAS but before the CP following the re-tx
segments, the receiver should stall forever). There is another case, trivial
to calculate, which could be used as ceiling value: in a block there are
bundles, and bundles have a lifetime. The highest lifetime of the bundles
contained in a block could be safely used as a ceiling for the session
deadline. However, in this case, it could be the BP to tell LTP to cancel
an ongoing session. <br>
Concerning block lenght, I agree with you on the max lenght constraint.
However, to know in advance the lenght of a block could be still advantageous
becouse this information could be used to reserve the right amount of space
in RAM for the Rx session buffer, not a single byte more than necessary.
This way, the total amount of RAM avaiulable for LTP at Rx side, could
be pooled among all on going sessions, without putting any hard limit on
the max number of concurrent Rx sessions. For example, given a total amount
of RAM available, we could use this to fit 10 large blocks, or 100 small
blocks, or whatever intermediate combination. This could add flexibility
when speed at Rx is necessary (i.e. RAM compulsory). This would be not
alternative to fragmenting very large bundles which would be most likely
necessary anyway (we can neither use all RAM for a giant block, nor discover
after having saturated all mememory available that we are sorry but we
cannot accomodate any more bytes!). A possible solution could be to insert
the block lenght in an extension, as an option, to be activated when there
are no problems of bandwidth available, as in optical links.<br>
Yours,<br>
Carlo<br>
________________________________________<br>
Da: Burleigh, Scott C (US 312B) [</span><a href=mailto:scott.c.burleigh@jpl.nasa.gov target=_blank><span style=" font-size:12pt;color:blue"><u>scott.c.burleigh@jpl.nasa.gov</u></span></a><span style=" font-size:12pt">]<br>
Inviato: mercoledì 7 aprile 2021 19:37<br>
A: Carlo Caini; </span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><br>
Oggetto: RE: [Sis-dtn] Telecon Notes 20210224<br>
<br>
A couple of remarks:<br>
<br>
As you have guessed, ION doesn't insert intermediate CPs because they would
have introduced yet more complexity for limited advantage. I definitely
would not argue against removing them from the protocol.<br>
<br>
Session timer is a good idea, though not really trivial to implement.
The right way to compute the timer interval, I think, would be to consult
the contact plan and use techniques similar to the ones developed by Nikolaos
Bezirgiannidis for bundle delivery time estimation. This would be
more accurate than a user-provided guess, and both ends of the session
could make this computation independently; there would be no need for signaling.<br>
<br>
Signaling block length is certainly attractive, but I can't think of a
clean way to do it. The first segment of the block is just as likely
to be lost in transmission as the last. Block length could be included
in every Nth data segment, to minimize the risk of losing it, but that
adds transmission overhead that increases with decreasing values of N.
I think a better approach might be simply to set a block size limit by
management; when a bundle is to be inserted into a block whose remaining
capacity is less than the size of the bundle, fragment the bundle.
(We already have to do that for the UDP convergence-layer adapter anyway.)<br>
<br>
Scott<br>
<br>
-----Original Message-----<br>
From: SIS-DTN <</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>
On Behalf Of Carlo Caini<br>
Sent: Friday, February 26, 2021 2:31 AM<br>
To: </span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><br>
Subject: [EXTERNAL] Re: [Sis-dtn] Telecon Notes 20210224<br>
<br>
Dear Felix,<br>
intermediate CPs can be useful, in theory, if radiation time
>> RTT, as interpreted by Tomaso. Assuming as a rule of thumb that
the radiation time of one bundle does not exceeds 1s, intermediate CPs
have no advantages starting from Moon communications and on. You could
still have some advantages on shorter RTTs, as with LEOs.<br>
However you cannot release anything at Rx side, until the whole block has
been received, which means that in the best case you can save only the
time elapsed between the intermeiate CP (let me assume for the sake of
similicity we have only one at a half of the block) and the last. This
is equal to a half radiation time, and this only under the conditions that
you have lasses only on the first half of the block and not on the second
one. This bacause in the latter case you should wait for the RS triggered
by the final CP to start retx of losses, thus the first intermediate CP
would be useless in this case. This is why I think these intermediate CPs
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 vision.
By the way, I suppose it should be easy to implement. This time could also
be "advertised" to the Rx side, by means of a segment extension,
inserted on the first segment (or on all). On the same line, I think that
it could be useful to let the Rx know the dimension of the block asap.
This could allow the Rx to cancel a too long (in size) session in a proactive
way, without waiting to have received too many segments. To know the lenght
in advance could also help to reserve to the Rx session buffer the right
amount of space (provided that there is sufficient space), etc. Last, it
could also help when the last segment, that flagged as a CP, is lost. In
this case the session stalls for an RTO, because the receiver do nothing
until the retranmitted CP arrives (after one RTO, as said, i.e. 6 minutes
from Earth to Mars in the best case). By knowing in advance the block lenght,
it would be strightforward to force the transmission of a gratuitous RS
after a much shorter inter-segment timer has elapsed (it could be be set
equal to the expected radiation time of the block).<br>
Yours,<br>
Carlo<br>
<br>
<br>
________________________________________<br>
Da: </span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">
[</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">]<br>
Inviato: venerdì 26 febbraio 2021 10:05<br>
A: Carlo Caini<br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">;
</span><a href=mailto:Tomaso.deCola@dlr.de target=_blank><span style=" font-size:12pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:12pt"><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
where the duration of the session >> RTT (could reduce overall latency,
on-board memory could be freed).<br>
<br>
I certainly like the idea of a blocklifetime. It could maybe even be an
optional parameter of the Transmission.request (which might need some 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 target=_blank><span style=" font-size:12pt;color:blue"><u>carlo.caini@unibo.it</u></span></a><span style=" font-size:12pt">><br>
To: "</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">"
<</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">>,
"</span><a href=mailto:Tomaso.deCola@dlr.de target=_blank><span style=" font-size:12pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:12pt">"
<</span><a href=mailto:Tomaso.deCola@dlr.de target=_blank><span style=" font-size:12pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:12pt">><br>
Cc: "</span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">"
<</span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">><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 ascribe the problem to the protocol, which is maybe too complex.
In particular, 1) the possibility of inserting CP before of the final segment
of a block and 2) the possibility of sending multiple RS in response to
the same CP, make the the protocol most likely more complex than 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
attempt, the oustanding CPs are 1) the compulsory CP that flags the latest
segment; 2) any other gratuitous CP that may be inserted before the latest
segment. Each of these CP triggers one or more RS, depending on the number
of claims; these RSs, one recived, trigger data ReTx and new CPs, belonging
to the first Re-Tx cycle and so on. It is diffiucult to explain and to
implement.<br>
Now, if you remove the possibility of inserting intermediate CPs (actually,
they are never inserted by ION), things start to improve. By the way, with
a propagation delay that is dominant on the "radiation time",
in my opinion there is not any advantage in using intermediate CPs. Let
us assume that the RTT is 6 minutes and that the radiationtime is 1s. What
is the advantage of receiving an intermediate CP at, say 500ms before the
last segment flagged as CP? It would just generate an RS 500ms before the
last, thus reTx could start 500ms before, which seems of little help, considering
the 3600 s RTT.<br>
The possibility of spreading claims on multiple RS is manageable (ION does),
but it makes once again maybe more complex than necesary the algorithm,
as multiple RSs means multiple CPs (the "oustanding ones" in
my interpretation) for each Re-Tx cycle.<br>
Last comment, I agree once again with you that many conditions could suggest
the closing of an ongoing sessions. To those you mentioned I would add
the duration of a session. I mean that in my opinion a session should have
a time limit. Suppose that an RS is followed by an RAS (RS ACK), but not
by any retranmissions for whatever reason (the Tx is lazy or worse...).
On the Rx side a buffer plenty of data would be kept forever as the RS
was confirmed by the RAS...<br>
A second reson for a time limit, is that a block should have a lifetime,
as bundles. Otherwise is pefectly possible, in the presence of a scheduled
intermittent link, that a session stay frozen for hours and that during
this time the content of the block, i.e. a bundle, expires. Is a non-sense
that, at the next, contact LTP carry on a session whose content is to be
discarded as soon as passed to BP. This could be easily avoided by associating
a blocklifetime (<=bundle_lifetime) to every session.<br>
Yours,<br>
carlo<br>
<br>
<br>
<br>
________________________________________<br>
Da: SIS-DTN [</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">]
per conto di </span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">
[</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">]<br>
Inviato: venerdì 26 febbraio 2021 08:08<br>
A: </span><a href=mailto:Tomaso.deCola@dlr.de target=_blank><span style=" font-size:12pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:12pt"><br>
Cc: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><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
this text actually means (in particular, what is meant by all outstanding
CP segments?). It also seems dependent on the sender's strategy when to
send CPs.<br>
<br>
Actually, looking at 6.13 I am wondering whether we need this at all. 6.13
allows to cancel a session with RLEXC if the number of transmission problems
exceeds an established limit. Maybe this could also cover re-transmission
cycle limits?<br>
<br>
Thinking about this, I believe we need to leave some room for implementation-specific
limits which could come in a lot of different flavours (absolute re-transmitted
amount of data, relative re-transmitted amount of data, number of queued
segments for re-transmission, ....). It just seems strange that for one
of these 'implementation-specific' limits 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 target=_blank><span style=" font-size:12pt;color:blue"><u>Tomaso.deCola@dlr.de</u></span></a><span style=" font-size:12pt">><br>
To: <</span><a href=mailto:kscott@mitre.org target=_blank><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">>,
<</span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>,
<</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">><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 appearing
on RFC 5326 at the end of section 6.2.2 (beginning of page 34) 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><a href="https://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-6.19__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-sy402NXl$" target=_blank><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-6.19__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-sy402NXl$</u></span></a><span style=" font-size:12pt">
>), queuing a CS segment with<br>
<br>
reason-code RXMTCYCEXC and sending a transmission-session<br>
<br>
cancellation notice (Section 7.5<</span><a href="https://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-7.5__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s1rm8pEy$" target=_blank><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-7.5__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s1rm8pEy$</u></span></a><span style=" font-size:12pt">
>) to the client service.<br>
<br>
<br>
<br>
@</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt"><mailto:</span><a href=mailto:Felix.Flentge@esa.int target=_blank><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">>:
which aspects did 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" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>
On Behalf Of Dr. Keith L Scott<br>
Sent: Mittwoch, 24. Februar 2021 17:52<br>
To: </span><a href="mailto:sis-dtn@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><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:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https://cwe.ccsds.org/fm/wiki/Lists/SISDTN*20LTP*20Update*202021/AllItems.aspx__;JSUl!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s4ojz1VX$" target=_blank><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://cwe.ccsds.org/fm/wiki/Lists/SISDTN*20LTP*20Update*202021/AllItems.aspx__;JSUl!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s4ojz1VX$</u></span></a><span style=" font-size:12pt"><br>
<br>
What testing / experimentation to drive out issues?<br>
<br>
. LTP Extension Header vs. small Green Blocks to signal adaptive coding
and modulation.<br>
<br>
. ESA looking to use LTP for optical; no experimentation expected for 8-12
months<br>
<br>
ReTx cycle limit & Discretionary Checkpoints<br>
<br>
People to come up with draft clarifying language and we'll review.
Consult the RFC5326 text to see if we want to 'normativeize' it.
Keith to collect 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
meeting.<br>
<br>
BPSec<br>
<br>
In Security WG processing; we need to notify them of status of BPSec doc
in IETF.<br>
<br>
<br>
<br>
People need to review current draft and we'll work any proposed changes
to the SEA-SEC WG ASAP:<br>
</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s9rlVfia$" target=_blank><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s9rlVfia$</u></span></a><span style=" font-size:12pt"><br>
<br>
<br>
<br>
Default security context from IETF is probably not what we want in CCSDS;
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
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
efforts above these.<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="mailto:SIS-DTN@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>SIS-DTN@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s0zj8bBY$" target=_blank><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s0zj8bBY$</u></span></a><span style=" font-size:12pt"><br>
_______________________________________________<br>
SIS-DTN mailing list</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="mailto:SIS-DTN@mailman.ccsds.org" target=_blank><span style=" font-size:12pt;color:blue"><u>SIS-DTN@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn" target=_blank><span style=" font-size:12pt;color:blue"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</u></span></a></p>
<br>
<br>
<br><span style=" font-size:12pt">-- </span>
<br><span style=" font-size:12pt">Please send any postal/overnight deliveries
to:</span>
<br><span style=" font-size:12pt">Vint Cerf</span>
<br><span style=" font-size:12pt">1435 Woodhurst Blvd </span>
<br><span style=" font-size:12pt">McLean, VA 22102</span>
<br><span style=" font-size:12pt">703-448-0965</span>
<br>
<br><span style=" font-size:12pt">until further notice</span>
<br>
<br>
<br>
<br>
<br>