Re: [multipathtcp] Options or Payload?

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 10 November 2009 01:35 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 0C9F53A67A2 for <multipathtcp@core3.amsl.com>; Mon, 9 Nov 2009 17:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.042
X-Spam-Level: *
X-Spam-Status: No, score=1.042 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
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 R2UVFr9aqbkh for <multipathtcp@core3.amsl.com>; Mon, 9 Nov 2009 17:35:00 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id EBDE23A69DA for <multipathtcp@ietf.org>; Mon, 9 Nov 2009 17:34:59 -0800 (PST)
Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E2FE94C0BC; Tue, 10 Nov 2009 10:35:22 +0900 (JST)
Date: Tue, 10 Nov 2009 10:35:22 +0900 (JST)
Message-Id: <20091110.103522.15256464.nishida@sfc.wide.ad.jp>
To: alan.ford@roke.co.uk
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>
References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Options or Payload?
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, 10 Nov 2009 01:35:01 -0000

Hello,
How about having a simple option which indicates the offset for real tcp payload?
For example, if mptcp packets conveys 10 bytes control info in the payload, set 
offset to 10 in the option.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

From: "Ford, Alan" <alan.ford@roke.co.uk>
Subject: [multipathtcp] Options or Payload?
Date: Tue, 10 Nov 2009 00:58:48 -0000
Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>

 > Hi all,
 > 
 > One of the big issues to be raised during yesterday's MPTCP session was
 > the question of whether TCP Options are really the right place to be
 > doing this. This is not the first time this has come up but deserves
 > further exploration.
 > 
 > Specifically, instead of doing this with TCP Options, the same
 > instructions could be included in the payload. Similar to TLS, the data
 > could be chunked and each chunk has a data sequence and length header.
 > These can be interspersed with control blocks to signal addresses,
 > security of joining subflows to connections, and connection close. A
 > simple 2-octet TCP option would still be used in the initial SYN to
 > signal MPTCP capability.
 > 
 > This has the benefit that it would allow the signalling to have
 > reliability, and we wouldn't be hit with option space limits, and thus
 > be potentially able to do better security algorithms. It would also give
 > us greater freedom in signals for future extensibility (for example, if
 > we wanted to signal ports for additional subflows, not just addresses).
 > 
 > On the downside, there may be cases where this could confuse
 > middleboxes, e.g. expecting HTTP on port 80 and finding this kind of
 > data instead. However, since a TCP option would be used at the start to
 > identify capability, if this were dropped by a middlebox/proxy then
 > MPTCP would not be used.
 > 
 > What do people think is the best approach?
 > 
 > Regards,
 > Alan
 > 
 > _______________________________________________
 > multipathtcp mailing list
 > multipathtcp@ietf.org
 > https://www.ietf.org/mailman/listinfo/multipathtcp