[Sis-dtn] Telecon Notes 20210224

Fri Feb 26 09:05:09 UTC 2021

Hi Carlo,

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).

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).

Regards,
Felix

From:   "Carlo Caini" <carlo.caini at unibo.it>
To:     "Felix.Flentge at esa.int" <Felix.Flentge at esa.int>, 
"Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>
Cc:     "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date:   26/02/2021 09:01
Subject:        RE: [Sis-dtn] Telecon Notes 20210224

Dear Felix,
    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.
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.
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.
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.
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...
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.
Yours,
   carlo 

________________________________________
Da: SIS-DTN [sis-dtn-bounces at mailman.ccsds.org] per conto di 
Felix.Flentge at esa.int [Felix.Flentge at esa.int]
Inviato: venerdì 26 febbraio 2021 08:08
A: Tomaso.deCola at dlr.de
Cc: sis-dtn at mailman.ccsds.org
Oggetto: Re: [Sis-dtn] Telecon Notes 20210224

Hi Tomaso,

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.

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?

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).

Regards,
Felix

From:        <Tomaso.deCola at dlr.de>
To:        <kscott at mitre.org>, <sis-dtn at mailman.ccsds.org>, 
<Felix.Flentge at esa.int>
Date:        25/02/2021 14:17
Subject:        RE: Telecon Notes 20210224
________________________________

Hi All,

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:

There may be other implementation-specific limits that may cause an

   LTP implementation to initiate session-cancellation procedures.  One

   such limit is the maximum number of retransmission-cycles seen.  A

   retransmission cycle at the LTP Sender comprises the two related

   events: the transmission of all outstanding CP segments from the

   sender, and the reception of all RS segments issued from the receiver

   in response to those CP segments.  A similar definition would apply

   at the LTP Receiver but relate to the reception of the CP segments

   and transmission of all RS segments in response.  Note that the

   retransmitted CP and RS segments remain part of their original

   retransmission-cycle.  Also, a single CP segment may cause multiple

   RS segments to be generated if a reception report would not fit in a

   single data link-MTU-sized RS segment; all RS segments that are part

   of a reception report belong to the same retransmission cycle to

   which the CP segment belongs.  In the presence of severe channel

   error conditions, many retransmission cycles may elapse before red-

   part transmission is deemed successful; an implementation may

   therefore impose a retransmission-cycle limit to shield itself from a

   resource-crunch situation.  If an LTP sender notices the

   retransmission-cycle limit being exceeded, it SHOULD initiate the

   Cancel Session procedure (Section 6.19<
https://tools.ietf.org/html/rfc5326#section-6.19>), queuing a CS segment 
with

   reason-code RXMTCYCEXC and sending a transmission-session

   cancellation notice (Section 7.5<
https://tools.ietf.org/html/rfc5326#section-7.5>) to the client service.

@Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>: which aspects did 
you want to make normative?
Best Regards,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L 
Scott
Sent: Mittwoch, 24. Februar 2021 17:52
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] Telecon Notes 20210224

SIS-DTN Telecon

LTP

Took some notes in the SharePoint List here:

https://cwe.ccsds.org/fm/wiki/Lists/SISDTN%20LTP%20Update%202021/AllItems.aspx

What testing / experimentation to drive out issues?

? LTP Extension Header vs. small Green Blocks to signal adaptive coding 
and modulation.

? ESA looking to use LTP for optical; no experimentation expected for 8-12 
months

ReTx cycle limit & Discretionary Checkpoints

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.

BPv7

Keith to build a list of items like the LTP list for discussion at next 
meeting.

BPSec

In Security WG processing; we need to notify them of status of BPSec doc 
in IETF.

People need to review current draft and we?ll work any proposed changes to 
the SEA-SEC WG ASAP:

https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27

Default security context from IETF is probably not what we want in CCSDS; 
we might need to define our own set.

ESA to start an activity on security.

NM Books

Links to I-Ds

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.

ICPA Need Dates for NM updated to 2028,  we can prioritize the other 
efforts above these.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210226/68717467/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11918 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210226/68717467/attachment-0001.bin>