Re: HTTP/2 and TCP CWND

Nandita Dukkipati <nanditad@google.com> Thu, 18 April 2013 23:57 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 9B09221F8733 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Apr 2013 16:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.377
X-Spam-Level:
X-Spam-Status: No, score=-7.377 tagged_above=-999 required=5 tests=[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 i96jf0TJ0Xcl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Apr 2013 16:57:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5F21F86F7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 18 Apr 2013 16:57:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USygK-00013j-6u for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Apr 2013 23:56:00 +0000
Resent-Date: Thu, 18 Apr 2013 23:56:00 +0000
Resent-Message-Id: <E1USygK-00013j-6u@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <nanditad@google.com>) id 1USygF-00012q-NM for ietf-http-wg@listhub.w3.org; Thu, 18 Apr 2013 23:55:55 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <nanditad@google.com>) id 1USygE-0002jT-IS for ietf-http-wg@w3.org; Thu, 18 Apr 2013 23:55:55 +0000
Received: by mail-oa0-f52.google.com with SMTP id k18so3272536oag.25 for <ietf-http-wg@w3.org>; Thu, 18 Apr 2013 16:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R7rF6sn7ytt2hNMhUbZVMySEhKh2ulMn0fQssOK1KGg=; b=MW0XxbDecW+0ybKg4ASGRIu8J+xY5UGEqivaxyZ5WOAA8ifjDbe9BzqA3jXbDANMXH CaRZ+DwVJBpHld8j1cAUnWDVKukL/sp/XQEUK0iFnK2wXU2N+HbAqlSlA8Zaft/RnY9Y vK4v6BRdbNCkp6JDhLIOwuUnwv1kGxLjsXUNxIIAhZEfAo/BsvbgJBMqk4tGFWjk/RZi bydJrgFgW9+myfQQYRF9M6O1lTXIHuD6DhYFSuXZaViqU+7UxeI/sfaD5zPuBRpm7bgu /cqOAfSqhIDNBObYHEznPgp+psKkCW9AgrVauQQegjvQyWxgwzyHun9GR2PQbugn5FWe HG+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=R7rF6sn7ytt2hNMhUbZVMySEhKh2ulMn0fQssOK1KGg=; b=VsZtqEzdD6gkHA18w2g3Y9wCr8PjUfHUjn77GDJ9opDZ1HVVBgfuJIOsky+3ZLBqpy NCQMmZwc04/DC6X10AVFmDlsD0GeJX4LAXbzbNbnum1zv39uVJQMHPrXiTa0fOgJthVV B+w93/7sQ0XSP3Ls74QjvOciTsT+Ekk6NsAm/Rj98X0Dh4xDKkUP+KOKwXICpZeK8P5g TzU8b++zCba82u59ct8MtgYIg9AjF9mLU2tGBVgFm2w2je9OHyU++oRuNnrUD5EsJguS yZc/F3Bzya4K9jzQHdNfK3lw09V2wpXt+oSqSSOUxtVr2r9f+qm0bheBWuUPQgjk1kAM lnDg==
MIME-Version: 1.0
X-Received: by 10.182.204.68 with SMTP id kw4mr6678788obc.5.1366329328331; Thu, 18 Apr 2013 16:55:28 -0700 (PDT)
Received: by 10.182.75.196 with HTTP; Thu, 18 Apr 2013 16:55:28 -0700 (PDT)
In-Reply-To: <CAOdDvNpidZwfMS_y_Hy56UjOaD9uNi-s=B9MErQSq4Msd3oBKw@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> <CAOdDvNpidZwfMS_y_Hy56UjOaD9uNi-s=B9MErQSq4Msd3oBKw@mail.gmail.com>
Date: Thu, 18 Apr 2013 16:55:28 -0700
Message-ID: <CAB_+Fg7h_P3mR=dTQ1u6BroYwVm=TuqmEiZRivGAh1OG=Os8xA@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, 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="e89a8ff1c9b8435bb204daab56f1"
X-Gm-Message-State: ALoCoQnlMuA48nEzRFZnpU7QXhdvSOJgrnxmm0lbzDFZAbuF14IBRsx4ol765TT2GYoDk0WEq6QEVU/oGjyx8Ra6LD8ncKzKKswhK7soPMZ8dH/WR62r3NJ2s3EjPnErMGLun639FkLfeatdHybm0vGOu19CnsdoZycF11l6/uhWZL5TC/kD4hWmJB4DZtbaxZF2CXh1WYsx
Received-SPF: pass client-ip=209.85.219.52; envelope-from=nanditad@google.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-1.4
X-W3C-Hub-Spam-Report: 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.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USygE-0002jT-IS 21984fa72678a6c06110a854a154b95a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CAB_+Fg7h_P3mR=dTQ1u6BroYwVm=TuqmEiZRivGAh1OG=Os8xA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17351
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>

Nice points Patrick.

To me these are the high order bits for letting CWND cookie feature remain-

*  As you correctly note, apps get around the static value of initcwnd per
connection by using an arbitrarily large number of parallel connections --
compared to this crude hammer, CWND cookie feature is a saner way to start.

* It's always arguable on how valid the CWND is... but then, this is true
of any starting condition. So the question really is: Is past value from
some XXX time ago less/more wrong on average than starting with an
arbitrary constant?

* Lars and others make excellent points on the detrimental effects of large
bursts. The good news is that there are server side techniques to soften
bursts on the network in the absence of ACK clocking, so implementations
will need to handle this case effectively.

CWND-SETTING is an API which gives the transport access to long term
persistent information. As such its efficacy may be subjective without
data, so it only seems reasonable to me to let the feature remain. In an
ideal world, we would have a holistic design of a transport that
understands its application well, but short of this ideal, CWND-SETTING is
a way to take us forward.

Nandita


On Mon, Apr 15, 2013 at 6:45 PM, Patrick McManus <mcmanus@ducksong.com>wrote:

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