[multipathtcp] Options or Payload: pros and cons

Costin Raiciu <c.raiciu@cs.ucl.ac.uk> Wed, 11 November 2009 02:21 UTC

Return-Path: <c.raiciu@cs.ucl.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 5D82028C266 for <multipathtcp@core3.amsl.com>; Tue, 10 Nov 2009 18:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 tKvAPu9GQaph for <multipathtcp@core3.amsl.com>; Tue, 10 Nov 2009 18:21:00 -0800 (PST)
Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 754803A696E for <multipathtcp@ietf.org>; Tue, 10 Nov 2009 18:21:00 -0800 (PST)
Received: from host-32-98.meeting.ietf.org ([133.93.32.98]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N82jQ-000DPq-Ci for multipathtcp@ietf.org; Wed, 11 Nov 2009 02:14:48 +0000
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com>
References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C1CDADDD-4C5E-4CEA-8548-80FA0DDDA96E@cs.ucl.ac.uk>
Content-Transfer-Encoding: 7bit
From: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
Date: Wed, 11 Nov 2009 11:21:03 +0900
To: "multipathtcp@ietf.org List" <multipathtcp@ietf.org>
X-Mailer: Apple Mail (2.753.1)
Subject: [multipathtcp] Options or Payload: pros and cons
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: Wed, 11 Nov 2009 02:21:01 -0000

Hi

I tried to assemble a pros and cons list for the two approaches.  
Please add bullets to both lists until we get something reasonably  
exhaustive, and then we can make an informed decision.

At a high level, we need to use options on every subflow at least in  
the syn exchange. Otherwise we can't attach the subflow to the  
existing connection, or can't negotiate mptcp in the first place.
Ideally you'd like fate sharing: if the syn/ack exchange passes, the  
subflow should work.

Options
+ nice with tcp
+ single subflow mptcp if friendly with IDSes, and traffic  
normalizers (i.e. data flow is what the app receives).
- reliability is more difficult (how often do you retransmit?) drop  
packets? what's the failure mode when options don't get through?
- boxes may crash when parsing unknown stuff. The hope is that on SYN  
processing is more robust with unknown options. ECN story is  
frightening :). Murari (Microsoft)
says that even changing position of padding bits in options crashes  
some middleboxes; I've heard a similar story from the Linux kernel  
experience. However, we can't (cleanly) avoid sending options on SYNs.

Payload
+ option space limits no longer matter; can do funkier stuff later,  
like negotiate keys, etc.
+ easier to get reliability; retransmit of control data linked to  
data retransmit
+ easier to deal with middleboxes that resegment (it just works!)
+ new options on syns may be allowed, but not on data (is this true)?
- feels like a hack, not the traditional way to evolve tcp
- implies encoding of any data sent MUST  be ASCII; middleboxes (ids,  
traffic normalizers) that look at content and see binary stuff will  
probably drop the data; finally, if we used binary stuff, there is no  
guarantee for fate sharing. . Text encoding is less space efficient;  
does it matter?

Any more?
Costin