Re: IW10 Considered Harmful

Some of the points raised in that draft are quite compelling, but they
lead me to a different conclusion than "IW10 Considered Harmful."

Section 2 describes the existence of home Internet connections where
the lack of an effective QoS mechanism can enable one high-throughput
application to cause substantial queuing delays for other, more
latency-sensitive applications sharing the same link.  So far, so
good.

Table 1 in Section 2 attempts to quantify the assertion that a bigger
initial congestion window for application A will materially increase
latency for some other application B that's using the same link.  The
table presents large, scary numbers to demonstrate just how much of
application A's data might be queued up in front of poor application
B's time-sensitive packet: 450,000 bytes in the example of a 10-packet
initial congestion window for each of 30 connections used by
application A.

While the arithmetic is correct, my interpretation of that table is
very different.  The table uses the example of a 50Mbps network link.
Let's assume that there's a 100ms round trip time between application
A and the server with which it's communicating.  The bandwidth-delay
product is 625,000 bytes.  If application A uses a single, long-lived
TCP connection to talk to the server, the congestion window eventually
will grow large enough to accommodate 625,000 bytes (if window scaling
is enabled, and if congestion between A and that server does not
prevent the window from growing large enough).  Thus the large, scary
numbers in Table 1 are smaller than the latency that application B
already must be prepared to experience once application A is in a
steady state.

Section 3 recommends HTTP pipelining and SPDY.  I'm a proponent of
both, but they won't solve the latency problem for application B.
Fundamentally, in the configuration described in the "IW10 Considered
Harmful" draft, where you have a single queue of nontrivial depth
shared by applications A and B, the only way to guarantee application
B a latency less than application A's RTT is to artificially throttle
application A so that the total of the window sizes across all its
connections is less than its bandwidth-delay product.  HTTP as
deployed today is artificially self-throttling due to the inefficiency
of sending small messages in synchronized lock-step over a
high-throughput, high-RTT connection.  One can reduce the inefficiency
with pipelining or SPDY, but because of the single queue, application
B *depends* on application A being inefficient in its use of the
available bandwidth.

The real fix, I think, is to address the single-queue problem: make
the queue shorter or add a QoS mechanism.

-Brian

On Fri, Aug 26, 2011 at 12:25 PM, Jim Gettys <jg@freedesktop.org> wrote:
> I just submitted draft-gettys-iw10-considered-harmful-00
>
> http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt
>
> It is commenting on the proposal in
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
> which would change the TCP initial window from 4 packets to 10.
>
> I believe this would be a serious mistake compounding problems already
> present
> for low latency applications, for the reasons outlined in my draft.
>                     Best regards,
>                                 Jim Gettys
>
>
>
>                         Abstract
>
> The proposed change to the initial window to 10 indraft-ietf-tcpm-
> initcwnd must be considered deeply harmful; not because it is the
> proposed change is evil taken in isolation, but that other changes in
> web browsers and web sites that have occurred over the last decade,
> it makes the problem of transient congestion at a user's broadband
> connection two and a half times worse. This result has been hidden
> by the already widespread bufferbloat present in broadband
> connections. Packet loss in isolation is no longer a useful metric
> of a path's quality. The very drive to improve latency of web page
> rendering is already destroying other low latency applications, such
> as VOIP and gaming, and will prevent reliable rich web real time web
> applications such as those contemplated by the IETF rtcweb working
> group.

Received on Friday, 26 August 2011 22:27:36 UTC