Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt

From: [email-masked]
Date: Wed, 03 Oct 2018 07:23:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multipath TCP WG of the IETF.

        Title           : TCP Extensions for Multipath Operation with Multiple Addresses
        Authors         : Alan Ford
                          Costin Raiciu
                          Mark Handley
                          Olivier Bonaventure
                          Christoph Paasch
	Filename        : draft-ietf-mptcp-rfc6824bis-12.txt
	Pages           : 80
	Date            : 2018-10-03

Abstract:
   TCP/IP communication is currently restricted to a single path per
   connection, yet multiple paths often exist between peers.  The
   simultaneous use of these multiple paths for a TCP/IP session would
   improve resource usage within the network and, thus, improve user
   experience through higher throughput and improved resilience to
   network failure.

   Multipath TCP provides the ability to simultaneously use multiple
   paths between peers.  This document presents a set of extensions to
   traditional TCP to support multipath operation.  The protocol offers
   the same type of service to applications as TCP (i.e., reliable
   bytestream), and it provides the components necessary to establish
   and use multiple TCP flows across potentially disjoint paths.

   This document specifies v1 of Multipath TCP, obsoleting v0 as
   specified in RFC6824 [RFC6824] through clarifications and
   modifications primarily driven by deployment experience.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-12
https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-12

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: Alan Ford <[email-masked]>
Date: Wed, 3 Oct 2018 15:25:41 +0100

Hi all,

I believe this new version addresses all last call/review comments we received for rfc6824bis, with the exception of adding a possible “changes since RFC6824” section.

Could all reviewers please check this new version and ensure we have handled your review comments appropriately?

Many thanks,
Alan

> On 3 Oct 2018, at 15:23, [email-masked] wrote:
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Xavier de Foy <[email-masked]>
Date: Thu, 4 Oct 2018 11:53:16 -0400

Thanks Alan,

Could all reviewers please check this new version and ensure we have
> handled your review comments appropriately?
>

Yes, I think my review comments have been handled appropriately.
Best Regards,
Xavier.

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 8 Oct 2018 13:49:09 +0000

Hello Alan,

Most of my comments from [1] are handled. Thank you.

Some comments based on the updated text:
1. Accepted comment#8 in [1] does not seem to be handled. I think it is important to be clarified that the value of "Address ID" has significance not only within a single connection but also only on the peer who generates the ID. Thus it is possible for peers to generate the same Address ID within a connection as well.
2. Thank you for removing the term "passive opener" throughout the document. The new text is much easier to understand.
3. Looks like comment#2 for explicitly mentioning the Reason Code for MP_TCPRST was not accepted. I understand we haven’t really got any feedback from the WG on this point but then I feel it is necessary to do this.
4. "make-before-break session" term is introduced after rewording ... I feel this term should be explained in terminology section.

Best,
Rahul

[1] https://mailarchive.ietf.org/arch/msg/multipathtcp/hpsqifbR00xRWJNZe-CYR7UtTyU

> -----Original Message-----
> From: multipathtcp [mailto:[email-masked]] On Behalf Of
> Alan Ford
> Sent: 03 October 2018 19:56
> To: multipathtcp <[email-masked]>
> Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt
> 
> Hi all,
> 
> I believe this new version addresses all last call/review comments we
> received for rfc6824bis, with the exception of adding a possible “changes
> since RFC6824” section.
> 
> > 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.
> >

---

From: Alan Ford <[email-masked]>
Date: Mon, 8 Oct 2018 21:58:28 +0100

Hi Rahul,

Thank you for double-checking, it is much appreciated!

1. Fixing text on Address ID, I hope the following is acceptable:

        The MP_JOIN option includes an "Address ID".  This is an identifier
        generated by the sender of the option, used to identify the source address 
        of this packet, even if the IP header has been changed in transit by a middlebox.
        The numeric value of this field is generated by the sender and must map uniquely 
        to a source IP address for the sending host.

3. It was left for further comment, and no further comment was forthcoming. I personally am not sure of any need to add a MP_TCPRST here since both ends should know why the subflow is being torn down - one sent the REMOVE_ADDR, and the other acted on it. If the REMOVE_ADDR was spoofed, the safety nets should mean the subflow is not torn down. So I see no benefit in signalling the reason here.

4. At the first appearance of “make-before-break", we can add:

	, where new subflows are added before the previously used ones are closed

Regards,
Alan

> On 8 Oct 2018, at 14:49, Rahul Arvind Jadhav <[email-masked]> wrote:
> 
> Hello Alan,
>

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 9 Oct 2018 22:34:33 +0530

The suggested text looks good. I have no further comments.

Thanks,
Rahul

On Tue, 9 Oct 2018 at 2:28 AM, Alan Ford <[email-masked]> wrote:

> 3. It was left for further comment, and no further comment was
> forthcoming. I personally am not sure of any need to add a MP_TCPRST here
> since both ends should know why the subflow is being torn down - one sent
> the REMOVE_ADDR, and the other acted on it. If the REMOVE_ADDR was spoofed,
> the safety nets should mean the subflow is not torn down. So I see no
> benefit in signalling the reason here.
>
> > 1. Accepted comment#8 in [1] does not seem to be handled. I think it is
> important to be clarified that the value of "Address ID" has significance
> not only within a single connection but also only on the peer who generates
> the ID. Thus it is possible for peers to generate the same Address ID
> within a connection as well.
> > 2. Thank you for removing the term "passive opener" throughout the
> document. The new text is much easier to understand.
> > 3. Looks like comment#2 for explicitly mentioning the Reason Code for
> MP_TCPRST was not accepted. I understand we haven’t really got any feedback
> from the WG on this point but then I feel it is necessary to do this.
> > 4. "make-before-break session" term is introduced after rewording ... I
> feel this term should be explained in terminology section.
> >
> > Best,
> > Rahul
> >
> > [1]
> https://mailarchive.ietf.org/arch/msg/multipathtcp/hpsqifbR00xRWJNZe-CYR7UtTyU
> >
> >
> >>>       Title           : TCP Extensions for Multipath Operation with
> Multiple
> >> Addresses
> >>>       Authors         : Alan Ford
> >>>                         Costin Raiciu
> >>>                         Mark Handley
> >>>                         Olivier Bonaventure
> >>>                         Christoph Paasch

---

From: <[email-masked]>
Date: Tue, 16 Oct 2018 16:34:30 +0000

Alan,
Looks good.

1. the list of changes /reasons compared with rfc6824 not included. I can submit as separate draft, if you prefer to inclusion in your doc.

2. I  made a comment on Fig 12 (just checking you meant to ignore it - don’t mind!)

And in Fig 12
|        Truncated HMAC (8 octets, if length > 10 octets)       |

Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn’t include the HMAC, is this right??

3. I made a comment on Section 2:  Need to add sub-sections on closing subflow & fast close & fallback
Would be nice, but I won't insist if it's too much work

Thanks
phil

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Alan Ford
Sent: 03 October 2018 15:26
To: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt

Hi all,

Many thanks,
Alan

---

From: Alan Ford <[email-masked]>
Date: Thu, 18 Oct 2018 15:49:17 +0100

Hi Phil, all,

Inline...

> On 16 Oct 2018, at 17:34, [email-masked] wrote:
> 
> Alan,
> Looks good.
> 

I do intend to add this, but have not yet got around to it. I am keen we keep the list clear, consistent, and simple, and focus only on implementation differences.

> Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn’t include the HMAC, is this right??

It’s wrong! It should say “If E = 0”. Corrected.

> Would be nice, but I won't insist if it's too much work

Closing subflow and fast close are covered in the “Closing an MPTCP Connection” subsection. Fallback is too specialist for this introductory overview of signalling.

Best regards,
Alan