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

Costin Raiciu <c.raiciu@cs.ucl.ac.uk> Thu, 05 November 2009 13:20 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 6ACBF28C0D6 for <multipathtcp@core3.amsl.com>; Thu, 5 Nov 2009 05:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 YKdzMUoX-exM for <multipathtcp@core3.amsl.com>; Thu, 5 Nov 2009 05:20:17 -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 8EF923A6824 for <multipathtcp@ietf.org>; Thu, 5 Nov 2009 05:20:17 -0800 (PST)
Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N62Ct-000CKl-V0; Thu, 05 Nov 2009 13:16:55 +0000
In-Reply-To: <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <2181C5F19DD0254692452BFF3EAF1D6808C85177@rsys005a.comm.ad.roke.co.uk> <20091104.195734.88191535.nishida@sfc.wide.ad.jp> <3B0898A2-0F7E-4128-B789-AC54A5D64B56@cs.ucl.ac.uk> <93D4E6CB-455F-4A4E-B8B3-2A0BDC2E2903@nokia.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <4E0E2C9F-28F7-4A09-8105-D095BDBBA71B@cs.ucl.ac.uk>
Content-Transfer-Encoding: 7bit
From: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
Date: Thu, 05 Nov 2009 13:20:21 +0000
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.753.1)
Cc: "multipathtcp@ietf.org" <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: Thu, 05 Nov 2009 13:20:18 -0000

Hm. The problem with per subflow receive window is ensuring you don't  
create deadlocks. Sebastien Barre already found a case where a  
deadlock can appear, and I imagine there are many more.

I do agree it's a neat way to control policy, but I am afraid it may  
introduce more problems than it solves.
Costin

On 4 Nov 2009, at 19:03, Lars Eggert wrote:

> 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.
>
> Lars