Re: Melting the Internet?

Sean Foderaro (jkf@frisky.Franz.COM)
Tue, 09 May 95 05:17:40 -0700


> OK. Tim and I spent some time talking about this. Probably the real issue
> is that the API to tcp doesn't give any info about what's happening on the
> connection (network level virtual circuit). With real-time stuff, the
> sender needs to delay capturing a frame (e.g.) until bw exists to send it
> end-to-end with minimal delay.

Two ways to tell if a TCP pipe is so full that a write() to it
would cause to process to block are:
1. put the file descriptor in non-blocking mode so that the
write returns with an error code of EWOULDBLOCK
2. use select() to test if a write to the file descriptor is
is possible. With select() you can have it answer right away
or you can tell it to wait N milliseconds for the pipe to empty
before giving up.

Also there is support for having signals delivered when input or
output is possible on a file descriptor (I've never used this
or output myself but I suspect it is possible).

As a test of this I modified my test code to try option 2. Before
I wrote each TCP packet I did a select (with a 0 second timeout) to
see if I could write to the socket. If I couldn't then I
incremented a counter and tested again. I ran this
test on two scenarios and the results are below, in the last row
in each table. It demonstrates that a machine is able to sense
a full pipe.

Here we have a local ethernet and the pipe never fills up:

Machine A ------------- Machine B
50mhz sun 10mbps 16mhz sun

UDP TCP
packets loss 6668 (67%) 0
time to receive 5 5
avg packet delay 0 0
max packet delay 1 1
net transmission rate 666 2000
error adj rate 444 2000
real time performance great great
write_delays - 0

Here we have a fast to slow net situation where the pipe fills
up quickly:

Machine A ------ 5 hops --- Netblazer --------- 1 hop------- Machine B
sparc II 10-?? mbps 38kbps 10mbps 16mhz sun

In this scenario we go from a site at UC Berkeley, out onto the
internet and then into my machine though a Netblazer run by UUnet.

UDP TCP
packets lost 9602 (96%) 0
time to receive 20 497
avg packet delay 8 0
max packet delay 15 8
net transmission rate 20 20
error adj rate 0.8 20
real time performance bad good
write_delays - 4721419