Re: HTTP/2 and TCP CWND

Roberto Peon <grmocg@gmail.com> Tue, 16 April 2013 16:04 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 237D021F9734 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 09:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 xZfJw8zR-sMv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 09:04:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E821F9742 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 09:04:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1US8MS-0001wZ-97 for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Apr 2013 16:04:00 +0000
Resent-Date: Tue, 16 Apr 2013 16:04:00 +0000
Resent-Message-Id: <E1US8MS-0001wZ-97@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1US8MP-0001vt-9H for ietf-http-wg@listhub.w3.org; Tue, 16 Apr 2013 16:03:57 +0000
Received: from mail-ob0-f175.google.com ([209.85.214.175]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1US8MN-00030Z-WE for ietf-http-wg@w3.org; Tue, 16 Apr 2013 16:03:57 +0000
Received: by mail-ob0-f175.google.com with SMTP id va7so582338obc.20 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 09:03:30 -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=Wf/tn73cBA2wm1PEnIVOOF97WTGO0MhMx4SNLEbjb+k=; b=qGoT7V/A592Fe7p+nxK40M1Q1t93IMJI3DgAn3OjYyCssUgbWvaJyOLZJESpV1rb/7 bOqcY35ILdvz4tw372Yo05iB2PW86dd5Jw601eHzduHKJS7SCjgOrpCpmQo5OKGRZmmG 7ATaAOJrDhoBJQLOW2vLasdUnDYIkVHCEpH791El8jD6wY09wtPinYFpQib5GPmxdwpy 5ClMZ9ZAw4b1qBaZcY3A6RSVD2ODc2hf2EknhsbvlaVXOrnD33EVx9VrMOgDZdf7qrmU UpkwO7FuJS6RBTYiqx9bzFVx6egIa999y46y42J6onYfimM2Vlc4tEnJhSMeOTXVR3CB TaOw==
MIME-Version: 1.0
X-Received: by 10.60.146.162 with SMTP id td2mr1099794oeb.32.1366128209920; Tue, 16 Apr 2013 09:03:29 -0700 (PDT)
Received: by 10.76.141.83 with HTTP; Tue, 16 Apr 2013 09:03:29 -0700 (PDT)
Received: by 10.76.141.83 with HTTP; Tue, 16 Apr 2013 09:03:29 -0700 (PDT)
In-Reply-To: <DF8F6DB7E5D58B408041AE4D927B2F48CBB8940D@CINURCNA14.e2k.ad.ge.com>
References: <856946E5-2239-40BB-AC2D-716D6FDAA9FF@netapp.com> <DF8F6DB7E5D58B408041AE4D927B2F48CBB8940D@CINURCNA14.e2k.ad.ge.com>
Date: Tue, 16 Apr 2013 09:03:29 -0700
Message-ID: <CAP+FsNfEjTN=xQt7OcXgA84rhN1jncq=iSF9ZLJ05xiqDwfiFQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: "Robby Simpson, (GE Energy Management)" <robby.simpson@ge.com>
Cc: "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, Eliot Lear <lear@cisco.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "Eggert, Lars" <lars@netapp.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Dave Thaler <dthaler@microsoft.com>, Martin Thomson <martin.thomson@skype.net>, Robert Collins <robertc@squid-cache.org>, Martin Stiemerling <martin.stiemerling@neclab.eu>, Jitu Padhye <padhye@microsoft.com>
Content-Type: multipart/alternative; boundary="047d7b5d42d8ab8c8004da7c82ca"
Received-SPF: pass client-ip=209.85.214.175; envelope-from=grmocg@gmail.com; helo=mail-ob0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.683, 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 1US8MN-00030Z-WE 19ffbcfc2e40334b6a45702b3a88b0e2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CAP+FsNfEjTN=xQt7OcXgA84rhN1jncq=iSF9ZLJ05xiqDwfiFQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17259
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>

Unfortunately, most flows with http/1 are short (and bursty) flows, so it
is incorrect to say that they have reached steady-state w.r.t. congestion
control. Many resource fetches complete in between one and three rtts, then
much of time the connection(s) sit idle for extended periods of time
(seconds to minutes).

I'm hoping Will will chime in here with data soon, but the distribution on
single connection cwnds as measured on traffic in the wild shows us that
using multiple connections puts more packets on the wire as a result of
init-cwnd (and thus not subject to congestion control, ouch) than a single
stable-state, heavily used and reused connection such as Spdy or HTTP/2
would allow.

This is happening now, the data is there now.

Multiple connections is worse, and it is the common case, and it is getting
to be even more of a problem month by month.

And I'm not even talking about how multiple http connections deal with loss
vs the one...

I agree that solving the problem for http/2 alone won't fix it for
everything. On the other hand, we also need to act swiftly to solve
problems on timescales that matter to users, and http is a fine venue for
that. The fact that http/2 could do this doesn't stop us from coming up
with an opaque blob that *any* latency sensitive application protocol
could use to communicate with the transport layer.

Really, all this is is an API which allows the transport layer to
communicate with a future instantiation of itself...
-=R


On Apr 16, 2013 8:00 AM, "Simpson, Robby (GE Energy Management)" <
robby.simpson@ge.com> wrote:

> It appears to me that the chief concern is in regards to HTTP/2's use of a
> single flow vs. HTTP/1's use of multiple flows.  I fail to see how
> changing CWND is going to make a difference (except for a beginning,
> potentially nasty, burst) since, if the flows are sharing the same
> end-to-end paths, they will still be competing and will steady-state to
> "equal" CWND's.
>
>
> Further, this is not specific to HTTP/2.  There are plenty of other
> applications out there using TCP that have suffered from HTTP/1's use of
> multiple simultaneous flows.  I fail to see how HTTP/2 is in a better
> situation to correct that issue than any other application or, more
> importantly, than the appropriate layer (4) or the offender (HTTP/1).
>
> Am I missing something, or is the concern really that some folks are
> looking for a way to throttle or compete with HTTP/1 flows?
>
> - Robby
>
>