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

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Thu, 21 Sep 2006 07:51:28 -0400

Hi Michael,

See below, please... 

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 2:23 AM
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? 

[Anna] there are theoretically some advantages in probabilistic marking
relizable over multiple congested hops - but indeed we did not see too
much difference in simulation between probabilistic and 'step' marling.
Since 'step' is a special case or 'ramp' the draft obviously allows
both.
In general,  the framework may allow multiple ways to mark traffic
(which also relates to your question below) - so there is a lot of room
to discuss possible solutions to the problem.   

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.

[Anna]  I agree that it is tempting to use the same underlying
mechanisms for marking for admission and preemption. We actually have
done some simulations on the case when both cac and reemption marking
are done in a uniform manner (in this case both based on a token bucket
implementation) - and we expect to report the results at the next ietf.
There are a number of pros and cons for doing so which we hope to
address then, but again we hope that ivestigating pros and cons of
different solutions (and distilling which are the building blocks
requiring standartization) could be done withing the scope of the new WG
should it be created.

Regards,
Anna 

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

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