W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013


From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 15 Apr 2013 17:16:23 -0700
Message-ID: <CAP+FsNd97LUZNRJrf=vCc_tmnxn8ygGZ4EyOfVywt=cuc_qutA@mail.gmail.com>
To: "Eggert, Lars" <lars@netapp.com>
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, Eliot Lear <lear@cisco.com>, Robert Collins <robertc@squid-cache.org>, Jitu Padhye <padhye@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, Dave Thaler <dthaler@microsoft.com>, Martin Thomson <martin.thomson@skype.net>, Martin Stiemerling <martin.stiemerling@neclab.eu>
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.


> Lars
Received on Tuesday, 16 April 2013 00:16:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC