[e2e] Admission Control and Policing in MPLS

[Jon Crowcroft]

I can't stress how much I agree about the evolution of carrier
business - this is an area that is extremely interesting, both
commercially to vendors and service providers, but also to researchers
as we need to consider how to provision for aggregates  of
traditional traffic, but flowing over VPNs and current work on
provisioning has tended to assume the traffic matrix is transparent,
whereas its partially opaque in a vpn....

plus the "arrival process" for a network provider is of entire legacy
enterprise nets (previously provisioned using frame relay or atm ) 
moving over to the IP core...it would be interesting to get estimates
from the large teleco/isps (at&t obviously, but on a smaller scale a
lot of european outfits - certinly BT, FT and DT and telecom italia)
of the amount of legacy net that we might expect to migrate...

also agree about voip..

In missive <418D5B98.9050103 at cs.columbia.edu>, Ping Pan typed:

 >>> what i mean is that the _algorithms and framework_ to do congestion
 >>> control and to do CAC are related and similar - the timescales are
 >>> different - one is per packet or rtt, the other is per session or flow
 >>> or call or forwarding equiv. class or diff serve class or whatever
 >>> aggregate you want but as the system gets very big, the differences
 >>> get very small indeed actually.
 >>> 
 >>
 >>Agree 100%. With the advance in silicon, per-flow policing/shaping, 
 >>queuing and scheduling for various traffic types, dropping... can be 
 >>done at very high speed. Not sure there much magic in this area. The 
 >>issue becomes where to apply all this.
 >>
 >>> i wasnt suggesting that all video/voice/game traffic should be
 >>> converted to be elastic adaptive behaviour (although its not so hard
 >>> for many of them) - conversely one can argue that limiting the number
 >>> of TCP flows through CAC might give a good (near guaranteed ) response
 >>> time to web users too - sure - two sides of same coin....
 >>> In missive <Pine.LNX.4.61.0411062150050.15463 at mars.cse.iitb.ac.in>, Sudeep Goya
 >>> l typed:
 >>> 
 >>
 >>Maybe. There are a couple of exceptions here.
 >>
 >>Since the beginning of commercial data networking, carrier's business 
 >>model has been selling guaranteed bandwidth to individual users. Much of 
 >>the telecom operation has been built around this model (accounting, 
 >>planning, restoration, OAM...). And this is not likely to change in the 
 >>near future, even when you have GigE all over the place. Thus, per-flow, 
 >>per-customer, per-call, per-whatever policing will still be in place at 
 >>edge. However, this does not impact how e2e applications suppose to work 
 >>- long live TCP. ;-)
 >>
 >>Another issue is the method of migrating traffic from the existing 
 >>networks to new ones, while still making money for the carriers. This is 
 >>likely taking place at the edge. During the migration, the entire suite 
 >>of QoS must be in place for many business users. This is where some 
 >>DiffServ type of conditioning would be useful. This is the reason why 
 >>you see a number of proposals on ATM-MPLS interworking in recent months. 
 >>Again, you may find them from IETF MPLS/PWE3/L2VPN WG drafts....
 >>
 >>As for the traffic types. VoIP traffic is not CBR, and never will be. 
 >>;-) In fact, the entire VoIP looks like an enterprise/end-user 
 >>application to me. The switches/routers have no way of knowing what it 
 >>is from the packet itself. One deployment scenario I have seen is to map 
 >>VoIP traffic onto a VLAN, and provisioning BW on that VLAN from network 
 >>edge. In this case, a simple priority queue or a half decent WFQ would 
 >>do the job.
 >>
 >>- Ping
 >>
 >>>  >>On Sat, 6 Nov 2004, Jon Crowcroft wrote:
 >>>  >>
 >>>  >>> on a more general point...
 >>>  >>>
 >>>  >>> personally , i could never see the fundamental different between
 >>>  >>> packet drop mechanis and congestion control
 >>>  >>> and
 >>>  >>> call admission control with call blocking
 >>>  >>>
 >>>  >>> in both cases, you have to look at the provisioning of buffers -
 >>>  >>> based on some model of the traffic source, and make decisions about
 >>>  >>> which packet/flow to drop/block based on the specific source model and
 >>>  >>> the multiplexing and aggregate behaviours...its just a
 >>>  >>> timescale/granualrity difference in the end
 >>>  >>
 >>>  >>Jon. In my humble opinion, there is a big difference depending on the 
 >>>  >>kind of traffic that is being injected into the network.
 >>>  >>
 >>>  >>Say, for example you have a CBR (constant bit rate) traffic for VoIP, 
 >>>  >>video-conferencing and you need to provide stringent qos requirements. 
 >>>  >>You donot bring congestion in the network and here, CAC plays important 
 >>>  >>role. Because any implementation of congestion control mechanism at the 
 >>>  >>core nodes would produce delay etc which we donot want for CBR kind of 
 >>>  >>traffic. The schedulling in this case at each node would also be highest.
 >>>  >>In above traffic, delay and jitter are important qos parameters.
 >>>  >>
 >>>  >>But, for elastic traffic (like FTP) which is also greedy and built over 
 >>>  >>TCP we need to be careful about the throughput because here throughput is 
 >>>  >>more important than delay and hence, we need to deploy proper RED 
 >>>  >>mechanism and maintain high throughput and admit more flows. Dropping of 
 >>>  >>packets and little delay is accpetable. But, throughput should be high. 
 >>>  >>Therefore, CAC algorithm should consider this and accept such elastic 
 >>>  >>traffic accordingly, fulling knowing that RED and congestion control 
 >>>  >>(TCP) is used for such traffic.
 >>>  >>
 >>>  >>For CBR traffic, CBR algorithm cannot take the chance for congestion and 
 >>>  >>most importantly, delay and loss of packets, therefore, never 
 >>>  >>overprovision any flow (flows are also more UDP-oriented). Then there can 
 >>>  >>be other kinds of flows like VBR, elastic short-lived flows and best-effort.
 >>>  >>
 >>>  >>  Thanks Ping Pan for the information again :)  But, plz help me clarify 
 >>>  >>following:
 >>>  >>
 >>>  >>> >>
 >>>  >>> >>Another observation, most deployed MPLS networks in metro area use LDP
 >>>  >>> >>to setup LSP's. LDP does not have QoS awareness by design.
 >>>  >>
 >>>  >>This is informative. But, could you plz tell if coming up with good MPLS 
 >>>  >>over DiffServ CAC algorithms that would help the incoming traffic meet its 
 >>>  >>requested QoS be useful (commercially). From what you have said, it feels 
 >>>  >>that ISPs are not doing it and may not need it at present, but future could be a 
 >>>  >>possiblity. Am i right?
 >>>  >>  If people have already done some work, can you plz refer some links to me 
 >>>  >>(from where I can know the state-of-art of MPLS over DiffServ admission 
 >>>  >>control algorithms)?
 >>>  >>
 >>>  >>Thanks a lot Again.
 >>>  >>
 >>>  >>Warm Regards,
 >>>  >>Sudeep
 >>>  >>
 >>>  >>
 >>>  >>
 >>>  >>
 >>>  >>
 >>>  >>> >>- Ping
 >>>  >>> >>
 >>>  >>> >>
 >>>  >>> >>Sudeep Goyal wrote:
 >>>  >>> >>> Hi Ping Pan,
 >>>  >>> >>>
 >>>  >>> >>>    Thanks for the information. But, you say that CAC would make sense at
 >>>  >>> >>> the edge.  Would you please tell what are the mechanisms used in real
 >>>  >>> >>> ISP networks to find out the explicit paths that meet certain QoS flow
 >>>  >>> >>> requirement. Or are the paths are statically (manually) set without any
 >>>  >>> >>> dynamic traffic engineering ?
 >>>  >>> >>>  I am presently working on algorithms on admission control on MPLS (and
 >>>  >>> >>> MPLS over DiffServ network) and have worked out few algorithms in
 >>>  >>> >>> theory. But, I donot yet know how and what actually ISPs are doing in
 >>>  >>> >>> reality for admission control ? Does it make sense commercially to come
 >>>  >>> >>> up with good TE techniques or algorithms that would help us find
 >>>  >>> >>> explicit paths in MPLS network at the edge that would meet certain QoS
 >>>  >>> >>> requirements. Or may be, given a LSP path, it makes more sense going for
 >>>  >>> >>> a DiffServ admission control rather than finding explicit path.
 >>>  >>> >>>
 >>>  >>> >>> Thanks for anticipated help.
 >>>  >>> >>>
 >>>  >>> >>> warm regards,
 >>>  >>> >>> Sudeep
 >>>  >>> >>>
 >>>  >>> >>>
 >>>  >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote:
 >>>  >>> >>>
 >>>  >>> >>>> First, in the (MPLS) backbone networks, most of the links are
 >>>  >>> >>>> over-provisioned, so not sure CAC and many QoS enforcement would make
 >>>  >>> >>>> much
 >>>  >>> >>>> use there.
 >>>  >>> >>>>
 >>>  >>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP,
 >>>  >>> >>>> that can be used to carry DiffServ class. The LSP's that carry such
 >>>  >>> >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can
 >>>  >>> >>>> run the
 >>>  >>> >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the
 >>>  >>> >>>> packets within the LSP. This function becomes more important during flow
 >>>  >>> >>>> aggregation.
 >>>  >>> >>>>
 >>>  >>> >>>> There are a bunch of drafts from Cisco on this topic over the years.
 >>>  >>> >>>>
 >>>  >>> >>>> - Ping
 >>>  >>> >>>>
 >>>  >>> >>>>> -----Original Message-----
 >>>  >>> >>>>> From: end2end-interest-bounces at postel.org
 >>>  >>> >>>>> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Fahad Dogar
 >>>  >>> >>>>> Sent: Wednesday, October 20, 2004 12:12 AM
 >>>  >>> >>>>> To: end2end-interest at postel.org
 >>>  >>> >>>>> Subject: [e2e] Admission Control and Policing in MPLS
 >>>  >>> >>>>>
 >>>  >>> >>>>>
 >>>  >>> >>>>> Hi,
 >>>  >>> >>>>>
 >>>  >>> >>>>> I would like to know the mechanism employed in MPLS networks
 >>>  >>> >>>>> for admission control and the process of subsequently
 >>>  >>> >>>>> policing the flow in order to ensure that it does not violate the SLA.
 >>>  >>> >>>>>
 >>>  >>> >>>>> Any help or pointers to any standardized requirements would
 >>>  >>> >>>>> be greatly appreciated.
 >>>  >>> >>>>>
 >>>  >>> >>>>> Thanks in advance,
 >>>  >>> >>>>> Fahad
 >>>  >>> >>>>>
 >>>  >>> >>>>
 >>>  >>> >>>>
 >>>  >>> >>>
 >>>  >>>
 >>>  >>> cheers
 >>>  >>>
 >>>  >>>   jon
 >>>  >>>
 >>>  >>>
 >>>  >>
 >>>  >>-- 
 >>> 
 >>>  cheers
 >>> 
 >>>    jon

 cheers

   jon