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

[Christoph Paasch <[e-mail]>]

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