Subject: [PCN] Nomenclature

From: Michael Menth <[email-masked]>
Date: Mon, 28 Jul 2008 18:00:02 +0200

Hi,

I think the current PCN nomenclature can still be improved. I cite from 
the architecture draft-04:
"The admission control mechanism limits the PCN-traffic on each link to 
*roughly* its PCN-threshold-rate and the flow termination mechanism 
limits the" PCN-traffic on each link to *roughly* its PCN-excess-rate."

Stupid question: is single-marking configured with a PCN-threshold-rate 
or PCN-excess-rate? According to this description the reference rate of 
the excess marker is set to the PCN-threshold rate. That is certainly 
not intended by the names. I think this simple example shows that the 
current nomenclature is not yet perfect. A better approach is described 
in our overview paper.
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-Comparison.pdf

I'm not at the meeting, but maybe you find some time to discuss this 
issue there? I request a small change:
PCN-threshold-rate -> admissible-rate
PCN-excess-rate -> supportable rate
The reference rates of the excess or exhaustive (threshold) markers are 
set to one of these values depending on what should be done with the 
marking.

Threshold marking -> exhaustive marking
I find exhaustive marking better than threshold marking since this term 
does not say nothing about implementation. Ramp marking could also be 
used although we have not found any benefit when doing that.

Good names are important to explain and sell stuff to other people. 
Sometimes to other researchers, sometimes to customers ...

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

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

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 11:39:17 +0100

that's a good spot, thanks. the text you quote needs tweaking as it isn't accurate in a single marking scenario.
 
yes, the change of terminlogy you suggest is possible. i'm sure it's possible to make all the docs consistent with either the existing terminology or with your suggested alternative. personally i dont think one is easier to understand than the other.
 
the consensus at the WG meeting a few ietfs ago, when we discussed terminology, was that the names of the reference rates of the meter/markers should reflect how the markers work rather than what they're trying to achieve. ie PCN-threshold-rate and PCN-excess-rate (for the threshold-marking and excess-traffic-marking behaviours).
 
note that your suggestion makes it harder to write the marking behaviour draft, because you have to say something like "if the opeartor has 3 encoding states, then the excess-traffic-marker sets its reference rate to supportable rate; if the operator only has 2 encoding states and is doing single marking, then the excess-traffic-marker sets its reference rate to the admissible rate". with the existing terminology, the marking draft can simply say "the excess-traffic-marker uses the PCN-excess-rate; the since the marking behaviour is STDS (architecture is Info) i think it's better to make the marking behaviour doc as easy as possible to understand (as this is the thing that implementors write code to do)
 
i dont particularly care about threshold vs exhaustive as terms, and personally dont find much difference in what they imply about implementation. a tiny practical issue in favoour of threshold, is that 'exhaustive' and 'excess rate' have the same first letters, so good abbreviations are less obvious. 

thanks
phil

________________________________

From: [email-masked] on behalf of Michael Menth
Sent: Mon 28/07/2008 17:00
To: pcn
Subject: [PCN] Nomenclature

Hi,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jul 2008 16:39:32 +0200

Hi Phil,

> yes, the change of terminlogy you suggest is possible. i'm sure it's possible to make all the docs consistent with either the existing terminology or with your suggested alternative. personally i d…
the terms admissible and supportable rate are also needed to qualify the 
type of overload or congestion occurred which is needed for 
explanations. See Figure 1 on page 3 in
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-Comparison.pdf
Just imagine to substitute admissible and supportable rate by excess and 
threshold rate. The outcome is not very intuitive.

> the consensus at the WG meeting a few ietfs ago, when we discussed terminology, was that the names of the reference rates of the meter/markers should reflect how the markers work rather than what t…
I was not at that meeting, but my impression was that people did not 
care so much about names and wanted to proceed. Therefore, we ended up 
with the current nomenclature. In addition, at that time PCN was not 
that well understood as today.

>  
> note that your suggestion makes it harder to write the marking behaviour draft, because you have to say something like "if the opeartor has 3 encoding states, then the excess-traffic-marker sets its reference rate to supportable rate; if the operator only has 2 encoding states and is doing single marking, then the excess-traffic-marker sets its reference rate to the admissible rate". 
This is not a bug but a feature: it shows that the configuration of the 
marker depends on what the marker is used for.

> with the existing terminology, the marking draft can simply say "the excess-traffic-marker uses the PCN-excess-rate; the since the marking behaviour is STDS (architecture is Info) i think it's better to make the marking behaviour doc as easy as possible to understand (as this is the thing that implementors write code to do
>   
This is true for 3 encoding states, but it is not true for 2 encoding 
states. Then, the reference rate of the excess marker is set to the 
PCN-threshold-rate. You see what I mean? That's not nice.

> i dont particularly care about threshold vs exhaustive as terms, and personally dont find much difference in what they imply about implementation. a tiny practical issue in favoour of threshold, is…
Well, you mean EM for excess and TM for threshold marking. "T" often 
stands for termination which is not quite what threshold marking is used 
for. So, there are also arguments against this counterargument. EcM and 
EhM works well for abbreviation of excess and exhaustive marking and is 
hard to mistake.

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 16:05:20 +0100

one follow up (otherwise i repeat my original reply)

[phil] No, the excess marker uses the PCN-excess-rate. 
(I think what your comment means is: If you're comparing a scenario where an operator is using both threshold and excess marking, with a scenario where the operator is using "single marking", then the opeartor in scenario 1 may set its PCN-threshold-rate to a similar value to what the operator in scenario 2 sets its PCN-excess-rate.)
 
phil

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jul 2008 22:39:04 +0200

Hi Phil,

> (I think what your comment means is: If you're comparing a scenario where an operator is using both threshold and excess marking, with a scenario where the operator is using "single marking", then…
That's what you think is right, but the definitions in the architecture 
draft say:

   o  PCN-threshold-rate: a reference rate configured for each link in
      the PCN-domain, which is lower than the PCN-excess-rate.  It is
      used by a marking behaviour that determines whether a packet
      should be PCN-marked with a first encoding, "threshold-marked".
/*_      It's roughly the rate up to which PCN admission control should
      accept new flows._*/

   o  PCN-excess-rate: a reference rate configured for each link in the
      PCN-domain, which is higher than the PCN-threshold-rate.  It is
      used by a marking behaviour that determines whether a packet
      should be PCN-marked with a second encoding, "excess-traffic-
      marked".  /_*It's roughly that rate down to which flow termination
      should, if necessary, terminate already admitted flows.*_/

The terms PCN-threshold-rate  and PCN-excess-rate are defined by the 
semantics of an admissible and supportable rate threshold. Therefore, in 
case of single-marking, the reference rate of the excess-marker must be 
set to the  PCN-threshold-rate (=admissible rate). Furthermore, in case 
of single-marking, we have the equation 
PCN-excess-rate=U*PCN-threshold-rate (supportable rate = U * admissible 
rate). Therefore, the PCN-excess-rate cannot be set to a similar value 
as the PCN-threshold-rate. Hopefully this accidental example of 
confusion side makes clear why I point out that the nomenclature should 
be improved.

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 10:12:53 +0100

yes, thanks I'd already spotted that the last two sentences of these two definitions needed to be removed. 
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Tue 29/07/2008 21:39
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Nomenclature

Hi Phil,

Regards,

    Michael

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jul 2008 10:14:30 +0100

I myself prefer Michael's terminology and find it more understandable.

Michael Menth wrote:
>> that's a good spot, thanks. the text you quote needs tweaking as it 
>> isn't accurate in a single marking scenario.
>>  
>> yes, the change of terminlogy you suggest is possible. i'm sure it's 
>> possible to make all the docs consistent with either the existing 
>> terminology or with your suggested alternative. personally i dont 
>> think one is easier to understand than the other.
>>   
>> the consensus at the WG meeting a few ietfs ago, when we discussed 
>> terminology, was that the names of the reference rates of the 
>> meter/markers should reflect how the markers work rather than what 
>> they're trying to achieve. ie PCN-threshold-rate and PCN-excess-rate 
>> (for the threshold-marking and excess-traffic-marking behaviours).
>>   
>> note that your suggestion makes it harder to write the marking 
>> behaviour draft, because you have to say something like "if the 
>> opeartor has 3 encoding states, then the excess-traffic-marker sets 
>> its reference rate to supportable rate; if the operator only has 2 
>> encoding states and is doing single marking, then the 
>> excess-traffic-marker sets its reference rate to the admissible rate". 
>> with the existing terminology, the marking draft can simply say "the 
>> excess-traffic-marker uses the PCN-excess-rate; the since the marking 
>> behaviour is STDS (architecture is Info) i think it's better to make 
>> the marking behaviour doc as easy as possible to understand (as this 
>> is the thing that implementors write code to do
>>   
>> i dont particularly care about threshold vs exhaustive as terms, and 
>> personally dont find much difference in what they imply about 
>> implementation. a tiny practical issue in favoour of threshold, is 
>> that 'exhaustive' and 'excess rate' have the same first letters, so 
>> good abbreviations are less obvious.

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Jul 2008 11:27:04 +0200

Hi Phil,

well, what's left over from the definition then is that 
PCN-excess/threshold-rate is the reference rate for the excess/threshold 
marker. I'm fine with that. But what's still missing for explanation of 
PCN are names to indicate the rate up to which PCN admission control 
should accept new flows or down to which flow termination should tear 
down already admitted flows. I propose to use admissible-rate and 
supportable-rate for that purpose and to add them to the terminology 
section. I think these expressions are fairly intuitive and helpful.

Also talking about exhaustive marking instead of threshold marking may 
have advantages because it does not imply any implementation details. 
Note that also excess marking requires a threshold for packet size 
independent marking. Maybe this shows why I don't like talking about 
threshold marking.

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 10:28:56 +0100

I confess that I have now got TOTALLY confused by all the different terminology. The really strong argument against Michael's terminology is that, as both marking behaviours start with the same first and second letters they need fairly obscure and unclear abbreviations...
 
Toby

From: [email-masked] on behalf of Tom Taylor
Sent: Wed 30/07/2008 10:14
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Nomenclature

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 30 Jul 2008 05:38:58 -0400

Hi all,

I also believe that at this late stage in the process, it is
counter-productive to change the terminology drastically in the WD
drafts and those that follow it. That is not to say that we do not need
to fix obvious problems.  

Personally, I also find explosion of terms for the same things quite
confusing as things keep reappearing in different drafts under different
names, so I can't help wishing we could stick to some set of terms and
go with that set.

Personally, not finding any new names more (or less) appealing that the
ones we have in the terminology section of the architecture draft,  I
would prefer if we could stick with the ones we had previously agreed
on, and concentrate on the things we still need to decide beyond the
terminology.

Best,
Anna  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, July 30, 2008 5:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I confess that I have now got TOTALLY confused by all the 
> different terminology. The really strong argument against 
> Michael's terminology is that, as both marking behaviours 
> start with the same first and second letters they need fairly 
> obscure and unclear abbreviations...
>  
> Toby
> 
> > the terms admissible and supportable rate are also needed 
> to qualify 
> > the type of overload or congestion occurred which is needed for 
> > Just imagine to substitute admissible and supportable rate 
> by excess 
> > and threshold rate. The outcome is not very intuitive.
> >
> >> 
> > This is not a bug but a feature: it shows that the configuration of 
> > the marker depends on what the marker is used for.
> >
> > stands for termination which is not quite what threshold marking is 
> > used for. So, there are also arguments against this 
> counterargument. 
> > EcM and EhM works well for abbreviation of excess and exhaustive 
> > marking and is hard to mistake.
> >
> > Regards,
> >
> >    Michael
> >
> >> 
> >> 
> >> 
> >> thanks
> >> phil
> >> 
> >> 
> >> I think the current PCN nomenclature can still be improved. I cite 
> >> from the architecture draft-04:
> >> "The admission control mechanism limits the PCN-traffic on 
> each link 
> >> to
> >> Stupid question: is single-marking configured with a 
> >> PCN-threshold-rate or PCN-excess-rate? According to this 
> description 
> >> the reference rate of the excess marker is set to the 
> PCN-threshold 
> >> rate. That is certainly not intended by the names. I think this 
> >> simple example shows that the current nomenclature is not yet 
> >> perfect. A better approach is described in our overview paper.
> >> 
> >> PCN-threshold-rate -> admissible-rate PCN-excess-rate -> 
> supportable 
> >> rate The reference rates of the excess or exhaustive (threshold) 
> >> markers are set to one of these values depending on what should be 
> >> done with the marking.
> >>
> >> Threshold marking -> exhaustive marking I find exhaustive marking 
> >> better than threshold marking since this term does not say nothing 
> >> about implementation. Ramp marking could also be used although we 
> >> have not found any benefit when doing that.
> >>
> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >> Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> >> room B206

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 10:45:53 +0100

no terminology is perfect. i find that different people prefer differently terminology. i suspect this is becuase have different backgrounds, different interests, and different ways their brains work.
 
as soon as the ID submission tool opens up again I plan to submit an update of the architecture that deals with various nits, including the ones you've spotted on terminology. also, i'll include a couple of pics which hopefully will help with people's understanding of what the terms mean (similar to one of your pics in your report)
 
I'm hoping that this minor rev will be ready for WG last call (to be discussed at WG meeting). i suggest that any remaining terminology points are dealt with as part of this. 
 
thanks
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Wed 30/07/2008 10:27
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Nomenclature

Hi Phil,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Jul 2008 11:56:53 +0200

Hi Toby,

your argument relates to excess marking vs. exhaustive marking. I just 
can comment that I personally prefer to have a weaker abbreviation than 
a name (threshold marking) for exhaustive marking that could be applied 
equally well for excess marking as its implementation also requires some 
threshold.

This issue is independent of the debate admissible and supportable rate 
vs. PCN-excess- and PCN-threshold-rate for which I do not know any 
arguments against except for the fact that pervious doc used other but 
also non-consistent expressions while many arguments in favor exist 
(clarity, intuition, compatibility for all proposals).

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Jul 2008 12:08:40 +0200

Hi Anna,

CL, SM, 3sm, LC-PCN, and the architecture draft use all different 
nomenclature. Streamlining is required anyway. It's up to us whether we 
produce a well-understandable description or a rather technical one that 
is hard to follow. I have done a lot of comparison work and know from my 
experience that terms like admissible and supportable rate are 
PCN-specific but implementation-independent which is a good thing. This 
helps to avoid unnecessary explanations for expressions like 
PCN-excess-rate whose semantics are implementation-specific (i.e. what 
does the value imply: admissible or supportable rate?).

I agree that technical aspects are more important. But nomenclature is 
also too important to be ignored, especially at a stage where not a 
single RFC is published.

Regards,

    Michael

Anna Charny (acharny) wrote:
>>>> that's a good spot, thanks. the text you quote needs 
>>>>         
>> tweaking as it 
>>     
>>>> yes, the change of terminlogy you suggest is possible. i'm 
>>>>         
>> sure it's 
>>     
>> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth
>>     
>>> 08-PCN-Comparison.pdf
>>>
>>>> they're trying to achieve. ie PCN-threshold-rate and 
>>>>         
>> PCN-excess-rate 
>>     
>>> I was not at that meeting, but my impression was that 
>>>       
>> people did not 
>>     
>>> care so much about names and wanted to proceed. Therefore, 
>>>       
>> we ended up 
>>     
>>> with the current nomenclature. In addition, at that time 
>>>       
>> PCN was not 
>>     
>>>> opeartor has 3 encoding states, then the 
>>>>         
>> excess-traffic-marker sets 
>>     
>>>> excess-traffic-marker sets its reference rate to the 
>>>>         
>> admissible rate".
>>     
>>>> with the existing terminology, the marking draft can 
>>>>         
>> simply say "the 
>>     
>>>> excess-traffic-marker uses the PCN-excess-rate; the since 
>>>>         
>> the marking 
>>     
>>>> behaviour is STDS (architecture is Info) i think it's 
>>>>         
>> better to make 
>>     
>>>> the marking behaviour doc as easy as possible to 
>>>>         
>> understand (as this 
>>     
>>> This is true for 3 encoding states, but it is not true for 
>>>       
>> 2 encoding 
>>     
>>>> i dont particularly care about threshold vs exhaustive as 
>>>>         
>> terms, and 
>>     
>>>> that 'exhaustive' and 'excess rate' have the same first 
>>>>         
>> letters, so 
>>     
>>> Well, you mean EM for excess and TM for threshold marking. 
>>>       
>> "T" often 
>>     
>>>> *roughly* its PCN-threshold-rate and the flow termination 
>>>>         
>> mechanism 
>>     
>>>> limits the" PCN-traffic on each link to *roughly* its 
>>>>         
>> PCN-excess-rate."
>>     
>> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Ment
>>     
>>>> h08-PCN-Comparison.pdf
>>>>
>>>>
>>>> I'm not at the meeting, but maybe you find some time to 
>>>>         
>> discuss this 
>>