[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Toby,

toby.moncaster at bt.com wrote:

I think we should leave terminology as it is. Otherwise we will just get
locked into a circular debate and end up with a more confusing document
as Phil points out below.
That is not true at all. Having concise nomenclature makes documents shorter. You can explain the core idea of PCN-based AC and FT for all PCN independently of any deployment scenario: 
PCN traffic < admissible rate -> admit new flows
admissible rate < PCN traffic < supportable rate -> block new flows
supportable rate < PCN traffic -> block new flows and terminate some admitted flows No case analysis is required that depends on the deployment scenario and the risk that people get something wrong is greatly reduced. 


Yes, there are good arguments for using
Michael's terminology in terms of accuracy but they make the job of
describing the ACTUAL system more difficult and thus risk people getting
things wrong.
Currently, the reference rate for the excess marker is given the name "PCN-excess-rate" and the reference rate for the threshold marker is given the name "PCN-threshold-rate". From my perspective, these terms are not necessary, but they do not harm. They help to describe the three particular deployment scenarios in a very simple way, but only if the general threshold names are available: CL,3sm: PCN-threshold-rate= admissible rate, PCN-excess-rate= supportable rate 
SM: PCN-excess-rate= admissible rate


Given we seem to be focussing in on a small subset of the possible
solutions I think "restrictive" terminology (eg that with extra
semantics within the terms) is no bad thing...
The small subset of possible solutions contains CL and SM and there you have the problem already. 

Regards,

Michael


Toby

-----Original Message-----
From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
philip.eardley at bt.com
Sent: 02 October 2008 14:55
To: menth at informatik.uni-wuerzburg.de
Cc: pcn at ietf.org
Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture



{ -----Original Message-----
{ From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
{ Sent: 02 October 2008 14:26
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: pcn at ietf.org
{ 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 { { philip.eardley at bt.com wrote: 
{ > { -----Original Message-----
{ > { From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
{ > { Sent: 02 October 2008 13:15
{ > { To: Eardley,PL,Philip,CXR9 R
{ > { Cc: pcn at ietf.org
{ > { 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
{ > {
{ > { philip.eardley at bt.com 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
{ > { > PCN at ietf.org
{ > { > 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:menth at informatik.uni-wuerzburg.de
{ > { 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:menth at informatik.uni-wuerzburg.de
{ http://www3.informatik.uni-wuerzburg.de/research/ngn

_______________________________________________
PCN mailing list
PCN at ietf.org
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:menth at informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn

_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn