IETF Logo Mail Archive

Re: [multipathtcp] High-level design decisions /architecture

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 03 November 2009 20:39 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 1E35E3A6A1F for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 12:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.262
X-Spam-Level: *
X-Spam-Status: No, score=1.262 tagged_above=-999 required=5 tests=[AWL=0.358, 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 vyPqcRAF+gUB for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 12:39:37 -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 65B533A67D3 for <multipathtcp@ietf.org>; Tue, 3 Nov 2009 12:39:37 -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 B08BB4C0AA; Wed, 4 Nov 2009 05:39:53 +0900 (JST)
Date: Wed, 04 Nov 2009 05:39:53 +0900
Message-Id: <20091104.053953.70139435.nishida@sfc.wide.ad.jp>
To: alan.ford@roke.co.uk
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <4AEF781E.4070009@isi.edu> <2181C5F19DD0254692452BFF3EAF1D6808C85179@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] High-level design decisions /architecture
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 Nov 2009 20:39:38 -0000

From: "Ford, Alan" <alan.ford@roke.co.uk>
Subject: Re: [multipathtcp] High-level design decisions /architecture
Date: Tue, 3 Nov 2009 18:37:56 -0000
Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808C85179@rsys005a.comm.ad.roke.co.uk>

 > > >           o [Question: Should we allow subflows in a single MPTCP
 > > >             connection to have different ports?]
 > > 
 > > Seems like you'd have to - or you have to coordinate port use on
 > > different addresses at a single endpoint constantly.
 > 
 > Yes, and we have a demuxing value (the token) anyway. However, for optimality it is proposed that the same ports are used on the same (and maybe different) addresses per connection.

Then, we might need to update Add Address option in the draft to propagate port number.
and the term Address ID might be a bit confusing.

If we think about the possibility that application can get peer's secondary IP address
outside of MPTCP (e.g. from DNS) and wants to try it, it might be convenient to 
use one single port for all subflows? 

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

v2.23.0 | Report a Bug | By Email