Re: HTTP/2 and TCP CWND

[Roberto Peon <[e-mail]>]

On Mon, Apr 15, 2013 at 4:03 PM, Eggert, Lars <[e-mail]> wrote:

> Hi,
>
> On Apr 15, 2013, at 15:56, Roberto Peon <[e-mail]> wrote:
> > The interesting thing about the client mucking with this data is that, so
> > long as the server's TCP implementation is smart enough not to kill
> itself
> > (and some simple limits accomplish that), the only on the client harms is
> > itself...
>
> I fail to see how you'd be able to achieve this. If the server uses a CWND
> that is too large, it will inject a burst of packets into the network that
> will overflow a queue somewhere. Unless you use WFQ or something similar on
> all bottleneck queues (not generally possible), that burst will likely
> cause packet loss to other flows, and will therefore impact them.
>

The most obvious way is that the server doesn't use a CWND which is larger
than the largest currently active window to a similar RTT. The other
obvious way is to limit it to something like 32, which is about what we'd
see with the opening of a mere 3 regular HTTP connections! This at least
makes the one connection competitive with the circumventions that HTTP/1.X
currently exhibits.


> TCP is a distributed resource sharing algorithm to allocate capacity
> throughout a network. Although the rates for all flows are computed in
> isolation, the effect of that computation is not limited to the flow in
> question, because all flows share the same queues.
>

Yes, that is what I've been arguing w.r.t. the many connections that the
application-layer currently opens :)
It becomes a question of which dragon is actually most dangerous.

-=R


>
> Lars