[Sis-dtn] Telecon Notes 20210224

[Felix.Flentge at esa.int]

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), queuing a CS segment with
   reason-code RXMTCYCEXC and sending a transmission-session
   cancellation notice (Section 7.5) to the client service.
 
@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/1083e444/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/1083e444/attachment-0001.bin>