Re: HTTP/2 and TCP CWND

Patrick McManus <mcmanus@ducksong.com> Tue, 16 April 2013 01:47 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 9C70721E8043 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Apr 2013 18:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Level:
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5wMayAPQUM4R for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Apr 2013 18:47:09 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF321E8041 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 15 Apr 2013 18:47:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1URuxq-00064G-1l for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Apr 2013 01:45:42 +0000
Resent-Date: Tue, 16 Apr 2013 01:45:42 +0000
Resent-Message-Id: <E1URuxq-00064G-1l@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1URuxm-000624-NA for ietf-http-wg@listhub.w3.org; Tue, 16 Apr 2013 01:45:38 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1URuxl-0003jK-O6 for ietf-http-wg@w3.org; Tue, 16 Apr 2013 01:45:38 +0000
Received: by mail-ob0-f177.google.com with SMTP id 16so2650469obc.36 for <ietf-http-wg@w3.org>; Mon, 15 Apr 2013 18:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=T7i8DhIbck6QT4fl5QMI18I4v6ipv/Vz+FWlf8JINCk=; b=jcS3E8sDqaF8KSCPu8OyDO6Sse/xzfexhCyXtuvz3VTSdAySUr/zlT7xZJpChzW3ny szxcvHkUc1o/zmjDzjKTqwg0EZMvUFUA46r429ew4fxNN5swjQgX9amhrwUtSm9oraiN Z+t0AbEmQFWEIxXYF27W3lkEVXs2XmVDr3o6Cxcswpo9wyJDO38Naar6XK4TPzLgMgSn LkecfAFmvhsEm9yL1Ma6swW7aFD0Oxef/jZku1amDa3aX02XFVJEzeP6zVOtcyRT7DQr GBk+jfzAdGir8NDG852YhiS/YIcjusxU7nv34DoUwOOmJkWZMaFpU6cRWjj4qn4P0yRn 3kOg==
MIME-Version: 1.0
X-Received: by 10.60.94.9 with SMTP id cy9mr85399oeb.58.1366076711838; Mon, 15 Apr 2013 18:45:11 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.27.106 with HTTP; Mon, 15 Apr 2013 18:45:11 -0700 (PDT)
In-Reply-To: <cf53405c48dc431693573a9148776c8a@BN1PR03MB072.namprd03.prod.outlook.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>
Date: Mon, 15 Apr 2013 21:45:11 -0400
X-Google-Sender-Auth: SDG8qpZ1WNnBF4lgF7ISPHwjPqo
Message-ID: <CAOdDvNpidZwfMS_y_Hy56UjOaD9uNi-s=B9MErQSq4Msd3oBKw@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: Roberto Peon <grmocg@gmail.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>, "Eggert, Lars" <lars@netapp.com>, Martin Stiemerling <martin.stiemerling@neclab.eu>
Content-Type: multipart/alternative; boundary="089e01229a90252b9e04da70854c"
Received-SPF: pass client-ip=209.85.214.177; envelope-from=patrick.ducksong@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.754, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 1URuxl-0003jK-O6 3f988097794ece0f589878422f6096fa
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CAOdDvNpidZwfMS_y_Hy56UjOaD9uNi-s=B9MErQSq4Msd3oBKw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17244
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>

Hi All,

The problem being addressed here isn't a hypothetical one, nor is it
resolved separately by IW10.. but it is one that specially impacts HTTP
because of its history of parallel connection [ab]use and the goal of
HTTP/2 to transition away from that. SETTINGS may or may not be the way to
do it. Expertise is always welcome, but the topic is completely germane as
far as I am concerned.

One of the deficiencies of IW10 is derived from its adherence to layering
separation - it works only on the TCP level. So you get IW=10 whether there
is 1 connection (SPDY), 6 connections (HTTP/1), or 36 connections (6 way
sharded HTTP/1). At the TCP level of course, the stack has no idea which to
use - IW is just a default config for new connections. If it uses IW=3 and
there is 1 SPDY connection then that decision likely has a large
opportunity cost in terms of un-utilized bandwidth.. if it uses IW=10 and
there are 36 HTTP/1 connections then congestion is self-induced and a train
wreck of packet loss ensues and the cost is paid in retransmissions, out of
order deliveries, timers, etc.. (This happens today on a fairly prominent
CDN). Both scenarios are suboptimal, as there is no perfect constant, but
in neither case does the Internet collapse or the page even fail to load.

Its totally reasonable to experiment with how HTTP/2 can improve this
unfortunate situation.

As Roberto says, giving applications a knob to do this reasonably removes
the need for them to do it unreasonably and less effectively with a hammer.

If we break down the arbitrary layer barrier and inject some history into
the algorithm, in this case via SETTINGS, you get something more powerful
than a default constant. Part of what you inject is traditional L4
information (what was our CWND before) which is much more interesting than
a constant, but the other thing you implicitly inject is information that
this flow carries SPDY and therefore won't be engaging in rampant
parallelization. (This latter bit can actually be done by the
implementation without help from the wire protocol, but being comfortable
with that opens the door for the protocol to create a better implementation
via the SETTINGS frame).

-Patrick