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

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 <rahul.jadhav@huawei.com> wrote:
> 
> 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:multipathtcp-bounces@ietf.org] On Behalf Of
>> Alan Ford
>> Sent: 03 October 2018 19:56
>> To: multipathtcp <multipathtcp@ietf.org>
>> 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.
>> 
>> 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, internet-drafts@ietf.org wrote:
>>> 
>>> 
>>> 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/
>>> 
>>> _______________________________________________
>>> multipathtcp mailing list
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> 
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp