Subject: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-06.txt

From: [email-masked]
Date: Sun, 28 Jan 2018 19:21:19 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Delay/Disruption Tolerant Networking WG of the IETF.

        Title           : Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
        Authors         : Brian Sipos
                          Michael Demmer
                          Joerg Ott
                          Simon Perreault
	Filename        : draft-ietf-dtn-tcpclv4-06.txt
	Pages           : 38
	Date            : 2018-01-28

Abstract:
   This document describes a revised protocol for the TCP-based
   convergence layer (TCPCL) for Delay-Tolerant Networking (DTN).  The
   protocol revision is based on implementation issues in the original
   TCPCL Version 3 and updates to the Bundle Protocol contents,
   encodings, and convergence layer requirements in Bundle Protocol
   Version 7.  Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles
   as its service data unit being transported and provides a reliable
   transport of such bundles.  Several new IANA registries are defined
   for TCPCLv4 which define some behaviors inherited from TCPCLv3 but
   with updated encodings and/or semantics.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-06
https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dtn-tcpclv4-06

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Sipos <[email-masked]>
Date: Mon, 29 Jan 2018 03:27:58 +0000

All,

I've edited the TCPCLv4 draft to address comments from Victoria Prichard, Fred Templin, and Marco Kaulea. None of these edits represent a change in on-the-wire encoding or nominal protocol flow. They should all be either clarifying off-nominal modes or making disparate requirements consistent with each other.

There is still an unresolved issue with SHUTDOWN sequencing and requirements about which message are required/allowed after sending and after receiving a SHUTDOWN message. The current draft spec. is inconsistent about what is required and what is allowed regarding in-progress transfers.

I believe the final spec. should allow for finishing any in-progress transfers (from either side) but not allow initiating any new transfers (from either side). If an implementation chooses to not allow finishing-up of any transfers after a SHUTDOWN then they are free to simply close the TCP connection and have the transfers fail as a side-effect. I say transfers in plural here because it's possible for a receiving node to have a backlog of XFER_ACK messages for more than one transfer when a SHUTDOWN is sent/received.

________________________________
From: dtn <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Sunday, January 28, 2018 10:21:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-06.txt

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/
Delay-Tolerant Networking TCP Convergence Layer Protocol ...<https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/>
datatracker.ietf.org
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 (Internet-Draft, 2017)

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

---

From: Brian Sipos <[email-masked]>
Date: Mon, 29 Jan 2018 16:53:18 +0000

One other thing new in the draft is Section 1.1 "Convergence Layer Services" which is intended to list all of the CL-BP interface services that the TCPCLv4 will be providing. It would be useful to review this short section in the context of earlier discussion of what a CL shall/should/may provide to the BP agent. These services are the justification for all of the rest of the specification.

________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Sunday, January 28, 2018 10:27:58 PM
To: [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-06.txt

All,

Abstract:

---

From: Rick Taylor <[email-masked]>
Date: Mon, 29 Jan 2018 17:18:06 +0000

Thanks Brian,

That list of services is very useful, especially brought out near the
beginning.

Cheers,

Rick

On Mon, 2018-01-29 at 16:53 +0000, Brian Sipos wrote:
> One other thing new in the draft is Section 1.1 "Convergence Layer
> Services" which is intended to list all of the CL-BP interface
> services that the TCPCLv4 will be providing. It would be useful to
> review this short section in the context of earlier discussion of
> what a CL shall/should/may provide to the BP agent. These services
> are the justification for all of the rest of the specification.
> I've edited the TCPCLv4 draft to address comments from Victoria
> Prichard, Fred Templin, and Marco Kaulea. None of these edits
> represent a change in on-the-wire encoding or nominal protocol flow.
> They should all be either clarifying off-nominal modes or making
> disparate requirements consistent with each other.
> 
> There is still an unresolved issue with SHUTDOWN sequencing and
> requirements about which message are required/allowed after sending
> and after receiving a SHUTDOWN message. The current draft spec. is
> inconsistent about what is required and what is allowed regarding in-
> progress transfers.
> 
> I believe the final spec. should allow for finishing any in-progress
> transfers (from either side) but not allow initiating any new
> transfers (from either side). If an implementation chooses to not
> allow finishing-up of any transfers after a SHUTDOWN then they are
> free to simply close the TCP connection and have the transfers fail
> as a side-effect. I say transfers in plural here because it's
> possible for a receiving node to have a backlog of XFER_ACK messages
> for more than one transfer when a SHUTDOWN is sent/received.
> 
>   Delay-Tolerant Networking TCP Convergence Layer Protocol ...
> datatracker.ietf.org