IETF Logo Mail Archive

Re: HTTP/2 and TCP CWND

"Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com> Tue, 16 April 2013 17:59 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 7484B21F96E5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 10:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 L1aV2XPgydyx for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 10:59:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D484E21F96D7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 10:59:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USA9z-0005kc-2u for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Apr 2013 17:59:15 +0000
Resent-Date: Tue, 16 Apr 2013 17:59:15 +0000
Resent-Message-Id: <E1USA9z-0005kc-2u@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <robby.simpson@ge.com>) id 1USA9v-0005jV-G0 for ietf-http-wg@listhub.w3.org; Tue, 16 Apr 2013 17:59:11 +0000
Received: from exprod5og114.obsmtp.com ([64.18.0.28]) by maggie.w3.org with smtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <robby.simpson@ge.com>) id 1USA9u-0002R6-I2 for ietf-http-wg@w3.org; Tue, 16 Apr 2013 17:59:11 +0000
Received: from cinmlip12.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob114.postini.com ([64.18.4.12]) with SMTP ID DSNKUW2RWP8YI8YIDAR/THcDkg/r7QbLM7th@postini.com; Tue, 16 Apr 2013 10:59:10 PDT
Received: from unknown (HELO alpmlef06.e2k.ad.ge.com) ([3.159.18.15]) by cinmlip12.e2k.ad.ge.com with ESMTP; 16 Apr 2013 13:58:47 -0400
Received: from cinmlef17.e2k.ad.ge.com ([3.159.213.93]) by alpmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Apr 2013 13:58:46 -0400
Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef17.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Apr 2013 13:58:46 -0400
Received: from CINURCNA10.e2k.ad.ge.com (3.159.212.127) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Apr 2013 13:58:40 -0400
Received: from CINURCNA14.e2k.ad.ge.com ([169.254.2.141]) by CINURCNA10.e2k.ad.ge.com ([169.254.4.227]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 13:58:40 -0400
From: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
To: Roberto Peon <grmocg@gmail.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>
Thread-Topic: HTTP/2 and TCP CWND
Thread-Index: AQHOOia9D8HEzB3rR8CdUf/Gdhfe25jYH2KAgAAIQICAAAHrgIAAyCKAgABU8ID//90dgA==
Date: Tue, 16 Apr 2013 17:58:39 +0000
Message-ID: <DF8F6DB7E5D58B408041AE4D927B2F48CBB89724@CINURCNA14.e2k.ad.ge.com>
In-Reply-To: <CAP+FsNfEjTN=xQt7OcXgA84rhN1jncq=iSF9ZLJ05xiqDwfiFQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [3.159.212.191]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <64D639C65F477540B35BF60D87CEE404@mail.ad.ge.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Apr 2013 17:58:46.0066 (UTC) FILETIME=[0A49A120:01CE3ACC]
Received-SPF: none client-ip=64.18.0.28; envelope-from=robby.simpson@ge.com; helo=exprod5og114.obsmtp.com
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=-0.575, RCVD_IN_DNSWL_MED=-2.3
X-W3C-Scan-Sig: maggie.w3.org 1USA9u-0002R6-I2 51d391211a34c19c3206fe3d98f54325
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/DF8F6DB7E5D58B408041AE4D927B2F48CBB89724@CINURCNA14.e2k.ad.ge.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17262
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 4/16/13 12:03 PM, "Roberto Peon" <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:

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

Good point.  Most of my work with HTTP/1 (and TCP) are with long-lived flows and I live in the long tail.  My gut tells me you are correct when it comes to traditional web usage.

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.

Wouldn't Spdy or HTTP/2 still face the issues regarding steady-state then?

Part of my concern is that we may, once again, create an HTTP that unfairly dominates traffic due to lots of bursty flows.

<snip>

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.

As someone stated earlier, I fear the opposite to be true.  This may end up slowing down HTTP/2 and not be swift at all..

v2.38.3 | Report a Bug | By Email | System Status