[e2e] Admission Control and Policing in MPLS

Ping Pan pingpan at cs.columbia.edu
Sat Nov 6 15:17:44 PST 2004


> 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


More information about the end2end-interest mailing list