[Sis-dtn] Telecon Notes 20210224

Thu Apr 8 12:24:13 UTC 2021

be careful with pooling - can get into some lockup scenarios (experience
with ARPANET).

v

On Wed, Apr 7, 2021 at 6:52 PM Burleigh, Scott C (US 312B) via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> 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!
>
> 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.
>
> Scott
>
> -----Original Message-----
> From: Carlo Caini <carlo.caini at unibo.it>
> Sent: Wednesday, April 7, 2021 1:15 PM
> To: Burleigh, Scott C (US 312B) <scott.c.burleigh at jpl.nasa.gov>;
> Felix.Flentge at esa.int
> Cc: sis-dtn at mailman.ccsds.org
> Subject: [EXTERNAL] RE: [Sis-dtn] Telecon Notes 20210224
>
> Dear Scott,
>     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.
> 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.
> 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.
> Yours,
>    Carlo
> ________________________________________
> Da: Burleigh, Scott C (US 312B) [scott.c.burleigh at jpl.nasa.gov]
> Inviato: mercoledì 7 aprile 2021 19:37
> A: Carlo Caini; Felix.Flentge at esa.int
> Cc: sis-dtn at mailman.ccsds.org
> Oggetto: RE: [Sis-dtn] Telecon Notes 20210224
>
> A couple of remarks:
>
> 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.
>
> 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.
>
> 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.)
>
> Scott
>
> -----Original Message-----
> From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Carlo Caini
> Sent: Friday, February 26, 2021 2:31 AM
> To: Felix.Flentge at esa.int
> Cc: sis-dtn at mailman.ccsds.org
> Subject: [EXTERNAL] Re: [Sis-dtn] Telecon Notes 20210224
>
> Dear Felix,
>     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.
> 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...
>
> 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).
> Yours,
>   Carlo
>
>
> ________________________________________
> Da: Felix.Flentge at esa.int [Felix.Flentge at esa.int]
> Inviato: venerdì 26 febbraio 2021 10:05
> A: Carlo Caini
> Cc: sis-dtn at mailman.ccsds.org; Tomaso.deCola at dlr.de
> Oggetto: RE: [Sis-dtn] Telecon Notes 20210224
>
> 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://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-6.19__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-sy402NXl$
> >), queuing a CS segment with
>
>   reason-code RXMTCYCEXC and sending a transmission-session
>
>   cancellation notice (Section 7.5<
> https://urldefense.us/v3/__https://tools.ietf.org/html/rfc5326*section-7.5__;Iw!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s1rm8pEy$
> >) 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://urldefense.us/v3/__https://cwe.ccsds.org/fm/wiki/Lists/SISDTN*20LTP*20Update*202021/AllItems.aspx__;JSUl!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s4ojz1VX$
>
> 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://urldefense.us/v3/__https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s9rlVfia$
>
>
>
> 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.
>
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
>
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!ch8g7EEz_e1eMBetbP7PTJqPefb5u01juhSStaKt4RA44_D6-QcvmVew1_M1m83-s0zj8bBY$
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210408/264b6e17/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210408/264b6e17/attachment-0001.bin>