Re: int-serv over e.g. ATM

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>du>, Noel Chiappa writes:
>     From: Curtis Villamizar <[e-mail]>
> 
>     On the other hand, SVCs may cost money. ... If you can often use either a
>     shared VC to the router (shared with other traffic from the same router) 
> or
>     use a VC to that router rather than a direct VC all the way, you might
>     still get the QoS you want and reduce your costs when the router is light
> ly
>     loaded, and get the QoS you want when rejected using a direct VC.
> 
> This sounds to me like a pricing anomaly, i.e. an artifact of prices that
> don't correspond to the actual resources used. Carrying the packets around
> should cost the same in terms of resources consumed, no matter how many layer
> s
> of mechanism you use to do it. So, I'm not sure how imporant this case is; it
> might go away since the market tends to drive prices toward "real" prices.

It happens to be the current way that switched services are normally
priced.  Ever wonder why they are so popular?

> About the only reason I can think of where it might be genuinely cheaper is i
> f
> you have saved the overhead of state/setup required for a separate VC all
> through the net. If this is that big a deal, how come ATM isn't trying to
> aggregate VC's? But the "do we have to aggregate flows" is a whole separate
> can of worms.

It seems to be well accepted that we do have to aggregate flows.  I
can think of numerous reasons.  One is the pricing reasons which have
historically favored PVCs.  The other is the potential for efficiency
gains by aggregating predictive reservations or aggregating elastic
traffic.  It is also easier to budget a pipe and slow down the elastic
traffic than find yourself holding a big bill.

> 	Noel

Curtis