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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 30 July 2013 06:44 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9986021F99E1 for <multipathtcp@ietfa.amsl.com>; Mon, 29 Jul 2013 23:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level:
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqkwu1NXMhvw for <multipathtcp@ietfa.amsl.com>; Mon, 29 Jul 2013 23:44:15 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id D22B821F8D90 for <multipathtcp@ietf.org>; Mon, 29 Jul 2013 23:44:14 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E82C9278095 for <multipathtcp@ietf.org>; Tue, 30 Jul 2013 15:44:11 +0900 (JST)
Received: by mail-la0-f49.google.com with SMTP id ev20so1494548lab.22 for <multipathtcp@ietf.org>; Mon, 29 Jul 2013 23:44:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pI6+rGzgPq84L+mAPTGdiGnez2h5x8j7Olvr7DFEfc4=; b=Tr4wN+n3AW0RAcvoMm18RjJlxbxOvalLmZAkMf0gFcQLIIF/dOFXlZvg/cYU6mLhq0 Ystjl/hy8ZoylmBLj7xt/gCuUIJ5fHbZ4E67m6Nsd3ihba8fgsr14khUCQAMCq5s42fj tAUZu5dghArsJMLafYUnwFe8Zi/zoNHXZZogEAjw3w5Ldz/HPZa+X1O72mYgHom6pKZC x5J8RR4dd3WFQqtFETVTrZmyMFZ7kF6bQKZHtYGxXL87l85fmNDinLpHO0tbqVCWzVKM OfUBgGkRSyMzyIYJxKDrZtpGxDJF7blnsNEmXYfndDP7NINS10MVewY6P9N+53hAS2Hx 30Dg==
MIME-Version: 1.0
X-Received: by 10.112.33.11 with SMTP id n11mr8038622lbi.76.1375166649040; Mon, 29 Jul 2013 23:44:09 -0700 (PDT)
Received: by 10.114.92.238 with HTTP; Mon, 29 Jul 2013 23:44:08 -0700 (PDT)
In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063CDB4A@SINPEX01CL02.citrite.net>
References: <CAO249yfyFmbfVBK_ZqyJvNm4JfCbXJLH-XMSo5iF1Ms-A5-F7w@mail.gmail.com> <5E21A2ABD63A394988AE055C785C29C4063C9AF9@SINPEX01CL02.citrite.net> <20130724090855.GA11135@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA2CB@SINPEX01CL02.citrite.net> <20130725074624.GA3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA539@SINPEX01CL02.citrite.net> <20130725082957.GD3897@cpaasch-mac> <5E21A2ABD63A394988AE055C785C29C4063CA58B@SINPEX01CL02.citrite.net> <CAO249yerJkC65iPqbQF1XG0MgNh--s_+XoaXALF2iy4t52NZFQ@mail.gmail.com> <5E21A2ABD63A394988AE055C785C29C4063CDB4A@SINPEX01CL02.citrite.net>
Date: Mon, 29 Jul 2013 23:44:08 -0700
Message-ID: <CAO249ydNcKL7vk=S1Qm0Pyqif4Gk-oTWayR2k46-g-vKvZa8ZQ@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Krishna Khanal <krishna.khanal2@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: multipathtcp <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2013 06:44:20 -0000

Hi Krishna,

Yes. you're right. I don't say it's a good approach. I just say it
might improve a situation with simple trick.
You might be able to check which destinations have many fallbacks,
then actives it..
-
Yoshifumi

On Mon, Jul 29, 2013 at 10:08 PM, Krishna Khanal
<krishna.khanal2@citrix.com> wrote:
> Hi,
>         One problem with this approach is that the first packet needs to be split most of the time (or always ?), if the sender has a single packet request/data or it does not has knowledge of how much data is available to send in advance. Also, combining MPCAP with a single data packet should be sufficient, no need to combine with subsequent data packets.
>
> Regards,
> Krishna
>
> -----Original Message-----
> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
> Sent: Tuesday, July 30, 2013 8:35 AM
> To: Krishna Khanal
> Cc: Christoph Paasch; multipathtcp
> Subject: Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior
>
> 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
> <krishna.khanal2@citrix.com> wrote:
>> Yes, I was using Linux Client.
>>
>> Both drop and out of order are causing fallback.
>>
>> Regards,
>> Krishna
>>
>>
>> -----Original Message-----
>> From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]
>> 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:christoph.paasch@uclouvain.be] 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:christoph.paasch@uclouvain.be] 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
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp