Re: HTTP/2 and TCP CWND

William Chan (陈智昌) <willchan@chromium.org> Wed, 24 April 2013 16:37 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8921F93E6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Vf3UOZ7n-Q for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:37:49 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id CF68421F914C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 09:37:48 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV2ge-0003nw-QI for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 16:36:52 +0000
Resent-Date: Wed, 24 Apr 2013 16:36:52 +0000
Resent-Message-Id: <E1UV2ge-0003nw-QI@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UV2gV-0003lw-Ba for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 16:36:43 +0000
Received: from mail-qe0-f49.google.com ([209.85.128.49]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UV2gQ-0001sv-3c for ietf-http-wg@w3.org; Wed, 24 Apr 2013 16:36:43 +0000
Received: by mail-qe0-f49.google.com with SMTP id 6so1361186qeb.22 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 09:36:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KKa9vFmQFMIYXd1YDCXKmYWJaHdCD9833nECZfsJkxo=; b=BBK0j5n8Imjscql5ZVAX0D7AT4Y9Zky+1JauFoQx2oYC3TrQVAFchW94+pJ3w0Dj7R BKQhvgd9pPztq/PEl74r+/5DM3SsYBkms/wv/8dUJjj6et/9sSEVRnuTIWw2QCweY7ZO VKLY02BZQQtxU2r8HXE0XZNhR0MQGwTEMQelD+W/b0cK1OJgU7wqIRY2E5BmcUph6Rt+ TdIfAKbrpJOl8Xfk8uPE4A/9xz4fGgDx5vMj3obzUolYW0yrasBS3oxM5usMTDbSsmcD PwAsngXmgoOCD+GY/M+6VvAl9eZ7dRaiZXA/KVjGKxkPQ5Eu9BQKjzYoh6MdnDEAEmiC Ynsg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KKa9vFmQFMIYXd1YDCXKmYWJaHdCD9833nECZfsJkxo=; b=eMIJk2cbGAr4j5PNuj29ve4mAxug1VYskAZBNWzq9XkjKkwNItk0IOE5YKxcDwCDM3 /gfB5Pqc18aFT22GgwA9hg1E0dqxbXSh2NIKZbZNUrs9nLQqabSUvuShxtBVFHA0f0p8 IJ8WSDpDQdiS767qQbHcEWN15r8GuRbIR30aE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KKa9vFmQFMIYXd1YDCXKmYWJaHdCD9833nECZfsJkxo=; b=DgwfsOTM+53Z2FiHoU+UmMgGHHlV2TjuGhmJxu+zMdsGmbbf9KmGwRK7XaZs8btE77 lwt/eTrMwyHIP40rYYZaGAp5qP0sb4D2yCi1zQJeGDaNkdSZXTSivwnr0Mutnub5Rbdy 4v7AeSXeYr+Cju1NtzlMvcLr1aqwve2iXYlogA0hj5TzqRqkKBCBS2LlzTbwBzmEfVe+ yrRwVcuQc/w8OybjJgQ44byNr0vVuktCusUZDULf93bgrdAboo4fztQxTMtl39UnTa0U oRRJ/PIZxTN3NkNoeIYsq5sS1YDs53scbml7R1Uz38TTxd4H3ZetbrMlRePl8BODjt5h X9GQ==
MIME-Version: 1.0
X-Received: by 10.49.82.45 with SMTP id f13mr15420403qey.53.1366821372202; Wed, 24 Apr 2013 09:36:12 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Wed, 24 Apr 2013 09:36:09 -0700 (PDT)
In-Reply-To: <CANmPAYFhD8kwiM5F1vG0A5Thkrf4Dmw+64nDhvOjzPDVONU7mQ@mail.gmail.com>
References: <516B8824.8040904@cisco.com> <DF8F6DB7E5D58B408041AE4D927B2F48CBB88103@CINURCNA14.e2k.ad.ge.com> <CAP+FsNfeUtKfOMPKriYP7Ak_YzsjEFKvprJOAQaxYP7_BxTBsw@mail.gmail.com> <cf53405c48dc431693573a9148776c8a@BN1PR03MB072.namprd03.prod.outlook.com> <8B0AAE84-CAB8-483B-99FD-DA6A0CA13395@netapp.com> <CAP+FsNca6TOB2B-ntnEHvzPx3JY=6Qcp34RgF7uQsbdsLUbptQ@mail.gmail.com> <95367D0C-D34C-4542-A0DE-921BBDE6A239@netapp.com> <CAP+FsNfGBYXABwLJJMk6rC_GAMVD2RXaMFEu93oGwMaCuCzN7Q@mail.gmail.com> <856946E5-2239-40BB-AC2D-716D6FDAA9FF@netapp.com> <CAP+FsNd97LUZNRJrf=vCc_tmnxn8ygGZ4EyOfVywt=cuc_qutA@mail.gmail.com> <CANmPAYFhD8kwiM5F1vG0A5Thkrf4Dmw+64nDhvOjzPDVONU7mQ@mail.gmail.com>
Date: Wed, 24 Apr 2013 09:36:09 -0700
X-Google-Sender-Auth: 0wj3_KByPYesEfKioM7xnoJgaN4
Message-ID: <CAA4WUYi+ewPmapspBETX=7m1Pxvft2u7C_7MHVJ7h1s0BFWN-Q@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, "Eggert, Lars" <lars@netapp.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, Eliot Lear <lear@cisco.com>, Robert Collins <robertc@squid-cache.org>, Jitu Padhye <padhye@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, Dave Thaler <dthaler@microsoft.com>, Martin Thomson <martin.thomson@skype.net>, Martin Stiemerling <martin.stiemerling@neclab.eu>
Content-Type: multipart/alternative; boundary=047d7b5dbf325caa6904db1de695
X-Gm-Message-State: ALoCoQnA/66EKZdhFWcmWoFl+NwjZpvZHNIDaaARNead66IpIox1CAPlATmml6tyfahwYU+faxPn3673MafYDtZ13gnpwGkzPtKBlI0uWl3wJQwvC2GWW6rm7Y6oX/CsyesNJ6iue9RC1gQSPb9nXx4LL9rdKKpO7il1YtbzB2Y3ZzCQoXelOKin1osW4e0PTzgj02SqCPDn
Received-SPF: pass client-ip=209.85.128.49; envelope-from=willchan@google.com; helo=mail-qe0-f49.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.712, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UV2gQ-0001sv-3c eed31bba5f4296435a4235aee34d0994
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CAA4WUYi+ewPmapspBETX=7m1Pxvft2u7C_7MHVJ7h1s0BFWN-Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17539
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Wed, Apr 24, 2013 at 8:40 AM, Peter Lepeska <bizzbyster@gmail.com>; wrote:

> Not sure this has been proposed before, but better than caching would be
> dynamic initial CWND based on web server object size hinting.
>
> Web servers often know the size of the object that will be sent to the
> browser. The web server therefore can help the transport make smart initial
> CWND decisions. For instance, if an object is less than 20KB, which is true
> for the majority of objects on web pages, the web server could tell the
> transport to increase the CWND to a size that would allow the object to be
> sent in the initial window.
>

In the HTTP/2 case where we often are multiplexing, this doesn't seem to
make as much sense. Also, I'm not sure that it's a reasonable argument to
select initcwnd in absence of any congestion information...or were you
suggesting merely tweaking the initcwnd a little bit if that little bit
would make a difference in terms of fitting the whole object in the
initcwnd?

Caching attempts to reuse old congestion information, although it has been
reasonably pointed out that the validity of that information is
questionable. It's an open research question as far as I'm concerned, and
I'd love to see any data people had.


>
> For larger objects, the benefit of a large CWND is minimal so the web
> server could tell the transport to use the default and let the connection
> ramp slowly.
>

I'm not sure this makes sense. GMail and Google+ and I'm sure other large
web apps have rather large scripts and stylesheets, but they still care
about their initial page load latency. Perhaps you're making the assumption
that large objects implies the user does not have interactivity /
low-latency expectations? If so, that's invalid. Those roundtrips still
matter and I can tell you our Google app teams work very hard to eliminate
them. Or maybe your definition is large is larger than what I'm thinking.


> Peter
>
>
>
>
> On Mon, Apr 15, 2013 at 8:16 PM, Roberto Peon <grmocg@gmail.com>; wrote:
>
>>
>>
>>
>> On Mon, Apr 15, 2013 at 4:03 PM, Eggert, Lars <lars@netapp.com>; wrote:
>>
>>> Hi,
>>>
>>>
>>> On Apr 15, 2013, at 15:56, Roberto Peon <grmocg@gmail.com>; wrote:
>>> > The interesting thing about the client mucking with this data is that,
>>> so
>>> > long as the server's TCP implementation is smart enough not to kill
>>> itself
>>> > (and some simple limits accomplish that), the only on the client harms
>>> is
>>> > itself...
>>>
>>> I fail to see how you'd be able to achieve this. If the server uses a
>>> CWND that is too large, it will inject a burst of packets into the network
>>> that will overflow a queue somewhere. Unless you use WFQ or something
>>> similar on all bottleneck queues (not generally possible), that burst will
>>> likely cause packet loss to other flows, and will therefore impact them.
>>>
>>
>> The most obvious way is that the server doesn't use a CWND which is
>> larger than the largest currently active window to a similar RTT. The other
>> obvious way is to limit it to something like 32, which is about what we'd
>> see with the opening of a mere 3 regular HTTP connections! This at least
>> makes the one connection competitive with the circumventions that HTTP/1.X
>> currently exhibits.
>>
>>
>>> TCP is a distributed resource sharing algorithm to allocate capacity
>>> throughout a network. Although the rates for all flows are computed in
>>> isolation, the effect of that computation is not limited to the flow in
>>> question, because all flows share the same queues.
>>>
>>
>> Yes, that is what I've been arguing w.r.t. the many connections that the
>> application-layer currently opens :)
>> It becomes a question of which dragon is actually most dangerous.
>>
>> -=R
>>
>>
>>>
>>> Lars
>>
>>
>>
>