The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] int-serv over e.g. ATM
In message <9511111714.AA27696@ginger.lcs.mit.edu>, Noel Chiappa writes: > From: Curtis Villamizar <curtis@ans.net> > > 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
|
|