Re: HTTP/2 and TCP CWND

Patrick McManus <pmcmanus@mozilla.com> Mon, 01 April 2013 18: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 03AE021F91D4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Apr 2013 11:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.977
X-Spam-Level:
X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 iB79tftBfSJA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Apr 2013 11:59:04 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 225C121F90B3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 1 Apr 2013 11:59:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UMjwP-0005lM-Tq for ietf-http-wg-dist@listhub.w3.org; Mon, 01 Apr 2013 18:58:49 +0000
Resent-Date: Mon, 01 Apr 2013 18:58:49 +0000
Resent-Message-Id: <E1UMjwP-0005lM-Tq@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 1UMjwN-0005kS-D5 for ietf-http-wg@listhub.w3.org; Mon, 01 Apr 2013 18:58:47 +0000
Received: from mail-oa0-f50.google.com ([209.85.219.50]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1UMjwM-0006Fu-7N for ietf-http-wg@w3.org; Mon, 01 Apr 2013 18:58:47 +0000
Received: by mail-oa0-f50.google.com with SMTP id n1so2227616oag.23 for <ietf-http-wg@w3.org>; Mon, 01 Apr 2013 11:58:20 -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 :content-transfer-encoding; bh=vOsEHzJUAkcXNlIVQzSqPQeS7CP2lPqRc9hGVwm9Jmw=; b=ekIDDl9k3W9Pyql1OHB/+Me+5Xe0qb95Qjbp0zzVoWen5vxiXrTm+tUN4RD46eZwKs a4XYG0i6Z1WeejLiAd4w7wMVld3X2KcS3m3tQWp1XQa9w3VJt83ptI8r3B4kjW/xAKa1 SjMWjrr1ip1w6fW9rct3OkVpMc5wy+G4Ep56Ovojl+7TsALlEEIN8GhadPDkaDUSKRbo PcKdieSMtUzsTagd/zsyGJAELG9UD0z5gJBPrP1LbbJlSHlLS+052UsA+h06TAxgQLLO OXNw7qGZXRtGTZFeq0XQtDLHd8gUMuor1g/co1y44DDeLbn8Ppvk/F4g6JMWrusW7HTw TNnw==
MIME-Version: 1.0
X-Received: by 10.60.142.164 with SMTP id rx4mr4586164oeb.83.1364842700129; Mon, 01 Apr 2013 11:58:20 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.27.106 with HTTP; Mon, 1 Apr 2013 11:58:19 -0700 (PDT)
In-Reply-To: <8e7e9a7db6204492afde5d8883570579@BN1PR03MB006.namprd03.prod.outlook.com>
References: <8e7e9a7db6204492afde5d8883570579@BN1PR03MB006.namprd03.prod.outlook.com>
Date: Mon, 01 Apr 2013 14:58:19 -0400
X-Google-Sender-Auth: 5Zhtqzcxyf4p1TX78ipC9ecEps8
Message-ID: <CAOdDvNoGV=KfTnbE7LQX2Dmf_hHC0FGHgkC=9Fu_nzVGs4zH1w@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
To: Jitu Padhye <padhye@microsoft.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.50; envelope-from=patrick.ducksong@gmail.com; helo=mail-oa0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.710, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UMjwM-0006Fu-7N 88763ee48b67285636330db53484da5f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <http://www.w3.org/mid/CAOdDvNoGV=KfTnbE7LQX2Dmf_hHC0FGHgkC=9Fu_nzVGs4zH1w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17192
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 Jitu,

Heh - I've been teasing the google team for a year over when someone
would raise a serious objection to this. I figured it just meant
nobody from TSV or sigcomm had really read the draft yet :) So welcome
and thanks!

While I can go either way, I think on balance all the persistent
settings should be removed because they provide a fairly minor benefit
at the cost of a new cookie mechanism and that trade probably isn't
worthwhile. But there are benefits here, I've seen them in practice.
My reasoning is quite different than what you presented, so I want to
explain why I have some disagreements - I think its important so we
don't close the door un-necessarily to similar approaches going
forward.

On Mon, Apr 1, 2013 at 1:50 PM, Jitu Padhye <padhye@microsoft.com> wrote:

> First, if a cwnd value is persisted at the client, then, after the connection ends, it needs to be gradually decayed with time, and completely discarded if the client changes networks (e.g. from wifi to 3G etc.). This adds additional complexity to client implementation.

perhaps it should be time decayed for efficiency - but it doesn't have
to. This is just an initial setting - analagous as you say to TCP IW.
It doesn't change any of the AIMD aspects of TCP so we're not delving
into anything serious that would touch on congestion collapse, etc..

It's the classic startup problem - start sending too conservatively
and you waste bandwidth that you can never get back , start sending
too aggressively and you do (fixable) damage to yourself and other
flows and waste time and bandwidth making those corrections. Its not
clear to me which scenario is worse - they're both tragic :(

TCP basically just punts and uses a constant (IW). It could be too
small or too large. Its always the same. The CWND cookie tries to give
it a little context. It could still be too large or too small - but at
least its based on a historical path between the end points.

We've got tons of data that says TCP on HTTP/1 generally sends too
conservatively. That's a big driver behind the crude hammer of
parallel connections. They are, in large part, an application layer
mechanism to game IW - right? SPDY goes back to a small number of
connections (thankfully!) and provides this as a way to get back some
of that lost window. Its not especially more or less legitimate than
current practice imo.

> Second, the server has to take any value reported by client with a large grain of salt, since it cannot trust the client to correctly decay/discard window. The client may even inflate the window in an attempt to get "better" service. So, at the very least, the server needs to check timeliness, which means it has to maintain additional state (e.g. remember when it last sent CWND to this client). This complicates server implementation.

The server has lots of options - it isn't obligated to do anything. It
could track this information locally and not send the cookie at all.
It could honor the cookie up to some kind of max. It could just leave
it all up to TCP. This is much like dos-prevention strategies - a
whole range of things are possible.

>
> Third, The clients who implement this may be able to grab a higher share of bandwidth, which is unfair to legacy clients (e.g. normal HTTP clients).

This is my big objection to your argument that I wanted to make.

I am opposed to making "HTTP/1 fairness" a requirement of HTTP/2.
making every change be "fair" on the network with legacy traffic both
ties the hands of new innovations and removes any incentives for
deployments of the new technology. Its a big mistake imo.

Each case has to be handled on its own merits, we obviously don't want
to be un-necessarily destructive. But perfect balance doesn't need to
be a goal.

>
> If the server wants to start with a higher initial cwnd, then that's already being discussed: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-08.  I am not advocating for that proposal, but at least it is better than warm start, since there is no state to maintain and clients have no influence.

IW10 is probably important - but its still a constant.. the idea of
the cwnd cookie is that it isn't a constant. Very different.

>
> In general,  SETTINGS_CURRENT_CWND violates the basic layering principle. So, unless there is a really good reason to keep it, it should be removed.
>

layers are lovely ways of thinking about things - but they aren't
goals unto themselves. Much of SPDY is about doing parts of TCP in
HTTP anyhow in order to get a performant deployable application based
on years of previous experience seeing where the bottlenecks are. CWND
is just one more piece of that and isn't, at least to me,
objectionable on a fundamental level.

-Patrick