IETF Logo Mail Archive

Re: [multipathtcp] Time for Long Options?

<L.Wood@surrey.ac.uk> Tue, 03 August 2010 10:02 UTC

Return-Path: <L.Wood@surrey.ac.uk>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B478B3A6875 for <multipathtcp@core3.amsl.com>; Tue, 3 Aug 2010 03:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bv15nmzh-KI for <multipathtcp@core3.amsl.com>; Tue, 3 Aug 2010 03:02:22 -0700 (PDT)
Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 227253A67ED for <multipathtcp@ietf.org>; Tue, 3 Aug 2010 03:02:21 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-13.tower-72.messagelabs.com!1280829215!672067!2
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.39]
Received: (qmail 15043 invoked from network); 3 Aug 2010 09:53:35 -0000
Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-13.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 3 Aug 2010 09:53:35 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 3 Aug 2010 10:53:35 +0100
From: L.Wood@surrey.ac.uk
To: touch@isi.edu, Andreas.Ripke@neclab.eu
Date: Tue, 03 Aug 2010 10:50:48 +0100
Thread-Topic: [multipathtcp] Time for Long Options?
Thread-Index: Acsy6Fa2cGUGky1fQqCjC9H+RKxGxwACQLSP
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2BF32002@EXMB01CMS.surrey.ac.uk>
References: <282447E9-0047-4F6C-8B6E-09301F72A930@nets.rwth-aachen.de> <1D99C255-6838-4017-B196-F3F558EE634D@muada.com> <8A2949EF-2F11-4D93-9C80-F9BA38AFBC0B@nets.rwth-aachen.de> <2B69FDEC-F19D-46F8-9D45-49B496FCD640@muada.com> <A8D9408E-CD02-4C90-B243-798AFA869B94@nets.rwth-aachen.de> <9DCAE0A3-6D76-4C4E-862B-3BDE879798B5@cs.ucl.ac.uk> <1E558979-D936-4BBC-ADE4-DD74C85474DA@nets.rwth-aachen.de> <5FDC413D5FA246468C200652D63E627A09B84785@LDCMVEXC1-PRD.hq.netapp.com> <1E3555D6-38D4-451D-A5A4-BBFBB9F3A46A@nets.rwth-aachen.de> <alpine.DEB.2.00.1007301007040.10894@melkinpaasi.cs.helsinki.fi> <87F55601-6C66-4BB5-8332-51F1A3989711@nets.rwth-aachen.de> <4C5282A6.2030101@isi.edu> <2D2FFE4726FAF74285C45D69FDC30E790220DB@PALLENE.office.hd> <4C5326FB.2080609@isi.edu> <2D2FFE4726FAF74285C45D69FDC30E79027EC7@PALLENE.office.hd>, <4C57D70B.3010306@isi.edu>
In-Reply-To: <4C57D70B.3010306@isi.edu>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Time for Long Options?
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 03 Aug 2010 10:02:24 -0000

Joe,

> As I noted, this problem was explored in numerous contexts in TCPM, and
> the conclusion was that it was not feasible to extend options in the
> SYN. That being the critical case, we didn't explore extending options
> in just the payloads after the connection was established. 

didn't
http://tools.ietf.org/html/draft-eddy-tcp-loo
do just that?

(yes, should probably be -tcpm- rather than -tcp- in the filename.)

L.

Lloyd Wood
http://sat-net.com/L.Wood/
________________________________________
From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu]
Sent: 03 August 2010 09:44
To: Andreas Ripke
Cc: multipathtcp TCP
Subject: Re: [multipathtcp] Time for Long Options?

On 8/2/2010 2:14 AM, Andreas Ripke wrote:
>> FWIW, the MacOSX is implementing TCP properly. The data in the SYN is
>> part of the data path (unless, presumably, the option declares
>> otherwise). Options not defined are required to be silently ignored.
>
>
> The plan was to figure out how to handle a receiver that does not
> know about extended option space. If the initial SYN with extended
> options space arrives and the receiver is unaware it treats the extra
> as payload. Falling back to regular TCP is then only possible with RST
> followed by a new connection request (to avoid extended options to be
> delivered to the application - as only the SYN is ack'ed in the first
> place and not the payload). But then, the other challenge is how to
> detect if middleboxes altered and rectified the packets.

RSTs are not reliable, so now you have to deal with the timeouts and
retransmissions that result.

As I noted, this problem was explored in numerous contexts in TCPM, and
the conclusion was that it was not feasible to extend options in the
SYN. That being the critical case, we didn't explore extending options
in just the payloads after the connection was established. That may be
useful to explore here as a separate issue, but SYN extension does not
seem possible.

Joe
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

v2.23.0 | Report a Bug | By Email