[Sis-dtn] LTP High, Medium, Low Data Rate Profiles
Jeremy.Mayer at dlr.de
Jeremy.Mayer at dlr.de
Tue Mar 2 08:18:47 UTC 2021
Felix,
Thanks for starting this! A couple of notes on my side: I think that we should keep the medium profile, since that's where a (probable) majority of missions will fall in the medium-term.
Additionally, we might consider the usage of 2 bytes for the client service ID within the medium data rate profile: the way that I consider it, missions using that profile are more likely than not using it for everything (TM, TC, various payload flows, DTN, etc). Allowing that second byte allows us a ton of flexibility. Alternately, we can keep the client service ID at one byte, and add a second byte to the session originator. This has the same result, but ensures that the segment header length is identical for both medium & high-rate applications.
Thanks,
Jeremy
________________________________
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of 구철회 <chkoo at kari.re.kr>
Sent: Tuesday, March 2, 2021 8:57:46 AM
To: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] LTP High, Medium, Low Data Rate Profiles
Greetings all,
Let me have a note to a situational difference when bundle sizes or ltp block sizes are being discussed.
1) I think bundle sizes/ltp block sizes can be (really) big between dtn relay nodes that are supposed to have enough resources, e.g., high speed processor, big storage and fast comm, that normally ground stations equip. Huge bundle sizes or ltp block sizes make sense and can be supported by specification document.
2) However, a rover or lander on a long-distance planet like Mars have different situation. Simply, there are chances that the rover and lander can't service the retransmission request of a really huge bundles regardless of CFDP or bundle blocks because of lack of on-board resources supporting telecommunications with the most adjacent dtn nodes (relay orbiter or ground station).
Please consider low power, or temporarily handicapped (processor power or radio power) system in space segment during specification update.
Best,
Cheol
----------------------------------------------------------------------
Message: 1
Date: Tue, 2 Mar 2021 07:56:27 +0100
From: Felix.Flentge at esa.int
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] LTP High, Medium, Low Data Rate Profiles
Message-ID:
<OF1E55830F.B2C9A54F-ONC125868C.002433AD-C125868C.002620EF at esa.int>
Content-Type: text/plain; charset="iso-8859-1"
Dear All,
I had a first go at defining some profiles for high, medium and low data rates.
There a certainly some choices to discuss. In particular, I have limited
the client ID and the service ID to just one byte each as it seemed more
then sufficient for a protocol operating on a single link.
I am also wondering whether the medium profile makes sense or whether it
would be enough to have the low and the high one.
I think we shall discuss in one of the next meetings (maybe after we have
started the BP/BPSEC discussions).
Related to the points below:
1) LTP Block Size: I assume that Bundle / LTP Blocks can be rather large
(4 GB for the high data rate). This is to reduce overheads, limit the
number of bundles (eg, if we want to have reports or custody transfer) and
just seems typically easier to handle. Also, as we have seen for CFDP,
on-board implementations may have rather low limits on the number of
parallel sessions.
2) The CFDP point is an important one: it seems that CFDP over BP is not
formally specified in CCSDS (please correct me if I am wrong). The
straight-forward approach to encapsulate each CFDP PDU in a separate
bundle is not ideal because of the overheads (I will never be able to
convince our missions to do something like that). I see two options here:
a) aggregating several CFDP PDU (possibly also from different
transactions) in a single bundle; I think we would need to define this
somewhere (similar to the CFDP / Encapsulation book)
b) we would allow really large file segments in CFDP; however, this would
require a change in the CFDP standard
I personally would tend to 2)a). I would not like to put DTCP in here as
its services (besides aggregation) are not required and it would add yet
another protocol.
[maybe this discussion would belong more to the CFDP WG]
Regards,
Felix
From: <Tomaso.deCola at dlr.de>
To: <scott.c.burleigh at jpl.nasa.gov>, <Felix.Flentge at esa.int>
Cc: <sis-dtn at mailman.ccsds.org>, <carlo.caini at unibo.it>
Date: 26/02/2021 17:38
Subject: RE: [Sis-dtn] Telecon Notes 20210224
Hi Scott,
You are right. In principle one could even use DTPC, I think, to aggregate
multiple ADUs (i.e., CFDP PDUs in this case) to have a larger bundle. I
was just reasoning on the scenario described from Felix, requiring a large
session that I?ve translated into large block, to scope it in view of the
discussion we did early today about the retransmission cycle concept of
LTP.
Best,
Tomaso
From: Burleigh, Scott C (US 312B) <scott.c.burleigh at jpl.nasa.gov>
Sent: Freitag, 26. Februar 2021 17:16
To: Cola, Tomaso de <Tomaso.deCola at dlr.de>; Felix.Flentge at esa.int
Cc: sis-dtn at mailman.ccsds.org; carlo.caini at unibo.it
Subject: RE: [Sis-dtn] Telecon Notes 20210224
I don?t think that?s a constraint. First, we expect CFDP normally to run
over BP, and BP to be the LTP client; in that formulation, LTP blocks
could be quite large because multiple CFDP file data PDUs might be
aggregated into a single bundle payload. (ION CFDP/BP doesn?t work that
way, but it probably should; it?s usually advantageous for bundles to be
large.) Second, even if CFDP were the LTP client, the CFDP UT adapter for
LTP might well aggregate multiple CFDP file data PDUs into a single LTP
block ? an application-defined ?service data aggregation? mechanism as
we?ve been discussing.
Scott
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of
Tomaso.deCola at dlr.de
Sent: Friday, February 26, 2021 5:02 AM
To: Felix.Flentge at esa.int
Cc: sis-dtn at mailman.ccsds.org; carlo.caini at unibo.it
Subject: [EXTERNAL] Re: [Sis-dtn] Telecon Notes 20210224
Ok about the large session duration, but how big would LTP blocks be if we
take into considerations that CFDP PDUs can carry at most 64kybtes (if I?m
not mistaken)?
Tomaso
From: Felix.Flentge at esa.int <Felix.Flentge at esa.int>
Sent: Freitag, 26. Februar 2021 12:29
To: Cola, Tomaso de <Tomaso.deCola at dlr.de>
Cc: carlo.caini at unibo.it; sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] Telecon Notes 20210224
Yes,
the scenario I had in mind is deep space to Earth (RTT in the order of
minutes). Here, on-board implementations might want to have rather large
session durations to limit the number of parallel sessions (the on-board
CFDP implementations I have seen allow only a few parallel transactions
which requires to reduce the latency for completing the transactions).
The idea of sending RS without an CP is interesting (similar to CFDP async
NAK), it could maybe even triggered after some "inactivity" timeout.
Regards,
Felix
From: <Tomaso.deCola at dlr.de>
To: <carlo.caini at unibo.it>, <Felix.Flentge at esa.int>
Cc: <sis-dtn at mailman.ccsds.org>
Date: 26/02/2021 11:37
Subject: RE: [Sis-dtn] Telecon Notes 20210224
Hi Carlo,
My understanding from Felix's comment was about a long session duration,
i.e. if we have to transfer a very long LTP block (say 10 seconds duration
against 1s RTT), then probably waiting too long for the retransmission may
be problematic if the sender is resource-constrained. The receiver side,
if on ground, probably does not have too many problems in keeping some
buffer allocated for long. If we are referring to space-to-space the
situation can certainly be different, but in such a case I'm tempted to
assumed almost error-free transmission. I'm in any case waiting for Felix
clarification on the scenario he had in mind here ?
Regards,
Tomaso
-----Original Message-----
From: Carlo Caini <carlo.caini at unibo.it>
Sent: Freitag, 26. Februar 2021 11:31
To: Felix.Flentge at esa.int
Cc: sis-dtn at mailman.ccsds.org; Cola, Tomaso de <Tomaso.deCola at dlr.de>
Subject: 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://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://protect2.fireeye.com/v1/url?k=e9180ad5-b68360dd-e91d7b5b-ac1f6bdccbcc-1644037160e6f445&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https%3A%2F%2Fcwe.ccsds.org%2Ffm%2Fwiki%2FLists%2FSISDTN%2520LTP%2520Update%25202021%2FAllItems.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: <https://protect2.fireeye.com/v1/url?k=9709b22f-c892d827-970cc3a1-ac1f6bdccbcc-f25791d27360f7fe&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LTP_Revision_FieldLength.xlsx
Type: application/octet-stream
Size: 13032 bytes
Desc: not available
URL: <https://protect2.fireeye.com/v1/url?k=bccae9a6-e35183ae-bccf9828-ac1f6bdccbcc-7b54979228781fa5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.obj>
-------------- 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: <https://protect2.fireeye.com/v1/url?k=bff2adc0-e069c7c8-bff7dc4e-ac1f6bdccbcc-9b508f0b9d5cffd5&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20210302%2Fd9d76705%2Fattachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://protect2.fireeye.com/v1/url?k=6aec0843-3577624b-6ae979cd-ac1f6bdccbcc-d9e5a427bdf963e1&q=1&e=341335a7-9dd4-4d08-8faf-86c39bb6d4d2&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn
------------------------------
End of SIS-DTN Digest, Vol 117, Issue 3
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210302/526e249c/attachment-0001.htm>
More information about the SIS-DTN
mailing list