Cell Relay Archive

[manfredi@arl.bna.boeing.com]

Pablo seems to have received the reply before I did, and he responded
accurately (in my opinion).

I just wanted to add something to a couple of his replies.

In article <5csoik$gok@dismay.ucs.indiana.edu>,
  Marrone Pablo <marronep@telefonica.com.ar> wrote:
> 
> murray@pa.dec.com stated
> 
> >Time for an alternate opinion.
> 
> >UBR is Unspecified Bit Rate.  The system doesn't promise anything.
> >This is frequently called Useless Bit Rate.

UBR is no more useless than Ethernet's bandwidth. Both give you whatever
happens to be available. If nothing is, both can end up throwing packets
away.

> >Calling Ethernet "best effort" in this context is misleading.  A congested
> >ATM switch will silently drop (UBR) cells.  When an Ethernet packet
> >encounters a collision, the transmitting host knows immediately and
> >can schedule a retransmission (after backoff).  The result from a
> >users viewpoint is that Ethernet packets generally get through but
> >the timing is hard to predict as compared to ATM packets that just
> >don't get delivered.
> >
> >ABR acts like Ethernet - the packet will (normally) get delivered, but
> >you don't know how long it will take.
> 
> ABR will also drop cells "silently"  in case congestion occurs, but CLR
> value
> is assured. CD and CDV are not controlled in ABR traffic.

Ethernet might "(normally)" manage to get packets across, but then so would
UBR. It's simply a case of buffering cells in the UBR instance. Sure, those
cell buffers will eventually overflow if congestion occurs, and similarly
if an Ethernet is busy enough the retries will expire and the packet will
be discarded.

ABR provides QoS guarantees. Ethernet provides none at all.

Bert
manfredi@arl.bna.boeing.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet