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
- [multipathtcp] draft agenda for Berlin meeting Yoshifumi Nishida
- [multipathtcp] MP_CAP Final ack drop and fallback… Krishna Khanal
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Christoph Paasch
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Krishna Khanal
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Christoph Paasch
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Krishna Khanal
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Christoph Paasch
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Krishna Khanal
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Yoshifumi Nishida
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Krishna Khanal
- Re: [multipathtcp] MP_CAP Final ack drop and fall… Yoshifumi Nishida
- Re: [multipathtcp] draft agenda for Berlin meeting philip.eardley
- [multipathtcp] draft agenda for Berlin meeting Yoshifumi Nishida