Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824

From: <[email-masked]>
Date: Thu, 10 Sep 2015 14:52:10 +0000

Added to the agenda for today

> -----Original Message-----
> From: multipathtcp [mailto:[email-masked]] On Behalf Of
> Anumita Biswas
> Sent: 05 January 2015 19:42
> To: Alan Ford
> Cc: [email-masked]
> Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824
> 
> 
> 
> > On Jan 5, 2015, at 2:25 AM, Alan Ford <[email-masked]> wrote:
> >
> > Hi Anumita,
> >
> > First, sorry for the slow reply!
> >
> > On 11 Dec 2014, at 21:50, Anumita Biswas wrote:
> >> For all this to work, the current MPTCP implementers will have to
> add the following support in their version 0 implementation:
> >>
> >> a. A server must accept a SYN with any version number.
> >> b. The server must reply with the version number it supports or
> wishes to use, provided it is equal to or lower than the client's
> version number, and not fall back to a regular TCP handshake in
> SYN/ACK.
> >> c. The client must echo the minimum of the versions advertised by
> the client and server in the ACK of the 3-way handshake or fallback to
> regular TCP if it does not support the server's version.
> >>
> >> Please let me know your thoughts on this,
> >
> > I agree with your proposal here, and will wrap it in in the next
> revision. I had originally thought we wouldn't need to tackle this
> until a newer MPTCP version number was proposed, but for fallback we do
> indeed need to specify some of this. From the perspective of a v0 MPTCP
> implementation, the one thing we need to actively specify is that it is
> still valid to respond to a SYN/MP_CAPABLE with one with a lower
> version number. A pleasant side-effect of the stateless handshake
> mechanism we have is that this means we don't need to worry about any
> contents in that initial SYN/MP_CAPABLE with the higher version number
> - all necessary data is echoed in the ACK/MP_CAPABLE. It's up to
> implementations of later versions to determine whether they want to be
> able to support fallback once the far end offers a lower version
> number.
> >
> 
> My belief is that implementations will prefer to fallback to the
> minimum MPTCP version if its possible to easily maintain/implement
> multiple MPTCP versions, than fallback to regular TCP.
> 
> Thank you!
> Anumita
> 
> > Best regards,
> > Alan
> >
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Thu, 10 Sep 2015 14:54:08 +0000

Sorry, my msg was spam. Old msg somehow popped to top of my inbox!

> From: Eardley,PL,Philip,TUB8 R
> Sent: 10 September 2015 15:52
> To: 'Anumita Biswas'; Alan Ford
> Subject: RE: [multipathtcp] MPTCP Versioning in RFC 6824
> 
> > until a newer MPTCP version number was proposed, but for fallback we
> > do indeed need to specify some of this. From the perspective of a v0
> > MPTCP implementation, the one thing we need to actively specify is
> > that it is still valid to respond to a SYN/MP_CAPABLE with one with a
> > lower version number. A pleasant side-effect of the stateless
> > handshake mechanism we have is that this means we don't need to worry
> > about any contents in that initial SYN/MP_CAPABLE with the higher
> > version number