Cell Relay Archive

Cell Relay Retreat>List Archive>month:1998-Apr> msg00296



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: UBR over ATM

  • From: Paul Koning <pkoning@xedia.com>
  • Date: Wed, 29 Apr 1998 09:53:52 -0400

Richard S. Tsumaki wrote:
> 
> Thanks to those who took the time to reply.  I'd summarize the responses
> but so far there's only two posts and one email (provided on request).
> Basically, Paul Koning's post is the most complete, and Ronald H.
> Davis's adds mention of upper layer flow control bugaboos for the last
> question.
> 
> Yikes, good thing I asked.  From the responses, the following
> architecture will work very poorly if at all (please forgive the ASCII
> etch-o'-sketch):
> 
> U1 <-(a)-> F <-(b)-> |ATM switch <-(b)-> F <-(a)-> F <-(b)-> ATM switch
> U2 <-(a)-> F <-(b)-> |                                             .
> U3 <-(a)-> F <-(b)-> |                                             .
> …
> Where Ux= a user PC running LANE client (i.e., UBR SVCs only)
>        F= intermediate cell forwarding device operating at PHY layer
>      (a)= 256 Kbps line
>      (b)= 25.6 Mbps line
> Since congestion occurs at F and there's no intelligence about discard,
> packets flowing through F would almost certainly be lost.  From the rate
> discrepancy at F, buffering alone probably won't be practical.  It looks
> like the only thing to save this architecture's bacon is traffic shaping
> at the ATM switch (if it'll go that low).  Hopefully that'll push
> congestion problems onto the more capable switch instead of F.  Also,
> the same applies to an F between two switches.  Any comments or
> suggestions?

How about "don't do that"?  :-)

Seriously... PHY level muxes with that kind of rate mismatch are
definitely
not a Good Thing.  As you observed, they don't have enough intelligence
to ensure sensible performance.

One possible saving grace is that U1 is adjacent to the mux and has the
low speed line coming into it.  So assuming that it knows the line speed
and specifies that speed (rather than some hardcoded large number) in
its PCR in the SETUP message, and assuming that the far end honors that
PCR by shaping to it (as it's supposed to) you should get cell arrivals
at F from b at the line rate of a (on average).  That should help.

For calls to U1 (rather than from U1) things are more problematic unless
the caller allowed for PCR negotiation.  By the way, there was a comment
that this isn't supported -- yes it is, in UNI 4.0, using the "minimum
traffic parameters" IE.

	paul
-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: pkoning@xedia.com
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859