Re: HTTP/2 and TCP CWND

[Yuchung Cheng <[e-mail]>]

On Wed, Apr 17, 2013 at 11:12 AM, Patrick McManus <[e-mail]> wrote:
> Hi Wes,
>
> On Wed, Apr 17, 2013 at 12:48 PM, Wesley Eddy <[e-mail]> wrote:
>>
>>
>> It's definitely misinformation given the dynamic nature of the
>> CWND variable in TCP.  This is not a path property like MTU that
>> can be thought of as relatively static, and it can change on short
>> timescales with high granularity.
>
>
> Granted, an old CWND measurement can be inaccurate. It's an informed guess
> based on path performance. I'm sure we agree the path plays a
> (non-definitive) role in this.
>
> The alternative, IW, is an inaccurate guess too. Its an uninformed guess and
> I don't see why we should assume it would be more accurate.
>
> We can't argue that IW10 is strictly more conservative because my data says
> it typically isn't.  (median SPDY CWND SETTING in firefox data is 30 x 1
> session.. apples to apples that compares to at least 6 parallel HTTP/1
> sessions of IW 10 each). Roberto suggested he's seen something similar. I'm
> not sure that more conservative is a better thing anyhow but I don't see how
> it applies in this case in any event.
I'd like to give some historical perspective of IW10 and CWND-SETTING,
as I proposed both to tcpm and the SPDY team. Three years when we
started looking at the TCP startup latency problems, we wanted to
experiment both simple fixed size  solution and a dynamic
history-based one. We were aware of the pros and cons of both
approaches. But I emphasize cwnd-setting was meant to experiment the
cwnd-caching idea that's been floating around for 20? years. It was OK
to violate the layers for experimental purposes. I agree with the
consensus on the list to delegate this type of job to the network
transport.

I am happy about the discussion of this thread because it points out a
bigger issue: we need a better network transport that understands the
applications.

The situation is terrible as how much browsers need to work-around or
manage to reduce network latency: number of connections, per-opening
connections, prefer connections that have sent more data, disable
slow-start-after-idle, open two connections at the same time and use
the one that comes back first, blah blah blah. each has its merit but
together sometimes they do very bad/stupid things (e.g., opening too
many connections and hoses itself on slow networks).

I feel httpbis and tsvarea should start looking into this problem
together. The browser has good knowledge about the priorities of the
resources, HTTP/2 helps speeding up things talking to the same
host/domain, and the network/transport knows the packet delays and
bandwidth well. Together there should be a better solution. It can not
be done by any single layer/protocol.

>
> -Patrick
>