Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 25 Oct 2006 17:36:52 -0400

Hi Michael,

I do agree with your observation that if smooth traffic consistently
exceeds the admission threshold, then all traffic soon starts getting
admission-marked, and hence further admission is prevented.  Strictly
speaking that does not contradict the statement that in that case PCN
fails to prevent admission *prior* to reaching the admission threshold.
But indeed, as admission control is expected to be substantially below
the link speed (or real queue service rate), that is not in practice a
serious problem, in my opinion.   Perhaps the next version of the draft
could elaborate on this a bit more. 

Anna 

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 5:05 AM
To: Kwok-Ho Chan
Cc: [email-masked]
Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt
submission

Hi all,

I browsed through the drafts and have some comments on Section 5
"Aggregate Traffic Characteristics" which says:

"However, too little [traffic] variation can also be a problem [for the
PCN marking].  For example, if all the sources are constant bit rate and
are synchronised, then the total traffic level at a router's interface
could be (almost) at its capacity and all packets could still be
serviced instantly.  However, admitting one more flow could tip the
router over its capacity, so its queue grew indefinitely until it had to
drop packets.  "Some" traffic variation means that as the traffic level
nears the capacity limit, some packets are PCN-marked but there's still
enough capacity to cope with the traffic fluctuations.  Hence new flows
can be blocked and packets are never dropped."

With PCN, all packets are "stop admission marked" if the currently
observed rate exceeds the configured "admissible interface rate". The
configured "admissible interface rate" is usually substantially smaller
than the physical link bandwidth.

In the context of RED marking, only those packets are marked that exceed
a certain threshold of the physical queue which is served at link rate. 
If the traffic exceeds the link rate preliminarily on a small time
scale, a queue builds up and some of the queued packets are marked. This
can also happen if the aggregate rate is low, but if bursts arrive. In
contrast, if the rate of the aggregate reaches almost the link
bandwidth, but if it is sufficiently smooth, no queue builds up. Thus,
the problem with RED-like marking is that it can give EARLY warning only
if the current traffic rate is below the link rate but exceeds it due to
short term variations.

 From my perspective, PCN marking does not have this problem because it
reacts if the sent rate exceeds the configured rate and that can be well
observed on a larger time scale than packet level, short term variations
are not required to this end. Therefore, PCN marking leads to more
stable results than RED marking and it does not need to give a warning
if the configured "admissible interface rate" is not achieved on a
medium time scale (~1s). Therefore, early warning can be perfectly done
also for extremely smooth CBR traffic.

Best wishes,

    Michael

Kwok-Ho Chan wrote:
> Hi:
> Please notice I have submitted an update to the Problem-Statement
draft.
> Please see the link to the draft at:
>   
> http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.tx
> t
>
> There were couple of minor cleanups.
> I have also added a new section just to set up the discussion of 
> trust, with the trust assumptions and security still in the 
> assumptions and security sections (as they were in -00).
> Thanks!
> -- Kwok --
>
>
> At 03:04 AM 10/23/2006, you wrote:
>> This is the submission of an update (version 01) to an individual
draft.
>>
>> Title:         Pre-Congestion Notification Problem Statement
>>
>> Filename:  draft-chan-pcn-problem-statement-01.txt
>>
>> Abstract:
>>    DiffServ mechanisms have been developed to support Quality of
Service
>>    (QoS).  However, the level of assurance that can be provided with
>>    DiffServ without substantial over-provisioning is limited.  Pre-
>>    Congestion Notification (PCN) investigates the use of per-flow
>>    admission control to provide the required service guarantees for
the
>>    admitted traffic.  While admission control will protect the QoS
under
>>    normal operating conditions, an additional flow pre-emption
mechanism
>>    is necessary in the times of heavy congestion (e.g. caused by
route
>>    changes due to link or node failure).
>>
>>    This document provides a problem statement on the addition of flow
>>    admission control and flow pre-emption functionality to a DiffServ
>>    network, in particular for the support of real time services such
as
>>    voice and video.
>>
>>
>> If there is any question or problem related to this submission, 
>> please contact:
>> Kwok Ho Chan
>> E-Mail:  [email-masked]
>> Phone:  978-288-8175
>>
>> The text version of the draft is attached.
>>
>> Thank You!
>> -- Kwok --
>>
>>
>>
>
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science Am Hubland,
D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 27 Oct 2006 11:00:55 +0100

Agree with your comments.

With very smooth traffic, indeed adding 'one more flow' can move the
router from marking no packets to marking all of them. 
With bursty traffic, we see an increasing % of pkts being marked (on
average) as the traffic level is increased. 
Hence with bursty traffic you start to get pkt marks (warnings of
potential congestion) at lower average traffic level. This behaviour is
good, as bursty traffic has a greater danger of causing some pkt
delay/drop in the real queue. 

If traffic was always smooth, rather than use a virtual queue the router
could just measure the traffic rate (on some kind of moving average). It
would work just as well. However, if the traffic is bursty, using a
virtual queue is better. Because it gives a better measure (than average
rate) of what might happen on the real queue 'soon' (ie if the traffic
increased further). 

Effectively the virtual queue gives you another parameter to play with -
as well as the average rate, the virtual queue threshold (ie length at
which go from no marking to marking). This allows you to control how
sensitive you are to bursty traffic. 

Thanks
Phil Eardley 
Ben Strulo

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: 25 October 2006 22:37
To: [email-masked]; Kwok-Ho Chan
Cc: [email-masked]
Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt
submission

Hi Michael,

Anna 

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 5:05 AM
To: Kwok-Ho Chan
Cc: [email-masked]
Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt
submission

Hi all,

Best wishes,

    Michael

draft.
draft.
Service
the
under
mechanism
route
as

---

From: Michael Menth <[email-masked]>
Date: Mon, 30 Oct 2006 19:07:28 +0100

Dear Phil,

> sensitive you are to bursty traffic. 
I definitely support the virtual queue for excess-traffic marking. 
However, for the stop-admission marking I am still undecided what is 
best since we want to have a clear and stable answer whether more 
traffic can be admitted. I think this might an issue for further research.

Best wishes,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn