[John Robinson <jr@LF-SERVER-2.BBN.COM>: Re: TCP performanc...]

10 Oct 1987 12:40-EDT

I found this note of considerable interest; fast packet switching (FPS)
is become an important focus of attention in several places - Bell Labs,
Bellcore, Univ Washington, and elsewhere. I believe it has the potential
to become the principal switching technology of the 90's and at the speeds
shwon in the laboratory (aggregate switching rates in the tens of gigabits
per second) could handle voice, data and possibly video (especially if

Vint Cerf

Begin forwarded message
Received: from LF-SERVER-2.BBN.COM by A.ISI.EDU with TCP; Tue 6 Oct 87 17:13:19-EDT
Date: Tue, 06 Oct 87 16:31:43 -0400
From: John Robinson <jr@LF-SERVER-2.BBN.COM>
Reply-To: jr@BBN.COM
Subject: Re: TCP performance limitations
Return-Path: <jr@LF-SERVER-2.BBN.COM>

It is interesting that the Bell&al switching fabrics are, at a lower
level, hardware packet switches. This comparison was in fact the seed
of the Butterfly idea in Crowther's head. Reduce the routing decision
to something simple enough, and then speed the whole thing up by doing
it in hardware (1976). I was intrigued when Luderer's (Bell Labs)
presentation on fast packet switching at ISS87 last March alluded to
the Butterfly as a commercial realization of FPS technology to build a
multiprocessor. Computing and communications are tending to merger
here, as has often been said at other levels. Conservative
projections of Buterfly technology we have done make 45mbs trunks and
FDDI LANs look entirely feasible for next-generation IP switching.

The phone application of packet switching isn't concerned about
end-end integrity too much, but they naively assume that plentiful
bandwidth and high speeds together mean that error detection and
recovery and, more importantly, resource management, won't ever be
necessary. I think the current difficulties the Arpanet is having
under heavy load are a consequence of a similar attitude in the early
Arpanet days. When peak utilizations are 20%, you don't have to try
very hard to control resource utilizations. So the only question is,
will the supply of phone trunking bandwidth keep enough ahead of
demand come FPS. Right now, I'd guess it will for at least long
enough for FPS to get accepted, due to rapid deployment of fiber and
deregulation. This depends on possible shakeouts in the IECs, I
suppose. This doesn't apply to the non-US world.

As for silicon doing IP or CLNS, I'd expect that this is entirely
within reason already. I would probably opt for a more powerful
header checksum, in fact, but this choice may already be moot. Too
bad that CRC is so easy in hardware and hard (compared to simple sum)
in software. Since only the header is checksummed, however, the check
can overlap reception of the user data and need not add any processing
delay at all.

I am not calibrated on what tcp-ip considers worth airing; please
redistribute this note if you find it interesting enough.

jr@bbn.com or or jr@bbn.uucp

End forwarded message

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:35 GMT