Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!Cs.Ucl.AC.UK!jon
From: jon@Cs.Ucl.AC.UK (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP Performance Limitations
Message-ID: <8710061310.AA08590@ucbvax.Berkeley.EDU>
Date: Tue, 6-Oct-87 09:13:24 EDT
Article-I.D.: ucbvax.8710061310.AA08590
Posted: Tue Oct  6 09:13:24 1987
Date-Received: Fri, 9-Oct-87 05:25:29 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 25


 Since TCP is a transport protocol, it has to reach the processes
lower protocols can't reach. This means (in most OS's (eg
Used Never In Xanadu)), at least one buffer copy, and one or two context
switches per packet. 

However good your windowing, and lossless the net, that bites 
bad. If the hardware could keep track of the actual user buffers (and scatter
gather them too) straight in and out of user processes, then you are down
to DMA speeds. The trick is to design clever enough hardware that the OS 
designers will trust not to trash the OS. 

You lose two ways because of current hardware - packet over run (see many
writings by Dave Cheriton) causing lowere throughput, and higher latency.

Another win would be hardware that 
provided the higher level protocols with a CRC [Say buffer descriptor
list contains pointer to where to put CRC in outgoing packets, and how to
do it for incoming packets].

It's instructive to look at fast gateways - two lance ethernet chips on a 
multibus can blow away the bus bandwidth - really fast boxes have no bus,
or have a binary tree bus a la buttergates...

Jon