Re: [multipathtcp] Options or Payload: pros and cons

Costin Raiciu <c.raiciu@cs.ucl.ac.uk> Thu, 12 November 2009 06:51 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 4435A28C0F6 for <multipathtcp@core3.amsl.com>; Wed, 11 Nov 2009 22:51:46 -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=[AWL=0.000, 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 QwaX6qqdyRhK for <multipathtcp@core3.amsl.com>; Wed, 11 Nov 2009 22:51:45 -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 7525A3A6B90 for <multipathtcp@ietf.org>; Wed, 11 Nov 2009 22:51:45 -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 1N8TQN-000Del-6X; Thu, 12 Nov 2009 06:44:55 +0000
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C01B6AD21@SLFSNX.rcs.alcatel-research.de>
References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk><3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> <C1CDADDD-4C5E-4CEA-8548-80FA0DDDA96E@cs.ucl.ac.uk> <133D9897FB9C5E4E9DF2779DC91E947C01B6AD21@SLFSNX.rcs.alcatel-research.de>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F8D11916-2A60-472D-A3D4-A884370AD91C@cs.ucl.ac.uk>
Content-Transfer-Encoding: 7bit
From: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
Date: Thu, 12 Nov 2009 15:51:46 +0900
To: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
X-Mailer: Apple Mail (2.753.1)
Cc: multipathtcp <multipathtcp@ietf.org>
Subject: Re: [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: Thu, 12 Nov 2009 06:51:46 -0000

Hi,

I am thinking of middleboxes that expect "text-only" protocols and we  
would introduce binary data in the payload. That's not going to go  
down well, but in the end it's just another failure mode.

I guess whichever way we go, we really need to think carefully about  
failure modes.

Let me add one more bullet to the list, after my discussion with  
Murari today.
Payload
- involves mixing the control and data plane in host stacks; will be  
much more difficult to implement

On 12 Nov 2009, at 10:57, SCHARF, Michael wrote:
>>
>
> I don't understand why ASCII encoding is mandatory. An IDS that parses
> the content may anyway be confused by the incomplete content inside  
> one
> MPTCP subflow, independent of the question whether options or payload
> encoding is used. Or do I miss something?
>
> Michael