[Sis-dtn] Telecon Notes 20210224

[Tomaso.deCola at dlr.de]

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/20210225/1106f0be/attachment.htm>