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

[Krishna Khanal <[e-mail]>]

Thanks Christoph for the information.

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.

Regards,
Krishna


-----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