[e2e] TCP design descisions

[Vernon Schryver]

> From: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>

> ...
> i'd be more interested in more hard to find design debates like 
> i) who was involved in the ISO
> OSI Teransport Protocol (e.g. class 4 was quite nice -we did an implementation which
> outperformed tcp:)

You mean you did an implementation of TP4 that outperformed some
particular implementations of TCP on some particular platforms.


> ii) where did XTP end up
> ...

Before Protocol Engines, the "TAB," and the rest of the political (in
many senses of the word) machinery Greg used to build support for XTP,
it was a light and possibly faster protocol.  (A little googling will
give clues about which version of the XTP spec I approved of.)  XTP was
based on the idea of finding what you needed to deal with a packet
(the "context") quickly and in parallel with receiving the body of
the packet.  However, the notion that finding and dealing with control
blocks is so hard that you need hardware support for "contexts" was
never objectively clear. Greg always (even long after XTP was dead
and buried) believed that finding TCP TCBs was significant based more
on prejudice and what he heard from people who weren't familiar with
the code than by looking at the code himself.

The venture capitalists and other supporters were told XTP was needed
because TCP could not run at wire speed over FDDI with contemporary
hardware.  While Protocol Engines Inc and other SGI people were busy
talking about chips in a building at one end of the campus, I perverted
SGI's version of the BSD stack and a fairly slow (even for the day)
extra CPU on a mis-designed FDDI board to fill a fiber in a building
at the other end of the campus.  That half killed XTP.  The coup de gras
was administered by standards committee bloat and dithering that
fatally slowed the development of the chips.  What can you say about
the self-discipline of a group that added a big/little endian bit to
the packet trailer, and where that bit was a significant justification
for having a trailer at all?

That FDDI hardware identical to what I used ran TCP less than half
as fast in other systems with other software and firmware was an
additional object lesson in the foolishness or worse of almost
all talk about speed limits imposed by protocols as opposed to
limits imposed by implementations.

If you don't believe me, ask Van Jacobson.


Vernon Schryver    vjs at rhyolite.com