Re: [multipathtcp] MP_CAP Final ack drop and fallback behavior
Krishna Khanal <krishna.khanal2@citrix.com> Thu, 25 July 2013 08:35 UTC
Return-Path: <krishna.khanal2@citrix.com>
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 B296A21F9CC3 for <multipathtcp@ietfa.amsl.com>; Thu, 25 Jul 2013 01:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.834
X-Spam-Level:
X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
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 GzmrZuN2ESK7 for <multipathtcp@ietfa.amsl.com>; Thu, 25 Jul 2013 01:35:43 -0700 (PDT)
Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id E00EA21F9CE7 for <multipathtcp@ietf.org>; Thu, 25 Jul 2013 01:35:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,742,1367971200"; d="scan'208";a="3916762"
Received: from sinpex01cl01.citrite.net ([10.151.46.32]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 25 Jul 2013 08:35:42 +0000
Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by SINPEX01CL01.citrite.net ([169.254.1.212]) with mapi id 14.02.0342.004; Thu, 25 Jul 2013 16:35:40 +0800
From: Krishna Khanal <krishna.khanal2@citrix.com>
To: Christoph Paasch <christoph.paasch@uclouvain.be>
Thread-Topic: [multipathtcp] MP_CAP Final ack drop and fallback behavior
Thread-Index: AQHOiESWGIUqyZLNGkanGr0qg2ELz5lzBDOAgAHMAsD//69EAIAAj13A//98zoCAAIbb0A==
Date: Thu, 25 Jul 2013 08:35:39 +0000
Message-ID: <5E21A2ABD63A394988AE055C785C29C4063CA58B@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>
In-Reply-To: <20130725082957.GD3897@cpaasch-mac>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.252.240.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 25 Jul 2013 08:35:47 -0000
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] 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