Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior

[Christoph Paasch <[e-mail]>]

Hello,

On 25/07/13 - 08:26:24, Krishna Khanal wrote:
> Hi Christoph, Yes server sending its willingness but letting client decide
> on the reliability of final ack looks better. 
> 
> In my experience, there is significant fallback due to receiving data
> packet before final ack, though I don't have exact data to share here.
> Anyone having any experience with this?

are you using the Linux implementation as a client?

I would be surprised if you have so many fallbacks, because you would need
a drop of the third ACK.
Thus you maybe have a high loss-rate on the path (?).


Cheers,
Christoph

> 
> Regards, Krishna
> 
> 
> -----Original Message----- From: Christoph Paasch
> [mailto:[e-mail]] Sent: Thursday, July 25, 2013 1:18
> PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp] MP_CAP
> Final ack drop and fallback behavior
> 
> Hello Krishna,
> 
> On 25/07/13 - 04:51:13, Krishna Khanal wrote:
> > What about setting a flag in the SYNACK packet to tell the peer about
> > the reliability of the final ack? If the administrator thinks it is ok
> > to put a client on hold for an RTT, then they can set the flag in the
> > synack packet and force client to do reliable transmission of final ack.
> 
> I'm not against this flag.  But, it should just be a signal of the server
> for the client, saying "I'm doing stateless connection establishment". In
> the end, it's the client who will decide if he wants to trade this
> additional RTT for assured MPTCP-connectivity or not.
> 
> 
> Cheers, Christoph
> 
> 
> > -----Original Message----- From: Christoph Paasch
> > [mailto:[e-mail]] Sent: Wednesday, July 24, 2013
> > 2:39 PM To: Krishna Khanal Cc: multipathtcp Subject: Re: [multipathtcp]
> > MP_CAP Final ack drop and fallback behavior
> > 
> > Hello Krishna,
> > 
> > On 24/07/13 - 08:05:40, Krishna Khanal wrote:
> > > Hi, For stateless implementation of MP_CAPABLE flow, there is no way
> > > to continue with MPTCP if the final ack of 3-way MP_CAP handshake is
> > > dropped or the data packet is received before the MP_CAP ack due to
> > > out of ordering of the packet in the network. Only way to continue
> > > with the transaction is to fallback to regular TCP and there is a
> > > pretty much chance of happening this in the real network. So, there is
> > > always a requirement of fallback even if the middle devices supports
> > > and understands MPTCP.
> > > 
> > > Is there any thought on making MP_CAP final ack reliable like MP_JOIN
> > > final ack or including MP_CAP final ack options with the data packet
> > > along with DSS packet until the ack is received? Second, option may
> > > not be suitable because it consumes all the option space and first
> > > option also tend to increase the handshake duration and block the
> > > request by atleast an RTT.
> > > 
> > > Any thought?
> > 
> > In the beginning of MPTCP, the third ACK with the MP_CAPABLE was sent in
> > a reliable way, as it is done today for the third ACK with the MP_JOIN.
> > But this got removed due to the additional RTT:
> > 
> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01529.html
> > 
> > 
> > Then, the status of the draft was for some time that MPTCP was doing
> > reliable transmission of the third ACK+MP_CAPABLE, but allowed sending
> > data before the arrival of this third ACK. However, this did not help,
> > as early arrival of data (prior to the third ACK) will still trigger a
> > fallback. So, the MPTCP-draft changed to a non-retransmitting third-ack
> > as it is for today:
> > 
> > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01699.html
> > 
> > 
> > It would not be possible to combine MP_CAPABLE with the DSS-option and
> > still use stateless connection establishment:
> > 
> > MP_CAPABLE: 20 bytes DSS-option: 4 bytes (header) + 4 bytes (DSN) + 4
> > bytes (Subflow-seq) + 4 bytes (Data-length + csum) = 16 bytes
> > 
> > So, there are 4 more bytes left. This would mean that we cannot put the
> > Timestamp-option, which is required for stateless connection
> > establishment.
> > 
> > 
> > 
> > Cheers, Christoph