Re: Naive question on multiple TCP/IP channels

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 04 February 2015 20:47 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51B91A1B6A; Wed, 4 Feb 2015 12:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EX5vNFviNsT; Wed, 4 Feb 2015 12:47:15 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD7C1A1A8D; Wed, 4 Feb 2015 12:47:15 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id gq15so3795178lab.12; Wed, 04 Feb 2015 12:47:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=asMyYGdYY0CMcz3yfQBwfT7WbZFGWRzwCaQ1jfHVsKo=; b=Gk/8InXSnGggKrZqk5Djc7+jW/sey464le//lCxyE/j1zA1x0ps6NpWKXWAdpcJI54 T7h2JwHQwNNTCKHi+14dzbPR60r3CzU3gthnuBNGJ3107pWonfNFE0ZJ84s1G3hxgHFi absz2oBHcFEXODzGMjA7vPLd56mggE4zyZLkBtdllOjmRjnE5dU0OrP5E3pNsK84vrTd 3AKjxkxYsukcZha3MAvXFq9Aqylk9fZxjXvWlNdUgnqjPK7Cfmy8zaaLNXxJ0O+iuKwb wG/R6NuFJnxbP/Etkl52OgC9h1+JnAtyB1o6NDst6j1z0fpcBKlC79NTVT/YVH8M2xhU LuyQ==
MIME-Version: 1.0
X-Received: by 10.112.144.164 with SMTP id sn4mr309723lbb.2.1423082833616; Wed, 04 Feb 2015 12:47:13 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Wed, 4 Feb 2015 12:47:13 -0800 (PST)
In-Reply-To: <5DF6DC77-E476-408F-9FA5-F107DDC9F857@netapp.com>
References: <CAMm+Lwgb9L9bUG6ommBDYJzQTCU1cC_zLSEf_5JPeJ+c=yrYmA@mail.gmail.com> <5DF6DC77-E476-408F-9FA5-F107DDC9F857@netapp.com>
Date: Wed, 04 Feb 2015 15:47:13 -0500
X-Google-Sender-Auth: TIVsBIFTrSlOFu8bMduFs0_oVOc
Message-ID: <CAMm+LwjM412i4NbXhYajSKdrP2FTa7sBbu8Fca1yA9g6QWjYGQ@mail.gmail.com>
Subject: Re: Naive question on multiple TCP/IP channels
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Eggert, Lars" <lars@netapp.com>
Content-Type: multipart/alternative; boundary="047d7b3a8588c8a793050e494ad2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4YlpwzI4LzM-ETXJcwEn0w8MrhQ>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2015 20:47:17 -0000

On Wed, Feb 4, 2015 at 2:49 PM, Eggert, Lars <lars@netapp.com> wrote:

> Hi,
>
> CC'ing tsvwg, which would be a better venue for this discussion.
>
> On 2015-2-4, at 20:22, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> >
> > Today most Web browsers attempt to optimize download of images etc. by
> opening multiple TCP/IP streams at the same time. This is actually done for
> two reasons, first to reduce load times and second to allow the browser to
> optimize page layout by getting image sizes etc up front.
> >
> > This approach first appeared round about 1994. I am not sure whether
> anyone actually did a study to see if multiple TCP/IP streams are faster
> than one but the approach has certainly stuck.
>
> There have been many studies; for example,
> http://www.aqualab.cs.northwestern.edu/publications/106-modeling-and-taming-parallel-tcp-on-the-wide-area-network


thanks, looking at it now,


>
> > But looking at the problem from the perspective of the network it is
> really hard to see why setting up five TCP/IP streams between the same
> endpoints should provide any more bandwidth than one. If the narrow waist
> is observed, then the only parts of the Internet that are taking note of
> the TCP part of the packet are the end points. So having five streams
> should not provide any more bandwidth than one unless the bandwidth
> bottleneck was at one or other endpoint.
>
> You don't get more bandwidth in stead state (well, with old Reno stacks,
> you got a little more, but not much). The real win is in getting more
> bandwidth during the first few RTTs of TCP slow-start, which is the crucial
> phase when transmitting short web objects.


Ah yes, of course, there is a built in bandwidth throttle in the stack and
it is per TCP connection...

So basically we are looking at an end run round the TCP slow start which
works because the network stack congestion algorithm throttles bandwidth by
TCP connection and not per process.

I know that traditionally we have considered congestion control to be a per
connection thing rather than per process or per user. Those don't exactly
exist in the Internet model. But if we consider DDoS to be an extreme form
of congestion, we have to look at the O/S implementing broader rate
limiting anyway.


> The reason it makes a difference is that it is becoming clear that modern
> applications are not best served by an application API that is limited to
> one bi-directional stream. There are two possible ways to fix this
> situation. The first is to build something on top of TCP/IP the second is
> to replace single stream TCP with multi-stream.
>
> SCTP has what you call multiple streams in your second option, and is
> designed the same way.


Yes, I know we have proposals for both approaches. I am trying to see if
there is a case for one over the other.

If the case for multiple streams is better performance based on friendlier
slow start parameters, maybe these should be allowed without the end run.
If the net is surviving with people starting five streams instead of one,
maybe the slow start parameters could start at five packets per destination
host instead of one per connection. It would be a little more code to
implement but speed is hardly an issue where its purpose is throttling
anyway.


Making use of SCTP means that I have to rely on O/S implementation. Which
is a really long wait. So a pragmatic approach is always going to mean a
TCP+Multiplex option. If I am going to need that anyway, SCTP has to
deliver a benefit other than simplifying my code.