Re: Naive question on multiple TCP/IP channels
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 05 February 2015 14:30 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 93DE61A88CE; Thu, 5 Feb 2015 06:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, 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 SDW0mIKN8aCN; Thu, 5 Feb 2015 06:30:54 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 4D6F51A8A7E; Thu, 5 Feb 2015 06:30:54 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id w7so3371285lbi.7; Thu, 05 Feb 2015 06:30:52 -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=OTYL8ksGLss2lg+BoOcSwXP+ZL6DN/3OOVV+0SkAQeg=; b=FZeJwVeuqCptCbCCHQhevziwMn8iRBmqdgk5oQeuIZwUZrD8Z7uyqwchkZQEF5c536 7mpHO8Te03QdHQOwMh0q1EM7lfaJxb5P6w2j/1Y3zNplwX6B125VD0+Xri75kq3RFmZ0 Qy4gZHn2PcCCyheIXAgAaVlXpmkwwocrMnfkn4qLpcIkoVK7upcD7UPDrD5JZV9+5ZRi DhtKsptWPWXVCDrtRafmDyICUrrKj36vfpNoozTUT3TPJNdeA13pm9q7lPFSm0K7uVe/ IRJ9IvvlamU+vwTOHtocwf4+l3rrDuXfFqlT9vAT+pdBLy5qInqcjRf3aaw3SiR+zNmY rYww==
MIME-Version: 1.0
X-Received: by 10.152.242.132 with SMTP id wq4mr3752644lac.79.1423146652714; Thu, 05 Feb 2015 06:30:52 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Thu, 5 Feb 2015 06:30:52 -0800 (PST)
In-Reply-To: <54D2B150.3020502@gmail.com>
References: <CAMm+Lwgb9L9bUG6ommBDYJzQTCU1cC_zLSEf_5JPeJ+c=yrYmA@mail.gmail.com> <5DF6DC77-E476-408F-9FA5-F107DDC9F857@netapp.com> <54D2B150.3020502@gmail.com>
Date: Thu, 05 Feb 2015 09:30:52 -0500
X-Google-Sender-Auth: jhugRLCBP6BwfXoGstM_ZdoqKK8
Message-ID: <CAMm+LwjQcX6xQSgEsiARFLtM5RGwyOtf19cxwph3g8X_9ON5ow@mail.gmail.com>
Subject: Re: Naive question on multiple TCP/IP channels
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="001a113417f4b2d143050e5826de"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/y3Ar69-XkV9QUlW6b2Gfs73d8sY>
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: Thu, 05 Feb 2015 14:30:57 -0000
On Wed, Feb 4, 2015 at 6:54 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05/02/2015 08:49, Eggert, Lars 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 > > GridFTP only exists because of lots of experience that several parallel FTP > streams achieve better throughput than a single stream, especially on paths > with a high bandwidth-delay product. I'm guessing that since buffer bloat > creates an artificially high BDP, that could apply pretty much anywhere. > > SCTP is not the only one-acronym answer: try MPTCP. The interesting thing > there > is that because there is explicit coupling between the streams, the > throughput > increases sub-linearly with the number of streams. Buffer bloat is a great example of the consequences of the co-operative nature of the Internet for one of the audiences I am writing for (Folk trying to make/understand Title II regulations). The Internet is actually a demonstration that the commons are not such a tragedy after all. If we look at the problem of buffer bloat there are several possible solutions and the problem is picking one: * Persuade manufacturers to reduce buffer sizes so the old congestion algorithms work. * Change the congestion algorithm. * Break with the pure end to end principle and have the middleboxen with the huge buffers do some reporting back when they start to fill. The first is difficult unless you get control of the benchmarking suites that are going to be used to measure performance. Which would probably mean getting the likes of nVidia or Steam or some of the gaming companies on board. The second is certainly possible. There is no reason that we all have to use the same congestion algorithm. In fact a mixture might be beneficial. Instead of looking for packets being dropped, the sender could look at the latency and the difference between the rate packets are being sent and the rate at which acknowledgements are being received. Whether folk are willing to consider the third depends on how serious the buffer bloat problem is considered to be. If the stability of the Internet really is at stake then everything should be on the table. But my gut instinct is that a middlebox does not actually have any more useful information available to it than can be derived from the acknowledgements.
- Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: Naive question on multiple TCP/IP channels Roberto Peon
- Re: Naive question on multiple TCP/IP channels Donald Eastlake
- Re: Naive question on multiple TCP/IP channels David Morris
- Re: Naive question on multiple TCP/IP channels Eggert, Lars
- Re: Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: Naive question on multiple TCP/IP channels Christopher Morrow
- Re: Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: Naive question on multiple TCP/IP channels Christopher Morrow
- Re: Naive question on multiple TCP/IP channels Brian E Carpenter
- Re: Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: Naive question on multiple TCP/IP channels Martin Rex
- Re: Naive question on multiple TCP/IP channels Jim Gettys
- Re: Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: Naive question on multiple TCP/IP channels Jim Gettys
- Re: Naive question on multiple TCP/IP channels Phillip Hallam-Baker
- Re: [tsvwg] Naive question on multiple TCP/IP cha… Piers O'Hanlon
- Re: [tsvwg] Naive question on multiple TCP/IP cha… Jim Gettys
- Re: Naive question on multiple TCP/IP channels Wesley Eddy