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

Mark Handley <M.Handley@cs.ucl.ac.uk> Tue, 03 November 2009 21:45 UTC

Return-Path: <mark.j.handley@gmail.com>
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 79B3A3A67B5 for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 13:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.787
X-Spam-Level:
X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 SqGLfnEntNDH for <multipathtcp@core3.amsl.com>; Tue, 3 Nov 2009 13:45:30 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 725173A6767 for <multipathtcp@ietf.org>; Tue, 3 Nov 2009 13:45:30 -0800 (PST)
Received: by bwz23 with SMTP id 23so8141640bwz.29 for <multipathtcp@ietf.org>; Tue, 03 Nov 2009 13:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=XTnMcQTk+Ngh9IZsoWA08UrNoTRZYOwTSBG/raFfbCI=; b=bxjpWvLdrMIEUPsKe4JJKkCfdBDwSsP8fi6uonGnAj7unT0iD+cd/af/dp7wrz1vrH YmScI5EsUftLQ3WkYA4gxdpuKj4+RR8X81KbEL6tO9ONyxc0WjVnb6q56uv+Z3ti9fL/ fWFLoZeWCKvfu+cuYV344WB891XWAavQHoqao=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=pAd17KZJ7a3Od3OgyXVvZ+OEFQdskeg8Jl4SreYQmjWe6+o7Ygtoo1ARJWdtnxrTwf RWiAfvv6m0VOVnVgp7UODIDXjklaM5Q5MIiNpXa4cXn3XKzkPfS95P/xm3X2e10E+PG6 rskS1OsyArCUK5A/dr7NEbj5x8f2Cd4Ot84N8=
MIME-Version: 1.0
Sender: mark.j.handley@gmail.com
Received: by 10.223.21.15 with SMTP id h15mr85686fab.15.1257284748154; Tue, 03 Nov 2009 13:45:48 -0800 (PST)
In-Reply-To: <4AF0A016.8030602@isi.edu>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu> <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com> <4AF05758.4080309@isi.edu> <6E3D84BC-F010-4035-A053-76D99901294F@cs.ucl.ac.uk> <4AF05A0F.6040705@isi.edu> <84a612dd0911030843u22f0aa19u6384886afa2342d8@mail.gmail.com> <4AF0A016.8030602@isi.edu>
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Date: Tue, 03 Nov 2009 21:45:28 +0000
X-Google-Sender-Auth: 1ce28c92294a5d28
Message-ID: <84a612dd0911031345s18785fcdl610888a324210583@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="ISO-8859-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: Tue, 03 Nov 2009 21:45:31 -0000

2009/11/3 Joe Touch <touch@isi.edu>:
> Fighting could occur if the subflows send packets at the same time, even
> if the aggregate is the same as a single TCP would have sent. A single
> TCP never sends two packets out at once (it serializes them), but
> separate TCPs could easily do this (even if the OS serializes them, they
> could go out simultaneously from different NICs).
>
> Keeping in mind how TCPs like to sync, this sounds like an area to keep
> an eye on.

Good point.  I'd hope that buffers at the queue feeding the common
bottleneck would cope with this, but it's possible it makes the
behaviour of the aggregate at the bottleneck more bursty.  We've not
seen any evidence for this, but it's not something we've explicily
looked for.  Regular TCP is pretty busty though, sending a lot of
back-to-back packets unless explicit spacing is done, so I doubt
MP-TCP would be any worse in most topologies.  Still, definitely
another thing to look out for for in our experiments.

 - Mark