Subject: Re: IEEE802.1 Looking for Guidance - Cells in Frames

From: [email-masked] (Richard Cogger)
Date: Thu, 21 Jul 1994 17:03:37 -0500

Sorry to be so late joining this thread.  I've been promoting an idea to
several vendors and associates who have encouraged me to write it up.
Although not precisely responsive to the issues here, it seems it may be
relevant.  Anyway, here it is:

Why not run ATM cells in Ethernet frames?

Background:  At Cornell, we have over 8000 ports of 10BASE-T ethernet
installed, going to 10,000 by the end of another year.  We want to get ATM
to all of those desktops as soon as possible.

Solutions being offered or proposed by various vendors promise 25Mbps or
51Mbps or more, but the most optimistic pricing I've heard, projecting for
a year or two in the future is about $3-400/port on a mux plus $2-300 for
the workstation adapter.  Well, that means $5-700 per desktop or
$5-7,000,000 for our 10,000 desktops.  No way will we be able to afford
that much.  Also, some of those destop systems have built-in ethernet and
no slot for a new ATM adapter.

So, my proposal to prospective vendors is: build a 24-port mux (10BASE-T
ports) with a 155Mbps ATM port to connect via fiber to a switch. Price it
so that the volume discounted cost for us is $100/port, and we will buy
approximately 10,000 ports.  I think there are probably many campuses with
similar needs.

Here is how it should work:

1.  The mux needs to be as simple as possible to make the cost target.  So
it should do as little as possible.

2.  Rule 1. -- Only one node (workstation) on a port, so it is a point to
point link.   No contention, no collisions, etc.

3.  AAL is done in software at the workstation (a new driver); SAR is
distributed between the workstation and the mux (see below).

4.  The UNI is available via appropriate API to Native-mode ATM
applications.  IP etc. run over ATM in *exactly* the same way they do with
the 25Mbps etc. desktop solutions.  The same native atm applications run,
although not as fast, of course with only half-duplex 10Mbps available.
Performance will be cpu-limited also for some workstations, but remember it
is only 10Mbps.

5.  A minimum size ethernet frame is 64 bytes with a 46 byte payload which
means that the minimum frame for a cell would be 66 bytes, unless some
games were played such as use the type bytes for payload.

6.  How about the cell header?  Implement the mux as a promiscuous
listener.  For frames sent toward the mux, put the cell header in the
ethernet destination address.  Perhaps the mux can calculate the HEC to
offload the workstation a little.  For frames sent by the mux toward the
workstation, the cell header goes in the source address.

7.  Rule 2. --  More than one cell payload can go in a frame, but they must
all be for the same VC; hence they all have the same cell header; hence the
cell header only needs to be supplied once, as above.  There is no overhead
on the wire for sending data as cells.  There is very little compute
overhead for the workstation to perform the SAR.

8.  For workstation originated data, the workstation can trade off
efficiency versus latency by choice of how many cells to put in a frame.

9.  For data coming in from the ATM switch and being sent on the ethernet
link in frames by the mux, there will (possibly) need to be some signaling
at VC setup to set parameters for how the mux frames the cells.  The mux,
receiving a cell from the high-speed link can dally to see if another for
the same VC arrives "soon enough" to be packaged in the same frame.  There
can be a max number of cells before sending the frame.

10.  VC's connecting ports on the same mux could have cells (frames?)
switched internally in the mux or they could simply be sent as usual on the
high-speed link so the switch at the other end can send them back.
Probably it's more important to keep the cost of the mux down by keeping it
simple than it is to economize on bandwidth used on the link to the switch.

Other comments:

This proposal is an alternative to ethernet frame switching, which seems
costly, and to several other forms of "preserving investment in the
installed base."  We've spent the last 5 years getting those 10,000 folks
hooked up, learning to operate it, manage it, etc.  The next step needs to
be directly to ATM to the desktop for everyone.

Whether to use such an infrastructure to do LAN emulation, or (my favorite)
router emulation for existing applications can be debated in exactly the
same terms as for the 25Mbps, 51Mbps, etc. solutions.

What about performance?  For someone converting from a shared ethernet,
they should see a 10 or 20 fold improvement, depending on many things.
They should also benefit greatly from being able to get QoS facilities,
especially for low bandwidth services such as voice.  It should be possible
to transmit middle-resolution MPEG at 6 Mbps, unless the workstation is a
lower-end PC.  Anyway, the point is to get early, massive deployment,
affordably.  I assume we would also be using the 25Mbps or 51Mbps solutions
for those able to afford more $.  In effect, being able to show folks the
benefits of ATM to the desktop may help to sell them on the need for
greater speed.

---

From: [email-masked] (Curtis Villamizar)
Date: Fri, 22 Jul 94 17:05:59 +0000

> to all of those desktops as soon as possible.

I think ATM for the sake of ATM should not be a goal.  You are setting
yourself up to waste a lot of money with little or no benefit over
alternatives.

If a goal is to continue to provide high quality data access, then
stick with routed IP of 10baseT at $0 incremental cost.  ATM will not
buy you anything here and will actually worsen your IP performance.
The existing TCP congestion control is a much better means of
utilizing available bandwidth than resource reservation could ever be
and is superior to anything I've seen proposed for ATM traffic
management of ABR service.

If real time applications such as voice are a concern, track the
progress in RSVP and deploy RSVP capable software in routers and hosts
as it becomes available and where reservations for real time traffic
are needed.  This again may be a $0 cost solution if software can be
upgraded at no cost.

Then and only then, if certain hubs are a congestion point, dealing
with that problem can be much cheaper than trying to do funny ATM over
ethernet things.  A combined router/hub which can treat each 10baseT
segment as an individual subnet might be a better solution.  You can
then have 51 or 155 mb/s into the router/hub using IP over ATM and
dozens of 10 mb/s segments (totaling way over 155 mb/s).  RSVP can
nail up bandwidth for the apps that need it and TCP can do it's usual
good job of high utilization and equitable sharing of the remaining
bandwidth including bandwidth that real time apps thought they needed
but never really used (often 80-90% of what they allocated if
compression is applied, since compressed audio and video are both
highly bursty).

Current ATM products try to replace your hub and group them into
logical LAN Emulation bridged subnetworks.  A router somewhere in the
picture can be used to talk directly to the LAN emulation protocol and
establish a very large number of bridging relationships (essentially
one on one) to accomplish the same thing described above.  If RSVP is
implemented, a router understanding both RSVP and the LAN Emulation
protocol will be able manage bandwidth by adjusting LAN Emulation VC
reservations queueing real time IP frames ahead of elastic traffic
(TCP).  This LAN Emulation based solution seems to be the immediate
direction of things for hub replacements - though many pieces are
still in the works (the least of which may be RSVP).

Strict bandwidth reservation is a loser, especially if bandwidth is
not practically infinite, as would be the case with ATM over 10baseT.
Doing things over native ATM loses you internetworking capability as
well.  If ATM is not ubiquitous for a long time, going native ATM will
severely limit your connectivity.

Curtis