Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt

From: Michael Menth <[email-masked]>
Date: Thu, 21 Sep 2006 08:23:17 +0200

Hi all,

I quickly browsed through the draft on Pre-Congestion Notification marking
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt
and want to give some comments.

1) I don't understand why Section 2 proposes a virtual queue with a
a probability-based marking when the queue size is within two thresholds.
What is the benefit of such an approach compared with the one of a queue
with a single threshold from which on packets are labelled if they exceed
this limit? Is this maybe a relict from an RED-based ECN-labelling which
might be useful in the presence of TCP traffic? From my perspective, the
task of admission marking is just to mark those packets that exceed the
configured admission rate and a virtual queue is used only to account for
the burstiness of the traffic and to allow some tolerance regarding the
rate. This is similar to the "cell delay variation tolerance (CDVT)" and
the "burst tolerance" in ATM.

2) I was puzzled by the fact that the Admission Marker uses a virtual
queue and that the preemption marker uses a token bucket. I'd prefer
if a solution is given in a similar manner, e.g., two virtual queues
that differ with respect to the following issues:
- Admission marking considers all realtime packets whereas preemption
marking considers only non-preemption-marked packets.
- The admission marker wants to find out whether the configured admission
rate is exceeded and if so, it wants to label all packets. Therefore,
the queue has infinite "buffer size" (probably set to a reasonable
value to recognize quickly if the rate has reduced) and all packets
beyond a certain threshold are labelled.
- In contrast, the preemption marker wants to mark packets that exceed
the configured preemption rate. Therefore, - if a virtual queue is
also used in this case - only those packets exceeding the threshold
are preemption-marked and these packets do not increase the queue
size.
- As the admission marker cannot be based on a token bucket, I consider
the virtual queue as the more appropriate unifying mechanism for both
markers.

Note that this would only describe the behavior of the markers, the
implementation can be done differently.

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

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

---

From: <[email-masked]>
Date: Thu, 21 Sep 2006 13:23:05 +0100

Michael
Thanks for the comments

On 1), we had a lot of discussion amongst the authors without reaching
final agreement on this issue. I think (I may have remembered this
wrong!) that we were leaning towards there not being that much
difference between having two thresholds and having one threshold ("ramp
or probabilistic" vs "step" marking), and that we needed to do some more
simulations to find out whether it makes any odds

A couple of possible reasons for having "ramp" marking:
- robustness to worst case traffic - if the aggregate of traffic at a
router is very smooth, then "step" marking might not give (hardly) any
markings until too many calls are admitted. Whereas "ramp" marking would
give some more warning - in particular, if several routers are marking a
little, then the marking rate at the egress (which is the sum of the
individual routers' marking rates) will be big enough that it starts
blocking calls.
- "ramp" marking may help
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch
eat-01.txt to work. this I-D is about enabling a single PCN-region to
include networks that don't trust each other  - at the borders between
the networks, only bulk measurements (of PCN markings) are needed. For
the idea to work, it needs a little bit of marking at data rates below
the configured-admission-rate. "ramp" marking helps this [there may be
alternative ways].

There's also the question of whether it could be left open to operator,
ie standard could have 2 thresholds, however in deployment you can set
them the same. 

On 2), as far as I remember there was no particular reason for the
description using token buckets rather than virtual queues - just [I
think] we found it easier to think about / describe like that. 

Where you say
indeed, we found a problem if the max size of the virtual queue is
"infinite" [NB the virtual queue is just a number, not a buffer].
Because then the marking probability can be 100% even when there are no
packets in the real queue. Why? After a period of excess traffic the
virtual queue grows. Say the arrival rate now drops to 0. It will take
about (size-of-virtual-queue / configured-admission-rate) secs for the
virtual queue to empty and the marking probability to drop so that calls
can once again be admitted. Therefore, if size-of-virtual-queue is too
big, after a lengthy period of excess traffic there will be a lengthy
recovery period whilst the virtual queue empties. However, the real
queue is constrained in length, because it drops packets and so will be
able to enqueue packets again much sooner.  The value used for
size-of-virtual-queue in simulations was, I think, chosen fairly
arbitrarily - twice the real buffer size rings a bell. 

Best wishes,
phil

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 21 September 2006 07:23
To: [email-masked]
Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt

Hi all,

I quickly browsed through the draft on Pre-Congestion Notification
marking
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt
and want to give some comments.

1) I don't understand why Section 2 proposes a virtual queue with a
a probability-based marking when the queue size is within two
thresholds.
What is the benefit of such an approach compared with the one of a queue
with a single threshold from which on packets are labelled if they
exceed
this limit? Is this maybe a relict from an RED-based ECN-labelling which
might be useful in the presence of TCP traffic? From my perspective, the
task of admission marking is just to mark those packets that exceed the
configured admission rate and a virtual queue is used only to account
for
the burstiness of the traffic and to allow some tolerance regarding the
rate. This is similar to the "cell delay variation tolerance (CDVT)" and
the "burst tolerance" in ATM.

- The admission marker wants to find out whether the configured
admission

Best wishes,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Sep 2006 15:15:02 +0200

Hi Philip,

> simulations to find out whether it makes any odds
Ok. I don't expect much difference.

> individual routers' marking rates) will be big enough that it starts
I think that the sensitivity to bursty traffic can be rather controlled 
by the size of the virtual queue itself.

> the configured-admission-rate. "ramp" marking helps this [there may be
Hm, not quite understood. Anyway. But again, I think that the size of 
the virtual queue is enough to control the marking. Simulations could 
proof or disprove whether probability-based marking has any benefit over 
a simpler queue with a reasonably set queue size.
> arbitrarily - twice the real buffer size rings a bell. 
So we think the same about this issue. I can imagine that the quest for 
a reasonable queue size of the preemption marker is also an open issue 
and subject to further research.

Kind regards,

    Michael

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 21 Sep 2006 11:35:32 -0400

We actually have been doing simulations on the algorithms.
And have been sharing them with the design team (some of our many
hours of design meetings during previous IETFs and other mtgs).

It may be helpful to have 15-30 minutes of agenda time during
the BOF to share some high lights of simulation results.
This will help some of discussions we are having on the CL-PHB draft.

This is a suggestion and is meant to solicit interest and response.
IMHO, this is secondary to the main topic of Problem Statement and Goals
and getting the WG started.  But this follows right on the heels of
creating the WG.

Thanks!
-- Kwok --

At 09:15 AM 9/21/2006, Michael Menth wrote:
>I think that the sensitivity to bursty traffic can be rather 
>controlled by the size of the virtual queue itself.
>
>Hm, not quite understood. Anyway. But again, I think that the size 
>of the virtual queue is enough to control the marking. Simulations 
>could proof or disprove whether probability-based marking has any 
>benefit over a simpler queue with a reasonably set queue size.
>>
>So we think the same about this issue. I can imagine that the quest 
>for a reasonable queue size of the preemption marker is also an open 
>issue and subject to further research.
>
>
>Kind regards,
>
>    Michael
>
>>Best wishes,
>>phil
>>

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Sep 2006 18:41:26 +0200

Hi Kwok-Ho

I cannot be at the next meeting but I am interested in your results.

Best wishes,

    Michael

Kwok-Ho Chan wrote:
>> proof or disprove whether probability-based marking has any benefit 
>> over a simpler queue with a reasonably set queue size.
>>>
>>> From: Michael Menth [mailto:[email-masked]] Sent: 
>>> 21 September 2006 07:23
>>> To: [email-masked]

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 21 Sep 2006 13:03:53 -0400

Michael:
OK.
We will post all our presentations and published drafts at:
   http://standards.nortel.com/pcn/
and notify the [email-masked] list when they are available.

IMHO, we need to have these supporting work to push
the CL-PHB draft forward.
And I am inviting others on this list to join in with this effort.
These are the sweat equity we need to create.

-- Kwok --

At 12:41 PM 9/21/2006, Michael Menth wrote:
>>>So we think the same about this issue. I can imagine that the 
>>>quest for a reasonable queue size of the preemption marker is also 
>>>an open issue and subject to further research.
>>>
>>>
>>>Kind regards,
>>>
>>>    Michael
>>>
>>>>Best wishes,
>>>>phil
>>>>