The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199410241935.PAA01635@faline.bellcore.com>, Mark Garrett writes:
> Both Juha and Jon make the point that UBR would be useful
> and still relatively simple if you add something like
> Early Packet Discard, to avoid the cell-loss multiplication
> effect.  I agree.  It would be nice to see some UBR implementations
> like that, and I don't think UBR excludes that sort of thing by
> its definition.
> -Mark


Mark,

I think your ATMF contribution should encourage this at least in the
tutorial and preferably in the final ATMF document.  I'll provide some
detailed comments shortly.  I'd like to see explicit mention of RED,
encouraging vendors to support UBR with RED and preferably UBR with
RED applied on individual queues.  

Given the way ABR is turning out (hop by hop flow control), I hope UBR
is not a dead end.

It would be useful to for switch vendors to allow some minumum
bandwidth to remain unused (ie: reserved for UBR) in addition to
giving UBR what no one else is willing to pay for.  This wouldn't
require extending the definition of UBR or the UBR portion of the UNI,
and could be encouraged in you contribution.  This would be useful for
carriers that would like to provide a useful UBR service rather than a
revenue opportunity and opportunity to bash TCP and IP when unused
their bandwidth approaches zero.  Currently the UBR definition seems
to encourage allocating all the bandwidth you can sell and then giving
any that is unused (possibly zero) to anyone sharing UBR service.

Even more useful would be the ability to specify UBR with a bandwidth
QoS.  This would be used with WFQ and used to modify the weight
assigned to a VC and must be used in conjunction with a minimu
quarentee for UBR.  This *would* require a UNI change in that UBR
currently does not allow a bandwidth.  This would accomodate
requirements for minimum bandwidths of elastic applications but allow
them to remain elastic and use any additional bandwidth available
(sharing the excess in proportion to their minimum bandwidth if WFQ is
used as the means to implement this).  This is a little better aligned
with the int-serv directions than UBR as is (and possibly ABR as is).

Even if allowing a minimum bandwidth on UBR doesn't happen, vendors
could implement VBR, such that traffic that exceeded the VBR traffic
profile (SCR, PCR and burst length) could be treated as UBR,
accomplishing the same thing.  This might be messier to implement than
just a minimum bandwidth on UBR that could be easily mapped to a WFQ
weight.

I suppose hierachical link sharing would be way too much to ask.  This
would involve changing the UNI to allow the (hopefully authenticated)
specification of a queueing class for a VC (ie: being able to say
"this is a vBNS elastic flow, allow it to share the bandwidth
allocation of the vBNS with other vBNS elastic flows").

Curtis