Subject: Steven's TCP/IP V1 and Host Requirements
To: VaX#n8 <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/09/1996 20:03:27
Warning: strong opinions follow!
>Has anyone methodically gone through Steven's V1 book and checked to see if
>the problems with BSD networking (specifically, the bsdi machine) have been
>fixed? Also, to work on unconditional compliance with the Host Requirements
>doc, if not already met.
*I* certainly haven't, but then I don 't find Rich Steven's TCP/IP
books useful. I'd rather check the items in section 2 of rfc1127
*first*, and then thnk about the rest of rfc1122 and 1123.
>Off the top of my head I remember something about invalidating entries
>from the ARP cache (even if they are being used as a destination addr)
>after a timeout (10min?) to catch hosts which change hardware addresses.
Yup, ARP is a high point on the list.
I think flushing *does* happen, I've certainly seen cloned entries
time out. It's a little hard to drop them if other route entries
(eg., an ARP entry for a next--hop gateway for some other route) are
Anyone working on this should also be aware that the state-of-the-art
in ARP cache managment has changed since Stevens' book and the HR
RFCs. The mobile-IP field has invented ``gratutious ARP'' (and
related concepts) for flushing out stale ARP entries when a host
decidesto change its MAC-to-IP address mapping. If you want to clean
up ARP for the 1990s instead of the 1980s, work on that instead.
>I'm a little disappointed trailer encapsulation was dropped;
I think the accepted wisdom is that you should be *grateful* :).
> it seemed
>like a nifty idea, but it must not be that big of a perf increase anymore
>since nobody seems to use it now :)
Yup. Trailers made sense only for machines with relatively fast
scatter/gather I/O, relatively slow CPUs, and painfully slow memory
systems (e.g., one-word write buffer, or no cache at *all*), where it
makes a lot of sense to avoid copying a three-page packet by doing
pageflipping into user space. The afficionados should be able to
guess which model of VAX this makes most sense on; for anything with
larger pagesizes than a VAX, it's a lose. And on, say, a KA630, a
leaner, meaner TCP stack plus a DELQUA turbo-mode driver make more sense
in any case.
However, NetBSD does support Unibus Vaxes; if Ragge wants to (re)implement
trailers and finds it's a significant win, I'd consider voting to let
trailers back in.