IETF Logo Mail Archive

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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 04 November 2009 20:19 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 D91B228C133 for <multipathtcp@core3.amsl.com>; Wed, 4 Nov 2009 12:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.16
X-Spam-Level: *
X-Spam-Status: No, score=1.16 tagged_above=-999 required=5 tests=[AWL=0.256, 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 Fm5CkVK4qK-d for <multipathtcp@core3.amsl.com>; Wed, 4 Nov 2009 12:19:42 -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 E030328C11D for <multipathtcp@ietf.org>; Wed, 4 Nov 2009 12:19:41 -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 DEC704C0BE; Thu, 5 Nov 2009 05:19:58 +0900 (JST)
Date: Thu, 05 Nov 2009 05:19:58 +0900
Message-Id: <20091105.051958.02289937.nishida@sfc.wide.ad.jp>
To: lars.eggert@nokia.com
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
In-Reply-To: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com>
References: <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com>
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: Wed, 04 Nov 2009 20:19:42 -0000

From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [multipathtcp] High-level design decisions /architecture
Date: Wed, 4 Nov 2009 11:03:10 -0800
Message-ID: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com>

 > On 2009-11-4, at 3:15, Costin Raiciu wrote:
 > > This is an open issue indeed. If the endpoint is sending, it can
 > > control how much data to put on each subflow. When it's receiving,
 > > our current thinking is to use ECN (or worse, packet drops) to reduce
 > > the bandwidth on a given subflow.
 > 
 > With per-subflow receive windows, you can use receive window tuning,
 > too.

Well, that's an idea. Yes, I agree.
I tend to agree that this can be a open issue now. But, I still have a naive question...

Compared to having a tweaky algorithm at receiver side, doing simple 
negotiation during SYN exchange would be that difficult? (and probably we will
also need to use 1 bit in Add Address option to specify primary path or etc, 
but it's still simple.) 
If we think about a small gudget like iphone, I guess simple receiving 
algorithm might be preferable.

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

v2.23.0 | Report a Bug | By Email