IETF Logo Mail Archive

Re: [multipathtcp] MPTCP Architecture Draft available

Dominik Kaspar <dokaspar.ietf@gmail.com> Tue, 20 October 2009 16:56 UTC

Return-Path: <dokaspar.ietf@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 D4F1828C0F0 for <multipathtcp@core3.amsl.com>; Tue, 20 Oct 2009 09:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 e96t4+uTTd9a for <multipathtcp@core3.amsl.com>; Tue, 20 Oct 2009 09:56:35 -0700 (PDT)
Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by core3.amsl.com (Postfix) with ESMTP id BABC63A68E4 for <multipathtcp@ietf.org>; Tue, 20 Oct 2009 09:56:31 -0700 (PDT)
Received: by gv-out-0910.google.com with SMTP id e6so618247gvc.15 for <multipathtcp@ietf.org>; Tue, 20 Oct 2009 09:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oo+TA67TmnX6I4YpN4smX3fqpi3d/EQWnFZOhqkPVx0=; b=suDlII5kCrRVsFbi37SSZlZMC50Y2fC+eQA+eYUkBhzfPS+G56gWHj5rwKDpFQBfYs niuN/1y+wepNY/Oe+cTuoA2bJumURPRocF33LKjfULHa1E9ZqSyPO90WUIoW2TGiLBtm nBsxhhsWjxB+2V0TDMdD+sXRyQZZd58zOWJsg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IXLvoTspTWUSuUUFyssb1Yx0phE+GbvUWe96gu4eQnOrzGWsxMLWtIJfnJt/Uuzp3l ugihPiP44SeMSkUz5xLh42clw0ZsDNwpwLAeg2mZNItaAolppdW2m1tohOQoY4PIcdf2 vcd45AvcAdKp8IyUPTw5v4tv25sfccXxO4uLY=
MIME-Version: 1.0
Received: by 10.103.127.32 with SMTP id e32mr2917756mun.70.1256057796481; Tue, 20 Oct 2009 09:56:36 -0700 (PDT)
In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk>
References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk>
Date: Tue, 20 Oct 2009 18:56:36 +0200
Message-ID: <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com>
From: Dominik Kaspar <dokaspar.ietf@gmail.com>
To: "Ford, Alan" <alan.ford@roke.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] MPTCP Architecture Draft available
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, 20 Oct 2009 16:56:35 -0000

Dear authors,

In my opinion, MPTCP has a great potential benefits for resource
pooling when a single, long-lasting, high-bitrate transport stream is
present. On the other hand, MPTCP's use of multiple paths might risk
performance degradation, which seems not to be addressed in this
draft.

For example, in our testbed, we have a host with two wireless
interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface
with roughly the following access network characteristics:

WLAN: 600 KB/s, 10 ms RTT
HSDPA: 300 KB/s, 100 ms RTT

MPTCP would be perfect for aggregating both links, achieving 900 KB/s
and providing a better user experience for "bulk" data transfers, such
as video streaming and large file downloads.

However, if the goal is to download a large number of small-sized
files (for instance downloading and displaying a thumbnail image
gallery), a new problem arises. Due to the large difference in access
latency, the WLAN interface might be able to finish the entire
download of a single file even before a connection can be established
of the HSDPA interface. In this case, opening an MPTCP connection for
each file may result in performance degradation and it may be much
more efficient to let the WLAN interface download 67% of the files and
the HSDPA the remaining 33%...

Except from a short paragraph on "support for small transactions",
this draft seems to lack a motivation for when MPTCP should be used,
when it should not be used, and how such a decision can be made. Are
such decisions made by the Path Managers or left to the application
developer?

Best regards,
Dominik


On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan <alan.ford@roke.co.uk> wrote:
> Hi all,
>
> We have started work on the beginnings of an Multipath TCP architecture
> draft, combining some of the implementation separation that featured in
> the -01 of the mptcp/multiaddressed draft with some architectural
> considerations from Tng.
>
> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt
>
> Comments welcome - but please remember this is very early days!
>
> Cheers,
> Alan
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

v2.23.0 | Report a Bug | By Email