[Diffserv-interest] Re: Admission and congestion control

["John H. Shuler" <[e-mail]>]

I guess my point is that admission control is an application-specific
phenomenon. The DiffServ network simply sees control traffic between the
client and VoIP server and treats it appropriately, then when/if the server
tells the client to go ahead, the DS network then sees voice traffic and
treats it appropriately. It is not up to the DS network to admit or not.

Same concept as with TCP and congestion control. Not up to DS to do this,
but up to TCP. DS only sets limits on total BE traffic and bursts.

j

> From: Brian E Carpenter <[e-mail]>
> Organization: IBM
> Date: Fri, 31 Oct 2003 10:51:58 +0100
> To: "John H. Shuler" <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Diffserv-interest] congestion in diffserv network
> 
> "John H. Shuler" wrote:
>> 
>> It is my understanding that DiffServ does not attempt to prevent congestion
>> at all, but only to ensure the the best chance for services to get the
>> treatment they need (vs. Want) by making choices about queuing priorities.
> 
> That's what I meant about it creating several separate Internets - you put
> the traffic into the Internet that has the most appropriate queue handling
> for your traffic, but ultimately (even for EF behavior) the result is still
> statistical. Queueing theory doesn't go away just because it has unpleasant
> consequences.
> 
>> 
>> It is up to the carrier to monitor congestion periodically to prevent
>> lowest-priority traffic from being too congested. EF should ALWAYS get
>> through on-time, and AF CIR should always get through, if somewhat delayed
>> and jittery. The cases when this is NOT true should be rare and bizarre
>> (earthquakes, major network outages, etc.) unless the carrier is not doing
>> their job... Which is simply to make sure they engineer total network
>> bandwidth above the level of peak CIR.
> 
> Exactly. Each traffic class (i.e. each queue) needs to be provisioned for
> the expected load with appropriate over- or under-provisioning. The new
> thing is that you can over-provision for some traffic and under-provision
> for other traffic. (New to IP, that is. It's hardly a new concept.)
> 
>> 
>> The only alternative to this -- admission control -- imposes a signaling
>> requirement that just adds to the total network burden and is not responsive
>> enough to deal with the unpredictable burstiness of the internet.
> 
> I think that's correct. But there are people in the VoIP world who really do
> want to provision individual calls, which means adding signalling and
> admission
> control. That's fine if they can make it scale, but it isn't part of the
> diffserv
> model. 
> 
>> Am I off-base, here?
> 
> No.
> 
>  Brian
> 
>> 
>> j
>> 
>>> From: [e-mail]
>>> Reply-To: [e-mail]
>>> Date: Wed, 29 Oct 2003 12:00:04 -0500
>>> To: [e-mail]
>>> Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs
>>> 
>>> Send Diffserv-interest mailing list submissions to
>>> [e-mail]
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> or, via email, send a message with subject or body 'help' to
>>> [e-mail]
>>> 
>>> You can reach the person managing the list at
>>> [e-mail]
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Diffserv-interest digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>  1. Re: congestion in diffserv network (John Schnizlein)
>>>  2. Re: congestion in diffserv network (Brian E Carpenter)
>>> 
>>> --__--__--
>>> 
>>> Message: 1
>>> Date: Tue, 28 Oct 2003 12:30:55 -0500
>>> To: "Feng Y" <[e-mail]>
>>> From: John Schnizlein <[e-mail]>
>>> Subject: Re: [Diffserv-interest] congestion in diffserv network
>>> Cc: [e-mail]
>>> 
>>> The simple reason that congestion can occur is that the TCA
>>> need not limit incoming traffic sufficiently to avoid it.
>>> The TCA for expedited forwarding is the only one, of many=20
>>> traffic classes, that seeks to eliminate potential congestion,=20
>>> in order to minimize delay and jitter.
>>> 
>>> The parameters of other class definitions, assured forwarding
>>> for example, are intended to mark traffic at different ingress
>>> rates for different treatment when congestion occurs. Note
>>> that this anticipates that congestion will occur.
>>> 
>>> Please recall that the high link utilization in an IP network
>>> is obtained in large measure because traffic loads are high
>>> enough to produce occasional congestion. Cooperative management
>>> of this congestion is the responsibility of transport-layer
>>> protocols.
>>> 
>>> John
>>> 
>>> At 10:43 AM 10/28/2003, Feng Y wrote:
>>>> ... I wonder why the
>>>> overloading or even congestion occurs in diffserv network.
>>>> In diffserv architecture, the =93DS ingress node is
>>>> responsible for ensuring that the traffic entering the DS
>>>> domain conforms to any traffic conditioning agreement (TCA)
>>>> between it and the other domain to which the ingress node
>>>> is connected=94 [RFC 2475]. Moreover,   =93Traffic conditioning
>>>> performs metering, shaping, policing and/or re-marking to
>>>> ensure that the traffic entering the DS domain conforms to
>>>> the rules specified in the TCA, in accordance with the
>>>> domain's service provisioning policy=94. So what causes the
>>>> overloading or congestion in diffserv? Does anyone explain
>>>> it for me or give me some references. Thanks in advance.
>>> 
>>> 
>>> 
>>> --__--__--
>>> 
>>> Message: 2
>>> Date: Wed, 29 Oct 2003 12:07:02 +0100
>>> From: Brian E Carpenter <[e-mail]>
>>> Organization: IBM
>>> To: John Schnizlein <[e-mail]>
>>> CC: Feng Y <[e-mail]>, [e-mail]
>>> Subject: Re: [Diffserv-interest] congestion in diffserv network
>>> 
>>> Another way to look at it is that what diffserv does is split the network=
>>> 
>>> into several separate networks, but each of them retains the statistical
>>> properties of a single Internet.
>>> 
>>>  Brian
>>> 
>>> John Schnizlein wrote:
>>>> =
>>> 
>>>> The simple reason that congestion can occur is that the TCA
>>>> need not limit incoming traffic sufficiently to avoid it.
>>>> The TCA for expedited forwarding is the only one, of many
>>>> traffic classes, that seeks to eliminate potential congestion,
>>>> in order to minimize delay and jitter.
>>>> =
>>> 
>>>> The parameters of other class definitions, assured forwarding
>>>> for example, are intended to mark traffic at different ingress
>>>> rates for different treatment when congestion occurs. Note
>>>> that this anticipates that congestion will occur.
>>>> =
>>> 
>>>> Please recall that the high link utilization in an IP network
>>>> is obtained in large measure because traffic loads are high
>>>> enough to produce occasional congestion. Cooperative management
>>>> of this congestion is the responsibility of transport-layer
>>>> protocols.
>>>> =
>>> 
>>>> John
>>>> =
>>> 
>>>> At 10:43 AM 10/28/2003, Feng Y wrote:
>>>>> ... I wonder why the
>>>>> overloading or even congestion occurs in diffserv network.
>>>>> In diffserv architecture, the =93DS ingress node is
>>>>> responsible for ensuring that the traffic entering the DS
>>>>> domain conforms to any traffic conditioning agreement (TCA)
>>>>> between it and the other domain to which the ingress node
>>>>> is connected=94 [RFC 2475]. Moreover,   =93Traffic conditioning
>>>>> performs metering, shaping, policing and/or re-marking to
>>>>> ensure that the traffic entering the DS domain conforms to
>>>>> the rules specified in the TCA, in accordance with the
>>>>> domain's service provisioning policy=94. So what causes the
>>>>> overloading or congestion in diffserv? Does anyone explain
>>>>> it for me or give me some references. Thanks in advance.
>>>> =
>>> 
>>>> _______________________________________________
>>>> Diffserv-interest mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> 
>>> -- =
>>> 
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> Brian E Carpenter =
>>> 
>>> Distinguished Engineer, Internet Standards & Technology, IBM =
>>> 
>>> 
>>> NEW ADDRESS <[e-mail]> PLEASE UPDATE ADDRESS BOOK
>>> 
>>> 
>>> 
>>> --__--__--
>>> 
>>> _______________________________________________
>>> Diffserv-interest mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
>>> 
>>> 
>>> End of Diffserv-interest Digest
>> 
>> _______________________________________________
>> Diffserv-interest mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> 
> NEW ADDRESS <[e-mail]> PLEASE UPDATE ADDRESS BOOK


_______________________________________________
Diffserv-interest mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/diffserv-interest