Re: Quoting email (was: HTTP/2 and TCP CWND)

Roberto Peon <grmocg@gmail.com> Tue, 16 April 2013 18:52 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 27AFF21F9356 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 11:52:55 -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 DCdhJlnWMId7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 11:52:51 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 114F321F92C0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 11:52:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USAzY-0007hA-Ow for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Apr 2013 18:52:32 +0000
Resent-Date: Tue, 16 Apr 2013 18:52:32 +0000
Resent-Message-Id: <E1USAzY-0007hA-Ow@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1USAzS-0007fG-87 for ietf-http-wg@listhub.w3.org; Tue, 16 Apr 2013 18:52:26 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1USAzN-0004Jx-FJ for ietf-http-wg@w3.org; Tue, 16 Apr 2013 18:52:26 +0000
Received: by mail-ob0-f177.google.com with SMTP id ef5so213213obb.36 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 11:51:55 -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=l9rscoxgQ3P/r9mBaNMPrH7d8O9b86faHEBjTgWEq4k=; b=dHKLGHt3tmnZ4URR6dvNmOSBTAbfySqZhdKWQoIOOBRoXngdfGIZOAMdyBeQtZsMWq LmLYn30u57FM5fMD55JeD+AycrA9/U17qhv5cRrGSk/Il+I5rFaGlZm2E/LSTQTthYr3 +xpcB1bmfhiYpupeGBkB9E4SUg8HqiuSO80rtHAYLb6K8wbwrIJAT5snJWDbwOG9jSK0 5tuV6HHtEfaZ0Pta9GYgJHrPkKk/Cs8yY3wOSvK0YxiFyXk3o4ckqC/eWKNcgODZft9R B4bbb3xtkyL8/UQtEoMZWYfckipdAVm5/V0cyp3m6wpR+0Ccf++bd+XtpeZm2TQQj0pO b9gA==
MIME-Version: 1.0
X-Received: by 10.182.226.162 with SMTP id rt2mr1287203obc.9.1366138315230; Tue, 16 Apr 2013 11:51:55 -0700 (PDT)
Received: by 10.76.141.83 with HTTP; Tue, 16 Apr 2013 11:51:55 -0700 (PDT)
In-Reply-To: <CAP+FsNcyBDuOm9U5+fmJQmWEY0=QYtoNb-yLg1Jz2on5Ncyagg@mail.gmail.com>
References: <CABkgnnUH+vYF2Q=jkOsoBsTD6ipBQ84UDvuN9EZyBM=vDrE1rQ@mail.gmail.com> <DF8F6DB7E5D58B408041AE4D927B2F48CBB897DD@CINURCNA14.e2k.ad.ge.com> <CAP+FsNcyBDuOm9U5+fmJQmWEY0=QYtoNb-yLg1Jz2on5Ncyagg@mail.gmail.com>
Date: Tue, 16 Apr 2013 11:51:55 -0700
Message-ID: <CAP+FsNdQwyZkWQqG51Yz65o1Bs8oDx6LkL=pHXAhgJtB64O07w@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a11c2e93cfe582704da7edc63"
Received-SPF: pass client-ip=209.85.214.177; envelope-from=grmocg@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.668, 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: maggie.w3.org 1USAzN-0004Jx-FJ d7dca3d17fe11702bae82cdf319b3c9f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Quoting email (was: HTTP/2 and TCP CWND)
Archived-At: <http://www.w3.org/mid/CAP+FsNdQwyZkWQqG51Yz65o1Bs8oDx6LkL=pHXAhgJtB64O07w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17269
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>

Spelling mistakes are free.
-=R


On Tue, Apr 16, 2013 at 11:51 AM, Roberto Peon <grmocg@gmail.com> wrote:

> I'll try to make it more clear in the future.
> I believe I'm the main culpret here, btw.
> -=R
>
>
> On Tue, Apr 16, 2013 at 11:27 AM, Simpson, Robby (GE Energy Management) <
> robby.simpson@ge.com> wrote:
>
>> Another attempt
>>
>>
>> >>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..
>>
>>
>>
>