> this paragraph. Before ripping apart TCP, you should say something like
> it has held up very well, is well designed, etc. but changes in Internet
> traffic characteristics have introduced a number of inefficiencies.
This is a really good point. We're fond of ripping on TCP in private, but
we need to be more diplomatic here in our first chance to go on the record
in public.
> Paragraph 3: I would not reference Stevens94 (strange to reference a
> book, plus you go through the major characteristics in the following
> bullets).
I would put in a vote for keeping this reference. It's a great book, and
if i were somebody new in the field trying to understand TCP, i would want
to be pointed here. It's a pain to piece together how TCP works from the
papers, and impossible from the RFCs, because it evolved in such an
erratic, ad hoc fashion over many years. We won't look too odd citing
it; quite a few papers do.
> One question that is likely to occur to readers as they read this
> section is how HTTP 1.1 will interact/does interact with the arguments
> you are making. A lot of the problems you mention seem to arise
> directly from "short flows", but this will become less of a problem once
> 1.1 is widely deployed. Now, I know that all the techniques are still
> valid, but it seems like you should pre-emptively mention issues with
> HTTP 1.1 before you get the question from readers.
This is a great point. Flows will definitely get longer; they already are,
with HTTP1.0 persistent connections (Keepalive). On a picture-heavy news
web page there can be about 200KB of crud these days, spread over 4
keepalive connections (which becomes 1 or 2 connections with HTTP1.1, i
guess. It may be worth pointing out that:
o you're ramping up in slow start (and thus not fully utilizing your pipe)
at least until you've sent 3*Bandwidth*Delay bytes of data, which is 262KB
for our hypothetical 10Mbps/70ms path.
o even if flows get longer, and start-up transients aren't a problem,
losses are still a huge problem for TCP, as evidenced by the Mathis and
Padhye formulas.
> Section 4.2, paragraph 3: Again, HTTP 1.1 immediately pops to mind as a
> counterpoint to the problems you describe. Is the problem TCP/the
> Internet, or a poor choice of protocols on top of TCP?
This is a good point. What we have been seeing is a poor design where a
single HTTP transaction opens a bazillion connections, each of which is
clueless. But even assuming that keepalive and HTTp1.1 fixes this, we
still have a a bazillion presistent HTTP connections, each to a different
user, and each connection clueless when it starts up. This problem could
be solved to some extent by sharing info within a TCP implementation, like
Venkat's stuff. Or you could try to solve it to some - hopefully further -
extent by sharing info within an entire site.
Another thing is that we should be careful about saying that the SYN
timeout is "frequently" six seconds. It's six seconds in BSD and ns, but 3
seconds in Win95/NT, Linux, and FreeBSD. So I'd say 3 secs is a more
typical number.
neal