Re: my broken TCP is faster on broken networks

Richard Gooch (rgooch@atnf.csiro.au)
Fri, 11 Sep 1998 23:49:31 +1000


Albert D. Cahalan writes:
>
> jamal writes:
>
> > It is extremely rude to make suggestions on how to break TCPs
> > net-friendliness. I dont see the hack value in it; neither does
> > it prove anything smart on your part. Infact i dont think what you are
> > suggesting will improve anything.
>
> Clearly it _does_ improve his network performance, and there is
> something very wrong with exponential backoff on the Internet.
> Congestion is not a temporary problem that can be fixed in such
> a simple manner. Even if every client does the backoff (hah!)
> there will be plenty of packets to which it does not apply.
>
> Real users do not ever tolerate 2 minute delays. Don't be silly.
> They hit the "Stop" button after 2 _seconds_ and start a new
> connection to avoid the stall. They kill the window and telnet
> again. In general, humans know to kill and restart a slow network
> connection.

Yep. People don't need to understand the guts of TCP to know that they
get an initial burst of transfers and then things can slow down.

> New connections means _more_ network traffic, not less. It sure
> seems that exponential backoff was designed for local 10base2
> with no collision detection. Perhaps a greedy algorithm would
> make more sense on the Internet.
>
> In any case, delays beyond 2 seconds make congestion worse.
> Since real users will restart such connections, it is very bad
> to let the backoff grow so much. Never mind the pure theory.
> We have _humans_ involved, and they don't wait 2 minutes.

I couldn't agree more. Whatever the network theorems, they have to
take account of user behaviour. In the "good old days" much Internet
traffic was batch/bulk transfer (Usenet, email, ftp). With more of the
traffic being http, the actions of humans needs to be considered in
the theorems.

Now, if the routers could tell applications what the maximum bandwidth
currently available on the next hop was, things might be
better. Hmmm. Sounds like ATM. Heresy ;-)

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html