What's wrong with Berkeley Unix
University of California at Berkeley has been funded by DARPA to modify the Unix system in a number of ways. Included in these modifications is support for the Internet protocols. In earlier versions (e.g. BSD 4.2) there was good support for the basic Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform nicely on IP ethernets and smaller Internets. There were deficiencies, however, when it was connected to complicated networks. Most of these problems have been resolved under the newest release (BSD 4.3). Since it is the springboard from which many vendors have launched Unix implementations (either by porting the existing code or by using it as a model), many implementations (e.g. Ultrix) are still based on BSD 4.2. Therefore, many implementations still exist with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles through vendors as new release, many of the problems will be resolved. Following is a list of some problem scenarios and their handling under each of these releases.
- ICMP redirects
-
Under the Internet model, all a system needs to know to
get anywhere in the Internet is its own address, the
address of where it wants to go, and how to reach a
gateway which knows about the Internet. It doesn't
have to be the best gateway. If the system is on a
network with multiple gateways, and a host sends a
packet for delivery to a gateway which feels another
directly connected gateway is more appropriate, the
gateway sends the sender a message. This message is an
ICMP redirect, which politely says "I'll deliver this
message for you, but you really ought to use that gateway
over there to reach this host". BSD 4.2 ignores
these messages. This creates more stress on the gateways
and the local network, since for every packet
sent, the gateway sends a packet to the originator.
BSD 4.3 uses the redirect to update its routing tables,
will use the route until it times out, then revert to
the use of the route it thinks is should use. The
whole process then repeats, but it is far better than
one per packet.
- Trailers
-
An application (like FTP) sends a string of octets to
TCP which breaks it into chunks, and adds a TCP header.
TCP then sends blocks of data to IP which adds its own
headers and ships the packets over the network. All
this prepending of the data with headers causes memory
moves in both the sending and the receiving machines.
Someone got the bright idea that if packets were long
and they stuck the headers on the end (they became
trailers), the receiving machine could put the packet
on the beginning of a page boundary and if the trailer
was OK merely delete it and transfer control of the
page with no memory moves involved. The problem is
that trailers were never standardized and most gateways
don't know to look for the routing information at the
end of the block. When trailers are used, the machine
typically works fine on the local network (no gateways
involved) and for short blocks through gateways (on
which trailers aren't used). So TELNET and FTP's of
very short files work just fine and FTP's of long files
seem to hang. On BSD 4.2 trailers are a boot option
and one should make sure they are off when using the
Internet. BSD 4.3 negotiates trailers, so it uses them
on its local net and doesn't use them when going across
the network.
- Retransmissions
-
TCP fires off blocks to its partner at the far end of
the connection. If it doesn't receive an acknowledgement
in a reasonable amount of time it retransmits the
blocks. The determination of what is reasonable is
done by TCP's retransmission algorithm. There is no
correct algorithm but some are better than others,
where better is measured by the number of retransmissions
done unnecessarily. BSD 4.2 had a retransmission
algorithm which retransmitted quickly and often. This
is exactly what you would want if you had a bunch of
machines on an ethernet (a low delay network of large
bandwidth). If you have a network of relatively longer
delay and scarce bandwidth (e.g. 56kb lines), it tends
to retransmit too aggressively. Therefore, it makes
the networks and gateways pass more traffic than is
really necessary for a given conversation. Retransmission
algorithms do adapt to the delay of the network
after a few packets, but 4.2's adapts slowly in delay
situations. BSD 4.3 does a lot better and tries to do
the best for both worlds. It fires off a few
retransmissions really quickly assuming it is on a low
delay network, and then backs off very quickly. It
also allows the delay to be about 4 minutes before it
gives up and declares the connection broken.
