Subject: Re: deploying reservations....

From: [email-masked] (Mark W Garrett)
Date: Tue, 11 Jul 1995 11:34:31 -0400

A few misc comments on these threads:

 > Hiroshi Esaki wrote:
 > But, I think, one to one mapping between IP flowspec and ATM QOS/Traffic 
 > descriptor is just one case, even when the ATM networks provide 
 > variety types of VCCs. 

I didn't get a chance to reply to this a while ago, but I agree
with Hiroshi here.  When I said "mapping", I didn't mean to imply
one-to-one mapping, just the general relationship between the IP
flow QOS and the QOS of the ATM connection which carries the flow
across the ATM cloud.  So the IP router may, quite realistically,
decide that a set of flows that need to go to a common point
across the ATM cloud, is highly multiplexed and smooth enough
that a CBR pipe is quite efficient.

 > Lixia wrote:
 > The first model was from Jon's pragmatic goal of how to deploy
 > RBone in today's NAP-connected provider world.  The box in the middle
 > is just a switch; it is *not* ATM today; will it be later?  we're yet
 > to see (I heard that two NAPs tried but never made it :-)

Yes, of course.  The first generation of ATM switches did not have
sufficient QOS functionality to carry TCP traffic, never mind juggle
several different types of requirements at once.  Next year's switches
*should* do much better, since the specs are getting better, and the
vendors are talking about much more sophisticated scheduling
functionality.  But these are, for the moment, quite unhatched chicks.

 > uninteresting to ATM, since it doesnt have much "value added",
 > but may not be bad for others :-)

Yes, my premise is that ATM only gets interesting when it adds
substantial value to the overall network.  If it doesn't, we might
imagine that it is usable in some way, but there is a question (in my
mind at least) as to how economically viable ATM would be if it only
did CBR type pipes.

 > I feel there is some issue here that's deeper than just how IP and
 > ATM's QOS can map each other.  Assume ATM can do anything it wants,
 > should IP buy the service in whole sale, or retail mode?
 > For the former, IP just buys one pipe and controls all traffic muxing
 > itself.  For the latter (that ATM community wants to see happen), you
 > buy one VC per flow at a time.

As Hiroshi responded, this shows the two ends of the spectrum,
and a lot of the interesting cases lie in between.

 > If we forget *all* other issues and consider only from a technical view
 > point (I know one cannot get away from politics, but just let's assume
 > for a moment): what would be the most efficient way to utilize the
 > resource?

This comes back to the case I mentioned in my long message.  When some
flows share a path-segment within the ATM cloud, and they can properly
be statistically multiplexed, i.e. share a queue and take less
bandwidth together than their QOS would require if they were isolated,
then buying pipes between routers creates unnecessary isolation.

-Mark

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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jul 95 0:39:55 JST

> When I said "mapping", I didn't mean to imply
> across the ATM cloud.

ABR pipes between adjacent routers can efficiently aggregate
best-effort flows, of course.

> So the IP router may, quite realistically,

Wrong. CBR (or anything with minimally assured bandwidth) pipes can't
be shared efficiently unless it's bandwidth is adjusted (up to zero
bandwidth) frequently.

>  > buy one VC per flow at a time.

For the latter, we buy one VC per flow per datalink layer segment
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
at a time.

> then buying pipes between routers creates unnecessary isolation.

Can't you say VBR?

							Masataka Ohta