On Mon, Apr 15, 2013 at 4:03 PM, Eggert, Lars <lars@netapp.com> wrote:
> Hi,
>
> On Apr 15, 2013, at 15:56, Roberto Peon <grmocg@gmail.com> 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