[Sis-dtn] RE: JAXA RID on LTP -- LTP and Sequential Delivery

[Tomaso.deCola at dlr.de]

As pointed out by Scott, I think current description of LTP is complete for what regards the services and related specification. LTPCLA specification is also quite clear in this respect. Further to this, section 2.3.2 already illustrates the services not supported by LTP, such as the in-order delivery. Maybe you can insert here the note you are suggesting, to show how in-order delivery might be ensured by protocol layers running on top of LTP, though not requiring any interface support from LTP.

Best Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san

From: sis-dtn-bounces at mailman.ccsds.org [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Burleigh, Scott C (312G)
Sent: Thursday, August 07, 2014 12:30 AM
To: Scott, Keith L.; sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] RE: JAXA RID on LTP -- LTP and Sequential Delivery

Keith, you're right, there is nothing in the LTP specification that ever compels a receiving LTP engine to deliver green data in transmission order rather than reception order (i.e., to reorder received green segments).

Scott
________________________________
From: sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> [sis-dtn-bounces at mailman.ccsds.org] on behalf of Scott, Keith L. [kscott at mitre.org]
Sent: Wednesday, August 06, 2014 10:00 AM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] JAXA RID on LTP -- LTP and Sequential Delivery
Greetings,

Here's my second question w.r.t. the JAXA RIDs.  This one has to do with sequential (which I interpret to mean in-order) delivery with LTP.

JAXA-PRA1415-09 states:

Sequential transportation is an essential function to control devices and
LTP can provide sequential transportation over single hop with certain parameter of RFC5326.
This aspect should be described in this document because it is an important potential of LTP.

Is there something about RFC5326 that I missed?  The Red-part data of a block is delivered atomically (so data is in-order within the Red Part I suppose) but I don't think LTP guarantees anything beyond that.  In particular:


*       The Red Part of a block might be delivered before, after, or in the middle of Green Data for that block.

*       The relative arrival times of Red and Green data from multiple blocks transmitted simultaneously are undefined by the spec.

The only way I know of to ensure in-order arrival of data would be to use only red data and to wait for the report indicating complete reception of one block before completing transmission of the next (red) block.  That's possible, but it would be an implementation decision not part of the specification.

Am I missing something here?



JAXA-PRA1415-10 states:
To control sequential transportation over multi-hop communication,
RFC and Red Book should contain the description of the interface and
rule as SAP of LTP like the option of Green-Data.
LTP can naturally support single hop  sequential transportation,
but multi hop transportation needs some handling of hop-to-hop interaction.

The Delay-Tolerant Payload Conditioning (DTPC) in the BP-for-CCSDS book provides an in-order delivery service.  As with the above (09) I don't think there's anything in the LTP spec (RFC5326 or LTP-for-CCSDS) that says anything about providing in-order delivery of  LTP blocks (or Green-part segments).



Does anyone interpret these differently?  If not then I'm going to suggest adding a NOTE specifically stating that in-order delivery is not an LTP service, but multi-hop (or single-hop, if BP is deployed on both ends of the link) in-order delivery is achievable with BP and DTPC.

                        --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20140807/1fc3f3d4/attachment.html>