Re: TCP performance limitations

3 Oct 1987 06:36-EDT

As you move upward in the bandwidth range, you have decreasing amounts of
time to process each object passing through - the high speed switching fabrics
developed at Bell Labs and Bell Core have the characteristic that very little
per packet processing is being done and, as you surmise, a kind of virtual
circuit is set up; however, the switching fabric is able to share the
bandwidth of the transmission resources, despite the VC set-up, because
the VCs are just table entries and not reservations of actual capacity
within each trunk.

At the terminations of such a switching fabric, however, I think one
still will need some end/end checking. Moreover, if we contemplate
the kind of linking of networks we have today (vastly different internal
operation), we may still need the end/end checking that TCP does. Rather
than putting the TCP in the mainframe, anymore, though, it is fair to
consider the sort of DMA interface which permits the TCP and perhaps
other layers of protocol to be housed on an external board, equipped with
special purpose logic or at least dedicated processing, placing data or
taking data from the main processor's memory. Communications becomes a
matter of placing buffers in memory and possibly signalling their arrival
to the communications processor.

I suspect that this description is not far away from the kinds of
equipment already made and sold by companies like EXCELAN and ACC.
Forgive me if I failed to mention the dozens of other companies whose
products may work this way - I'm not up to speed on all the commercial
products now flowering in the TCP/IP fields.

At an IP switch point, you are still faced with at least full IP
level processing and handling 45 Mb/s and up at that point is
still a big processing load, unless we re-think the IP level and
try to find a way to fabricize it, as the Bell folks have with
the lower level packet switching. Hmm.


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