Subject: Re: [dtn] Draft changes to TCPCL for BPbis and implementation feedback

From: Brian Sipos <[email-masked]>
Date: Fri, 3 Jun 2016 12:46:28 +0000

I'm replying to myself to include some comments on the pre-existing TCPCL rather than the new changes. I came across these within a trial implementation.

Regarding contact negotiation, I don't see a point to allowing a TCPCL endpoint to negotiate for not sending either REFUSE_BUNDLE or ACK_SEGMENT. If an endpoint simply ignores these messages upon reception it seems like it would be the same effect, with the only difference being the (small) network traffic of the ignored message. I can make a similar argument for LENGTH messages, in the sense that it makes a simpler TCPCL protocol to simply mandate sending LENGTH immediately before any starting DATA_SEGMENT and if the receiver chooses to ignore the LENGTH then so be it.

Regarding the per-segment ACK messages, I'm not sure what the point is in having per-segment rather than per-bundle. TCPCL delegates retransmission to the TCP layer, and there is no specified behavior for reception of either missing or out-of-order ACK messages. The only thing per-segment, rather than per-bundle ACK, gives is a 'feel good' for someone troubleshooting the network traffic. I don't see how it helps the sending endpoint at all (other than the final full-bundle-length ACK).

Back to the topic of contact negotiation, someone more familiar with RFC5050 BP may be able to add some insight on the aspect of reactive fragmentation: I'm not sure what the CL negotiation of this buys the protocol, because the concept "reactive fragmentation" is not defined by either TCPCL (RFC7242) or BP (RFC5050) so enabling it for a single connection allows the endpoints to 'do something unspecified'.

The short version of above is that I would prefer to simplify TCPCLv4 and do away with those negotiated connection attributes.
________________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Wednesday, May 25, 2016 2:12:20 PM
To: [email-masked]
Subject: [dtn] Draft changes to TCPCL for BPbis and implementation feedback

All,
Based on the ongoing discussions of BPbis I have put together an updated TCPCL spec.
These changes are intended to address:
 - issues found in TCPCLv3 implementation
 - need to support eventual BPbis
 - my own need for concrete link security specification
 - keep some amount of similarity with TCPCLv3 to avoid churn

I'm sure that there will be further changes to this, as BPbis itself is itself under review. My hope is to at least provide something concrete to pick nits within.
All comments are appreciated!
________________________________________
From: [email-masked] <[email-masked]>
Sent: Wednesday, May 25, 2016 13:56
To: Brian Sipos; Brian Sipos
Subject: New Version Notification for draft-sipos-dtn-tcpclv4-00.txt

A new version of I-D, draft-sipos-dtn-tcpclv4-00.txt
has been successfully submitted by Brian Sipos and posted to the
IETF repository.

Name:           draft-sipos-dtn-tcpclv4
Revision:       00
Title:          Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
Document date:  2016-05-25
Group:          Individual Submission
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-sipos-dtn-tcpclv4-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sipos-dtn-tcpclv4/
Htmlized:       https://tools.ietf.org/html/draft-sipos-dtn-tcpclv4-00

Abstract:
   This document describes a revised protocol for the TCP-based
   convergence layer for Delay-Tolerant Networking (DTN).  The protocol
   revision is based on implementation issues in the original [RFC7242]
   and updates to the Bundle Protocol contents, encodings, and
   convergence layer requirements in [I-D.ietf-dtn-bpbis].  The majority
   of this specification is unchanged from TCPCL version 3.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 3 Jun 2016 17:23:22 +0000

I think the (small) network traffic increment imposed by these additional messages is the reason for making them optional/negotiated; the reasoning was (I suspect) that for some use cases the additional traffic might be prohibitively costly.  Speaking just for myself, I'm fine with simplifying.

The per-segment ACK messages are the incremental acknowledgments that make reactive fragmentation possible.  However, since (as you point out) reactive fragmentation isn't formally defined anywhere, this may be moot.  If we're not going to bite the bullet and define exactly what TCPCL is supposed to do when it's required to perform what we colloquially call "reactive fragmentation" then I agree that negotiation of the reactive fragmentation flag should also be removed.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Friday, June 3, 2016 5:46 AM
To: [email-masked]
Subject: Re: [dtn] Draft changes to TCPCL for BPbis and implementation feedback

All,

A new version of I-D, draft-sipos-dtn-tcpclv4-00.txt has been successfully submitted by Brian Sipos and posted to the IETF repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brian Sipos <[email-masked]>
Date: Mon, 6 Jun 2016 19:08:51 +0000

Responding again to all just to get my thoughts down before any edits,
I don't want to remove functionality from TCPCL since someone probably does care about what's already there. I'm looking at moving the contact header negotiation from single-octet of bit flags to a single-pass version of PPP LCP option negotiation [RFC1661]. This would be an exchange of type-length-value options, which would allow a TCPCL peer to operate on the full spectrum from pure-policy (negotiate nothing) to negotiation of all parameters. This also allows extensibility of to-be-negotiated parameters without changing TCPCL itself.

I will be adding some parameters, because from an interoperability standpoint it seems more important to negotiate something like a maximum receive segment-size than to negotiate-away ACK or REFUSE messages. But by making these all independent contact options, a one-to-one mapping of capability from TCPCLv3 to TCPCLv4 will be possible.
________________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Friday, June 3, 2016 1:23:22 PM
To: [email-masked]
Subject: Re: [dtn] Draft changes to TCPCL for BPbis and implementation  feedback

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Friday, June 3, 2016 5:46 AM
To: [email-masked]
Subject: Re: [dtn] Draft changes to TCPCL for BPbis and implementation feedback

All,

Abstract:

The IETF Secretariat