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

[Rahul Jadhav <[e-mail]>]

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

Thanks,
Rahul

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

> 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 <[e-mail]>
> 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:[e-mail]] On Behalf Of
> >> Alan Ford
> >> Sent: 03 October 2018 19:56
> >> To: multipathtcp <[e-mail]>
> >> 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, [e-mail] 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/multipathtcp
> >>
> >> _______________________________________________
> >> multipathtcp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/multipathtcp
>
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>