IETF Logo Mail Archive

Re: [multipathtcp] Modified MP_CAPABLE handshake

"Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> Wed, 07 September 2011 18:17 UTC

Return-Path: <georg.hampel@alcatel-lucent.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 D2C3721F8CB3 for <multipathtcp@ietfa.amsl.com>; Wed, 7 Sep 2011 11:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level:
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 mi2MeVzuDSaJ for <multipathtcp@ietfa.amsl.com>; Wed, 7 Sep 2011 11:17:42 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D935C21F8CA9 for <multipathtcp@ietf.org>; Wed, 7 Sep 2011 11:17:41 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p87IJUoo019724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 13:19:30 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87IJU9Q028818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Sep 2011 13:19:30 -0500
Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 7 Sep 2011 13:19:30 -0500
From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
To: "christoph.paasch@uclouvain.be" <christoph.paasch@uclouvain.be>, Alan Ford <alan.ford@gmail.com>
Date: Wed, 7 Sep 2011 13:19:28 -0500
Thread-Topic: [multipathtcp] Modified MP_CAPABLE handshake
Thread-Index: AcxtdH44eV37bgKOQB6ruvLpN++FLQAE3oGw
Message-ID: <154773479ED2314980CB638A48FC443486DE8FF3@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
References: <154773479ED2314980CB638A48FC443486DE8EC0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201109071826.10767.christoph.paasch@uclouvain.be> <CAOs_kTZ=BAhvsofwLxqk59Gm8xWZ-1X=CDOoKsBuCHFixCFvVg@mail.gmail.com> <201109071840.22993.christoph.paasch@uclouvain.be>
In-Reply-To: <201109071840.22993.christoph.paasch@uclouvain.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Modified MP_CAPABLE handshake
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: Wed, 07 Sep 2011 18:17:42 -0000

All,

I think that delaying client requests from 1RTT to 2RTT is pretty unacceptable. In the tcpm WG, Google tries to push for data on the SYN packet to reduce the client request time from 1RTT to 0 RTT. In this light, MPTCP wouldn't quite meet the trend.

I would tend to ask the question how much security we gain by pushing the key A transfer from the first SYN to the second ACK.

I further see a philosophical problem in the 3rd ACK solution: MPTCP-level messages (e.g. DSN, data FIN) should be acknowledged via MPTCP-level messages (e.g. data ACKs) and not via subflow level ACKs. The -03 version of the draft was consistent in that respect.

My vote: Go back to -03.

Georg


-----Original Message-----
From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch
Sent: Wednesday, September 07, 2011 11:40 AM
To: Alan Ford
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Modified MP_CAPABLE handshake


On Wednesday 07 September 2011 wrote Alan Ford:
> Mark's solution is unfortunately not feasible since we do not have enough
> option space to fit both a DSS and a MP_CAPABLE in the same packet.

The DSS can also be reduced to 32-bit sequence numbers. Then, this would fit, 
as the MP_CAPABLE in the third ack is 20 bytes long and the DSS fits in the 
remaining 20 bytes. But there is no more space left for timestamps, which are 
not necessary on each packet.

> Indeed, that would work.
> 
> However, I think it may well be safest, and easiest, to go back to the -03
> version where the keys are in both the SYN and SYN/ACK, and only echoed in
> the ACK for reliability.
> 
> If a server wants to act statelessly and thus rely on the third ACK for its
> keys, then fallback would be the only sensible option in the event of the
> third packet loss.

Yes, I think that would be best. Put the key back in the SYN and ignore the 
loss of the ACK.

Christoph

--
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain

www.rollerbulls.be
--
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

v2.8.7 | Report a Bug | By Email