[Sis-dtn] RE: Proposed RID resolutions to LTP Book

[Scott, Keith L.]

Scott,

OK, I may have gone a bit over.  I agree with you that I thought all of the material in the proposed resolutions was implied by the rest of the book, but I also agree with Gian-Paolo that if we can add some clarity for explicitness, that can't hurt.

I am concerned with your comment regarding the 'An LTP implementation could be written...' bullet.  I think what I'd like to propose is the following resolution that *leaves off* the notion that one could build an entire LTP implementation that stuck with only one outstanding red-part.  If the RIDder really feels strongly about it we can re-introduce the text of the 'LTP implementation' bullet (modified version below the word snippet).

[cid:image004.jpg at 01CFDE35.77261090]

Proposed third NOTE bullet *if necessary*:
*       An LTP implementation could be written to maintain order between the red parts of different LTP blocks by limiting the number of concurrent outstanding LTP blocks to one.  While such an implementation would be conformant, it would probably have adverse impact on performance.


                        --keith

From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Thursday, October 02, 2014 12:59 AM
To: Scott, Keith L.; sis-dtn at mailman.ccsds.org
Subject: RE: Proposed RID resolutions to LTP Book

Keith, if you think we have to say this sort of thing to get the book published, well, I can live with it.  But it's unfortunate.

I don't see any reason to make the first change shown here.  The original text is correct.

The first bullet under NOTES is correct, and I don't object strongly to inserting it.  It should be obvious to anyone who has read the document, but maybe it's not.

I'm fine with removing the "For real-time commanding" text as shown in the second bullet, but the text replacing the word "order" is (I think) more confusing than what was originally written.  At minimum, let's delete the "red parts of" text from that revision.

The text in the third bullet is true, I guess, but I see no benefit in inserting it.  The most that could accomplish would be the development of an extremely poor-performing LTP implementation that, when well publicized, will provide convincing evidence that LTP is a lousy protocol.

The fourth bullet is okay, but I think a better approach would be a NOTE replacing the second and third bullets that says something like "If your LTP-based application requires in-order delivery of service data units, consider using the delay-tolerant payload conditioning (DTPC) service of the Bundle Protocol."  Everything else we're saying here amounts to hitching a snowplow to a motorcycle.

Scott

From: sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Wednesday, October 01, 2014 11:02 AM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] Proposed RID resolutions to LTP Book

We got a RID asking for clarification of the 'in-order-delivery' mechanisms available in LTP.  I'm proposing to update section 2.3.2 to the following:

[cid:image001.jpg at 01CFDE34.B7783D90]


Does anybody see any issues here?

                --keith


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20141002/da79f82d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 67975 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20141002/da79f82d/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 77502 bytes
Desc: image004.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20141002/da79f82d/attachment-0001.jpg>