Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!im4u!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!ihm
From: ihm@nrcvax.UUCP (Ian H. Merritt)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP performance limitations
Message-ID: <1215@nrcvax.UUCP>
Date: Wed, 7-Oct-87 12:58:04 EDT
Article-I.D.: nrcvax.1215
Posted: Wed Oct  7 12:58:04 1987
Date-Received: Sun, 11-Oct-87 10:10:38 EDT
References: <8710030356.AA29135@ucbvax.Berkeley.EDU>
Reply-To: ihm@minnie.UUCP (Ian Merritt)
Organization: The Frobboz Magic Packet Co., Inc.
Lines: 53

>The instruction count sounds low to me, how about 10 times more?

This sounds more reasonable.

>
>(A 1000 byte packet sounds like it would take 500 adds just to
>compute the TCP checksum, not to mention a 64K packet).

Since the 1's complement arithmetic is so flexible, this could of
course be improved on 32 bit processors, for example, but still
represents significantly more than 1000 instructions...
	.
	.
	.

>Unfortunately for a TCP connection, most of the checksum overhead
>is in the TCP checksum (which is an end-to-end check) and this
>sounds harder to move off of the general purpose CPU.  The idea
>would be to let your general purpose 14 MIP[S] CPU do general
>purpose work rather than adding up checksums.
>
	.
	.
	.

>I have been thinking of how to design a T3 (45Mb) type speed
>packet switch (just thinking) and there are some real problems
>with doing IP packet header processing when you need to process a
>packet every 6 us.  (Voice packets want to be about 100 bytes so
>you need to be able to handle about 56K packets/sec).
>
>Virtual circuts sure seem easer at the packet level at this speed
>(smaller packet overhead too).  Of course, a virtual circut could
>carry embedded IP packets.

This suggests a dedicated packet concentrator arrangement such that
long-haul very high speed (VHS (:->) ) circuits could be utilized by
grouping large numbers of small (i.e. ip/tcp-size) packets bound for
the same region together into mostly-reliable megapackets shipped over
the high-speed link to be unpacked and sent off to gateways at the
far end.

TCP's reliability features would be sufficient to permit this to work
with little or no megapacket-level error handling, but such
functionality could be included by using nonflexible (therefore
simple) algorithms implemented in VLSI that operate on the entire
megapacket or by cutting it up into arbitrary segments without any
content-specific knowledge.  The common-channel interoffice signalling
(CCIS) protocol used by the bell system incorporated a similar scheme
(albeit on a smaller (and slower) scale), allowing selective
retransmission of portions of a megapacket while verifying the
validity of the rest of the data.
					--i