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

[Yoshifumi Nishida <[e-mail]>]

Hi,
Hmm.. I'm still thinking we need to solve this in the spec as reliable
solutions might require major changes..

I know this is tricky and not a very good idea, but it might improve a
situation a bit.
Let's say initiator's IW=4. if it wants to send something after
handshake, it may transmit data packets like this.

packet 1 with MPCAP
packet 2 with MPCAP
packet 3 with MPCAP
packet 4 with DSS (covers 1-4)

On the lost of these packets, it should retransmit them with DSS.
I know this doesn't keep the following rule in RFC6824 exactly, though.

   A sender MUST include a DSS option with data sequence mapping in
   every segment until one of the sent segments has been acknowledged
   with a DSS option containing a Data ACK.  Upon reception of the
   acknowledgment, the sender has the confirmation that the DSS option
   passes in both directions and may choose to send fewer DSS options
   than once per segment.

--
Yoshifumi

On Thu, Jul 25, 2013 at 1:35 AM, Krishna Khanal
<[e-mail]> wrote:
> Yes, I was using Linux Client.
>
> Both drop and out of order are causing fallback.
>
> Regards,
> Krishna
>
>
> -----Original Message-----
> From: Christoph Paasch [mailto:[e-mail]]
> Sent: Thursday, July 25, 2013 2:00 PM
> To: Krishna Khanal
> Cc: multipathtcp
> Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior
>
> 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
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp