Re: HTTP/2 and TCP CWND

Peter Lepeska <bizzbyster@gmail.com> Wed, 24 April 2013 15:41 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 AFDD821F93B9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 08:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level:
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8AMkDX+0uaAR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 08:41:58 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D886C21F93B2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 08:41:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV1oc-0003jy-VL for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 15:41:03 +0000
Resent-Date: Wed, 24 Apr 2013 15:41:02 +0000
Resent-Message-Id: <E1UV1oc-0003jy-VL@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <bizzbyster@gmail.com>) id 1UV1oX-0003j1-NB for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 15:40:57 +0000
Received: from mail-vc0-f176.google.com ([209.85.220.176]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <bizzbyster@gmail.com>) id 1UV1oS-000760-Up for ietf-http-wg@w3.org; Wed, 24 Apr 2013 15:40:57 +0000
Received: by mail-vc0-f176.google.com with SMTP id hf12so1896021vcb.21 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 08:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Nl2CHgNqMvJV4GwWlBaiaw8wfEmDjwGojJmhzs8CGOI=; b=epXM3nRsAmwKKsQdHBJZSMJa+x2LUs+RagR0K8htYVPCSwM1hkkGsYu2FM3CgyZPZO ubmsGm9z6O1KY1lbZccQTctQbsngMXqI5/J53Nlv31YGOvghqlkDI1toYp4Ry8DquLwX 7No0jCqpJCR31/iQgFLLxZKmCwHLNNTlm4MUN48N5TWBynI28vBh6Es7xQSWDTKai2ki XEfo8TuKYT/LKuErA+2AXK9DeI1jErI7N2SkhIws+TzoPb65ol9P6LXpu8mqRre4QtxU nAV/dtY8NtzaOHEPG+CJMPP73aVkr/Fq9mIggogXL8r7kSi5X7jLGKP9LyKYZE89g25S +Idg==
MIME-Version: 1.0
X-Received: by 10.52.170.143 with SMTP id am15mr21367918vdc.87.1366818027353; Wed, 24 Apr 2013 08:40:27 -0700 (PDT)
Received: by 10.59.10.227 with HTTP; Wed, 24 Apr 2013 08:40:27 -0700 (PDT)
In-Reply-To: <CAP+FsNd97LUZNRJrf=vCc_tmnxn8ygGZ4EyOfVywt=cuc_qutA@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>
Date: Wed, 24 Apr 2013 11:40:27 -0400
Message-ID: <CANmPAYFhD8kwiM5F1vG0A5Thkrf4Dmw+64nDhvOjzPDVONU7mQ@mail.gmail.com>
From: Peter Lepeska <bizzbyster@gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: "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=e89a8ff24c71fe6d2a04db1d1eed
Received-SPF: pass client-ip=209.85.220.176; envelope-from=bizzbyster@gmail.com; helo=mail-vc0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UV1oS-000760-Up 66010d61be4b32418e80d17230b403e4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CANmPAYFhD8kwiM5F1vG0A5Thkrf4Dmw+64nDhvOjzPDVONU7mQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17536
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>

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.

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.

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
>
>
>