Subject: Re: IP Broadcast

From: [email-masked] (Mark Garrett)
Date: Mon, 24 Oct 1994 10:17:09 -0400

> > I believe ABR will not use for delay sensitive application 
  > > such as topping on RSVP. 
  > > Meaning RSVP will topping on VBR, instead of on ABR. 
	hiroshi

  > i disagree - we will continue to run audio/video on IP on ABRr, just
  > as we do on the mbone today, bevcause on any tariffed ATM net ABR will 
  > be cheaper than VBR - for non- crucial
  > audio/video, we'd be crazxy to do anything different
	 jon

Jon,

This is probably not correct.  ABR has a relatively complex feedback
flow control mechanism, and will be designed for delay-tolerant
applications---i.e. big buffers etc.  One could easily create a
cheaper and simpler VBR service that multiplexed your real-time
applications and did not guarantee the bandwidth access or very low
loss of CBR (at the same time, other instances of VBR would be free to
make those guarantees, at the discression of the switch designer
and/or network provider).  Or you could run on UBR, which will be very
uncontrolled and cheap, and dimensioned as you do IP links now---i.e.
add bandwidth when customers complain.  My favorite occupation these
days is to defend UBR.  The ATM folks think it's so simple that it
will have no market, while many IP folks want nothing more complex
from ATM than FIFO queueing with big buffers (which would be a
satisfactory implementation of UBR.)

So, I wouldn't assume that ABR is the only ATM service appropriate for
running IPng over.  Also, as we get the int-serv service model off the
ground for IPng, we should be asking what could ATM provide us as an
underlying layer.  And it's fair to assume that ATM will be a relatively
ubiquitous sub-network; after all that is it's ambition, and if it
fails to be, it's no loss for IP.  (I think ATM will be quite
widespread, but far from the exclusive sub-net technology.)

See ftp://thumper.bellcore.com/pub/mwg/ATMF.qos.mwg for a copy of the
contribution I made in the ATM Forum which offers definitions and
rationale for the CBR, VBR, UBR service categories.  This text was
accepted into a baseline document--i.e. it's a working text, but not
cast in stone (yet).  The document it affects will be out in April or
so.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 24 Oct 94 14:57:44 +0000

>satisfactory implementation of UBR.)
 
hmmm - can't we have a UBR with RED? then i could run video over IP on
that....

 >widespread, but far from the exclusive sub-net technology.)

yes - agree - the only complexity then is how to do the mapping from
IP6 RSVP flow spec into VBR or other QoS - say that IP is
likely to be specified by  peak bandwidth only while the ATM VBR may 
have lots of parameters, and that the former is in IP packets worth, 
unspecific about size, or burst, while the latter is in cells, specific 
about burst e.g.  via leaky bucket parameters, say, would you care to hazard
a guess as to how to implement one with the other...?

now subsitute an etherm an FDDI, a DQDB net along the way, and make
sure that the concatented service spec mappings across the subnet
technologies work end to end to meet the source (actually sink) RSVP
requirement...

now, do the same, but simply implement the scheduling i nthe IP packet
forwarding layer: what do we lose?

cheers

 jon

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 24 Oct 1994 17:30:46 +0200

The ATM folks think it's so simple that it
   will have no market, while many IP folks want nothing more complex
   from ATM than FIFO queueing with big buffers (which would be a
   satisfactory implementation of UBR.)

mark,

i have nothing against simplicity, but you make implementing ubr too
simple.  even in case of ubr, one would like to have at least some
degree of fairness and to avoid dropping of cells, unless you at the
same time drop all cells of the same frame.  large buffers alone don't
provide this.

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Oct 1994 12:42:33 -0400

> satisfactory implementation of UBR.)

I think I qualify as an "IP folk", so I'd like to qualify the above
statement, if I may.

IP folks would be much happier if they could get adequate buffering
out of a switch, where adequate means greater than one delay bandwidth
product.  For example, for DS3 across the US continent (a problem we -
ANS, Alernet, Sprint, MCI, ... - already face in production
unchannelized DS3 networks) has a 380 kB (or roughly  20,000 cell)
delay bandwidth product.  Anything less is inadequate and causes
premature high loss at low (ie: 50% or less) utilizations.  I am not
aware of any ATM switch which is truly available and has enough
buffering for DS3.  

For OC3, multiple by 3.  And then there is the problem of existing DS3
connectivity to Hawaii, which adds almost doubles the potential delay
(from 70 to 120 msec).

Unfortunately for ATM, adequate buffering and cell tail drop don't
quite cut it.  For IP, packet tail drop is not very good but works
well enough with adequate buffering.  At the very minimum ATM needs to
drop complete frames.  Better yet, ATM woulod benefit from a more
intellegent drop strategy.  {aside: we've been working with a
variation of RED (Random Early Detection by Sally Floyd and Van
Jacobson).  If you want to discuss this, please drop the Cc, and we'll
go offline with it.}

Without an intellegent drop strategy (meaning one that is designed to
work well as a feedback stimulus to TCP), too much buffering can also
be a problem, though so far ATM doesn't suffer from this at all.

If UBR offerred adequate buffering and an intellegent drop strategy,
or at least dropped full frames, UBR would be very useful.

> widespread, but far from the exclusive sub-net technology.)

I am very disappointed with the ABR hop by hop flow control proposals.
I was hoping for nothing more than ABR with weighted fair queueing and
an intellegent drop strategy implemented on individual queues.  This
would provide a UBR like service with proportional sharing of the
excess bandwidth, and still using intellegent drop (or ECN for IP6 as
proposed by Floyd in her TCP/ECN paper) and TCP end to end flow
control.  

Whether rate based or credit based, hop by hop has disadvantages over
feedback to the sender.  Hop by hop will not slow down the source
until a queue is formed at each hop along the path.  The queue size at
each hop will be dictated by the distance between hops (ie: feedback
to the previous hop can only take effect after propogation delay to
the previous hop and back) and the hysteresis applied (ie: too little
hysteresis will cause underutilization, too much will cause excess
delay).  For TCP, the feedback needs to go all the way back to the
source (ie: congest every link on the path) in order to cause the
source to slow down.  I would love to see (or do - funding gladly
accepted:) simulations of TCP using the rate based or credit based
schemes (assuming the source(s) are an FDDI ring or ethernet off the
ATM network).  IMO - ATMF should not be standardizing on something
with no implementation experience at all with the scheme and without
even simulation results.

> cast in stone (yet).  The document it affects will be out in April or

Thanks for the pointer.  I'll get comments to you.

Thanks for the note,

Curtis