[H-GEN] Network load calcs

Bruce Campbell bc at thehub.com.au
Fri Jun 25 03:06:11 EDT 1999


(Note reply-to: being general at humbug.org.au vs Bruce Campbell <bc at thehub.com.au>)

On Fri, 25 Jun 1999, Ben Carlyle wrote:

> As Mark Suter has pointed out, what I have said so far is only
> absoultely true for protcols that do not require data to travel
> in both directions.  TCP is a classic example of a bi-directional
> protocol with congestion control, which means that deliberately

Which if you've ever sat and watched a ftp ###ing away retrieving a file
from Finland (ssh) and you have another tcp session in the background, you
will notice the session exhibiting variable speed.  This is due to the
backoff mechanism in TCP, which looks like (see, more ASCII art):

|           /|              /|
|          / |    /|       / |
|   /| /| /  |/| / |/|    /  |/|
|  / |/ |/     |/  ~ |/| /     |/|
| /                    |/        |/|
|/_________________________________|/|/|/|______________
                   Time

The congestion control is extemely simple, being that if a limit is
reached (ie, it just hit its head against the top of the pipe), it will
halve the rate of output, and slowly climb back up until it hits its head
again.  If you graphed the rate of all TCP sessions occuring inside a
given pipe, you would see the above graph repeated for each session with
differing congestion (*thunk*) points, thus filling the pipe evenly.

The nice thing about the above algorithm is that a TCP session will expand
to fill a given pipe (and repeatedly hit its head).  The bad thing about
the above is that a TCP session will expand to fill a given pipe, usually
the slowest pipe on the route to the remote destination.

> After a few failures, TCP will start sending (and failing)
> less often.  This will reduce congestion.

If you are interested, try setting up a ppp session over a null-modem
cable running at the highest practical rate on both computers, and notice
the speed of transfers when the machine isn't doing anything, and when you
keep interrupting it (as serial lines are interrupt based, and if you miss
enough, you will change the size of the pipe), and multiple TCP sessions
over the same connection.

You get even weirder effects when you are measuring a TCP session running
a tunnel.

--==--
Bruce.


--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.



More information about the General mailing list