From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Flow Control
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 13 Nov 1992 07:06:16 GMT

myoung@force.ssd.lmsc.lockheed.com writes:
+---------------
| The near term flow control problem can be limited to solving the 
| bursty data problem in the local area environment where we need to 
| duplicate the current services offered by FDDI and switched ethernet.  
| 
| Currently there is no mechanism, short of using routers, which
| allows bursty traffic across wide area networks.  So in the WAN case
| the net can require circuit building procedures with implied bandwidth
| reservation and rate based data release, or require the use of embedded 
| routers.
| 
| [Rob] suggested a "backpressure" (did Tyment invent this term?) method
| [the RBCE bit] which can be used in a local multi-hop environment.
+---------------

I'm sorry. I guess I never said it explicitly: I was *not* proposing a
global fan-out of the RBCE bit for WANs (though it may have sounded like
that, I guess). I was attempting to address the fact that a lot of people
are expecting ATM in the LAN to give the same kind of performance a
traditional [e.g., old pre-LAN ARPAnet] packet-switch network [that is,
hosts have point-to-point links to "brouters"] would give on the same
speed links. And that without low-level flow control, that's just not
going to happen.

+---------------
| [Rob]'s method has not solved the WAN feedback issue, namely that the
| host may have released the entire burst load before receiving the RBCE 
| bit.  However in a local environment when links are short and hops few, 
| the feedback delay is small enough to that the RBCE should migrate back
+---------------

Aha! I see I need another small clarification: It is *not* necessary that
the RBCE flow all the way back to the source of the burst before the burst
ends. It is only necessary it flow back to the previous output port in the
path before the buffer overflows. And that requires only that each output port
have a burst buffer big enough to hold a next-device-back's "backpressure
response time"'s worth of cells (for each input port in the switch).

That is, with an N-port switch, a maximum link speed of "R" cells/second, a
maximum single link round-trip transit time of "RTT" seconds, and a maximum
backpressure ("XOFF") response time in the previous output port(s) of "B"
seconds, the required burst buffer per output port is N * R * (RTT + B) cells.

These are all quantities that are dependent *only* on the "immediate neighbor-
hood" of the switch -- its directly connected links and the switches/hosts on
the ends of those links. [Note that usually you'll want about twice that much
buffering, so you can apply some reasonable high-water/low-water hysteresis
on the backpressure without putting "bubbles" in the flow.]

Numerical example for a WAN tandem switch: N = 64, R = 1.5 Mcell/s (622 Mb/s),
RTT = 5ms (100 miles?), B = 5us ==>  N * R * (RTT + B) = 480 Kcells = 25 MB.

Numerical example for a fast LAN hub: N = 256, R = 1.5 Mcell/s (622 Mb/s),
RTT = 5us (1km of fiber/link), B = 5us ==>  N * R * (RTT + B) = 3840 cells =
204 KB/port.

Now if you apply that picture recursively out from any switch, you'll see
that, provided the buffer sizes meet the above criterion, the method *does*
"work" in as large a WAN as you might wish to build, in the sense that it
will not drop cells due to congestion. However, don't get me wrong: In the
worst case the entire net can "block" waiting for some single slow link to
pass a few cells, so in that sense it's *not* a "solution" to the WAN.

[In the LAN case, where most of the workstations/hosts will have access links
on the same order of speed as the switch-switch tandem links, such "blocking"
events are no worse than a bus-style LAN with the same speed. And since the
traffic is bursty, most of the time things are a lot better than that.]

+---------------
| The method could be applied independently in local regions so that a RBCE  
| does not back down a wide area link into another local region which didn't 
| causing the original problem.
+---------------

But if you do that, then you *will* drop data at the point that you fail
to propagate the backpressure. However, provided that one also still has
end-to-end congestion avoidance operating, this is not necessarily a bad
thing.

+---------------
|   * Accept a hop by hop feedback mechanism for the local environment,
|     dis-allowing its usage across multiple domains. Thus duplicating  
|     existing  LAN service.
| 
|   * Use embedded routers to duplicate existing service over WANs.
+---------------

Yes, or have WAN connections use the same sorts of dynamic adjustment of
their bandwidth reservations as IP over X.25 or IP over multiple-BRIs
does. This will require true large-buffered "routers" only at the LAN/WAN
interfaces.

+---------------
|   * Newer services such as voice or video applications, distributed 
|     database, transaction routing, high speed channel to channel transfer
|     must use the new bandwidth reservation mechanisms and call set up.
+---------------

"Must" is too strong; "newer services" is too weak. Both traditional packet
switching applications and multimedia services might use *either* the constant
bit rate or the bursty option, whichever fits the particular service better.
After all, it was *years* ago that people demonstrated successful carrying
of multiple voice connections over Ethernet, not to mention the recent
multicasting over the Internet of live audio from the IETF meetings...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay