Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture

From: 佐藤 大輔 <[email-masked]>
Date: Fri, 03 Oct 2008 18:23:18 +0900

Hi Phil and Michael,

Thank Phil for accepting my recent comment.

I agree with Michael about PCN-excess-rate and PCN-threshold-rate
because some new algorithms may use PCN-excess-rate that is less than
PCN-threshold-rate and others may use double PCN-excess-rates or double
PCN-threshold-rates. In my opinion, all the possiblity should not be
excluded. Moreover, they are confusing as Michael pointed out.

Best regards,
Daisuke

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 02 October 2008 14:26
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture
{ 
{ Hi Phil,
{ 
{ sorry, I was confused. You are right. I overlooked that this intrinsic
{ contradiction is resolved by redefining the term "PCN-threshold-rate"
in
{ Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the
{ term "PCN-threshold-rate" depends on the deployment scenario, right?

it isnt redefined; it isnt an intrinsic contradiction. It's consistent.
different deployment scenarios uses PCN marking differently - this
concept is independent of the terminology. 

{ Again, this is very confusing an I recommend to introduce the two
terms
{ "admissible rate" and "supportable rate" in addition. They are
{ independent of the deployment scenario and allow the explanation of
PCN
{ without having a particular deployment scenario in mind.

Having extra terminology is a possibility. I took the view that each
term that is defined is an extra thing for the reader to understand. It
also requires some mapping between the admissible /supportable rates and
excess/threshold rates. Personally I think this likely to be more
confusing. But if there is a clamour in support of this being added, I
could add it. (Michael, I take your vote in favour as read!)

Phil/

{ 
{ Regards,
{ 
{     Michael
{ 
{ [email-masked] wrote:
{ > { -----Original Message-----
{ > { From: Michael Menth [mailto:[email-masked]]
{ > { Sent: 02 October 2008 13:15
{ > { To: Eardley,PL,Philip,CXR9 R
{ > { Cc: [email-masked]
{ > { Subject: Re: [PCN] Second Last Call for
draft-ietf-pcn-architecture
{ > {
{ > { Hi Phil,
{ > {
{ > { I still have concerns regarding the nomenclature in the current
{ > version
{ > { of the architecture draft.
{ > {
{ > { Take Figure 1 on page 10. The terms PCN-threshold-rate and
{ > { PCN-excess-rate are meaningful only in the CL deployment scenario
{ > where
{ > { the reference rate for the threshold marker is the
PCN-threshold-rate
{ > { and the reference rate for the excess marker is the
PCN-excess-rate.
{ > { This is different for the SM deployment scenario where the
reference
{ > { rate of the excess marker must be set to the PCN-threshold-rate.
{ >
{ > This is not correct. The rate of the excess marker is set to the
{ > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment
{ > scenario, how this relates to admission /termination
{ >
{ > Best wishes
{ > Phil
{ >
{ >
{ >
{ > How
{ > { funny is that? No, it's not funny - this is confusing and makes
{ > further
{ > { explanations cumbersome and prone to misunderstandings. I think
that
{ > { this is a bug that should be corrected before publication as these
{ > terms
{ > { help to describe the core idea of PCN. Using the term admissible
rate
{ > { instead of PCN-threshold-rate and supportable rate instead of
{ > { PCN-excess-rate decouples PCN rate thresholds from marking
mechanisms.
{ > { They express the meanings of these thresholds within the PCN
concept
{ > { which are denoted on the right side in Figure 1 and allow a much
{ > clearer
{ > { presentation of the concept.
{ > {
{ > { I hope my reasoning is clear. This document is not a working
document
{ > { for a closed group where nomenclature has no importance as long as
{ > { everybody knows that we mean pears if we say apples - it's a
reference
{ > { for others to learn about PCN and, therefore, technical terms
should
{ > be
{ > { precise and easy to remember.
{ > {
{ > { Regards,
{ > {
{ > {     Michael
{ > {
{ > { [email-masked] wrote:
{ > { > {
{ > { > { There are some known edits that have to be made before we can
{ > submit
{ > { > to
{ > { > { the
{ > { > { IESG:
{ > { > {
{ > { > { - Correct references to Internet Drafts to indicate "Work in
{ > Progress"
{ > { > { - Fix formatting errors detected by ID-nits
{ > { >
{ > { > I just fixed these (I think) in
{ > { >
{ >
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt
{ > { > The only changes from 06 to -07 are to re-format some of the
{ > references
{ > { > in order to fix the above 2 points.
{ > { >
{ > { > Phil
{ > { >
{ > { > Ps to see the -05 to -06 diffs:
{ > { >
{ >
http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn-
{ > { > architecture-06-from-05.diff.html
{ > { > or from
http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/
{ > { > _______________________________________________
{ > { > PCN mailing list
{ > { > [email-masked]
{ > { > https://www.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
{ >
{ 
{ --
{ 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://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Fri, 03 Oct 2008 12:01:50 +0200

Dear Daisuke,

the key feature of threshold marking is that it marks all packets when a 
certain rate is exceeded. Therefore, I like the term "exhaustive 
marking" better than "threshold marking" as it tells you what it does. 
Moreover, algorithms for excess marking also use thresholds and 
exhaustive marking can also achieved by ramp marking, not only by 
threshold marking whose implementation uses a threshold. This is another 
nomenclature issue which I think needs improvement, but it is not as 
important as the introduction of the terms admissible and supportable rate.

What I actually want to say is the following. When the reference rate 
for exhaustive marking (PCN-threshold-rate) is set to the supportable 
rate, either all packets are marked (PCN rate > supportable rate) or 
none (PCN rate < supportable rate). Thus, it clearly indicates whether 
the PCN rate on a link has exceeded the supportable rate or not. 
However, it is not possible to infer an estimate for the traffic rate 
that exceeds the supportable rate. Therefore, exhaustive marking is from 
my perspective not very helpful for flow termination for which the 
supportable rate threshold is relevant. But I don't think either that it 
needs to be prohibited ;-)

Kind regards,

    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