Re: [aqm] TCP ACK Suppression

[Joe Touch <[e-mail]>]

On 10/9/2015 10:04 AM, Yuchung Cheng wrote:
>     That definitely contradicts the TCP specs. So it is very much in
>     "don't go there" territory...
> 
> By 'not going there' you are crippling people's networks for the sake of
> following a spec. Rather than following the letter of the old spec, we
> should be looking at the reasons for it, and reasons to make exceptions.
> There is a long history of introducing new things that break the old way
> of doing things, from breaking "classful" network routing to Anycast,
> there are lots of things that "broke" the old way of doing things.

There's a useful less on here:

Van Jacobson, in an unpublished appendix to his Sigcomm 1988 paper on
congestion control, discussed how TCP should restart after idle, and
that this would require a "time since last sent" timer. A footnote to
that text noted that there was already a "time since last received"
timer, and that - 'since TCP traffic is typically symmetric', it would
be reasonable to use that timer for slow-start restart after idle.

A few years later, when developing HTTP, Tim Berners-Lee said that he
didn't want to use FTP for file transfers because it would open two
connections for one file from one location (one for control, one for the
file). He said that was heavyweight, and that (paraphrasing), 'most of
the time, we'll only get one file from a location'. So we ended up with TCP.

When the web became more sophisticated, users wanted many files from one
server for each page visited (images, formatting, etc.). What we ended
up with was burst after idle for HTTP traffic.

I.e., there are a lot of things there for a reason. Yes, nothing is
immutable, but simply claiming "I need it now" and "nobody has
complained" isn't considered a reasonable way to deploy changes in the wild.

Joe