[e2e] Admission Control and Policing in MPLS

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Sat Nov 6 08:59:14 PST 2004

I dont think you are getting my point at all

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.

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:

 >>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 
 >>> >>
 >>> >>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,
 >>> >>- 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



More information about the end2end-interest mailing list