Subject: [PCN] Issues A1, A2, A3, A4

From: <[email-masked]>
Date: Mon, 2 Oct 2006 15:09:55 +0100

Thought I'd try to close a few more of the Issues - covering the Issues
"A. Terminology Issues" listed at
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
A1      "PCN-Region Term" Issue 
Should the region running the PCN mechanism be called the PCN-Region or
PCN-Domain?
 Reference: draft-chan-problem-statement-00.txt section 2.1.
 RFC2998 supports use of Region, RFC2474 supports use of Domain.
Personally I don't mind, happy to stick with PCN-region as currently
used in draft-chan-problem-statement. 
 
A2      "PIN Term" Issue 
Should we use the terminology PCN Interior Node or PCN Intermediate Node
(function)?
 Reference: draft-chan-problem-statement-00.txt section 2.1.
 RFC2475 supports use of PCN Interior Node
Personally I slightly prefer PCN Interior Node, though I don't mind
much. So happy to stick with PCN Interior Node as currently used in
draft-chan-problem-statement

A3      "PEN Term" Issue
Should we use the terminology PCN End Node or PCN Edge Node or PCN
Boundary Node or PCN Border Node or PCN Gateway Node (function)?
 Reference: draft-chan-problem-statement-00.txt section 2.1.
 The term currently used in draft-chan-problem-statement is PCN End Node
 
Personally I don't like the term PCN End Node - the problem is that it
will probably get shortened to end node (already seen this happening on
the list). I think this will get confusing as [1] the innocent may think
it means 'end host'; [2] the deployment models will probably show how
PCN fits into the 'big picture' of end-to-end QoS, in which case we'd
have both end hosts & PCN End Nodes. 
 
I also think PCN Gateway Node (function) could be slightly confusing.
The actual physical node where the "PCN End Node" function sits is
typically the PCN-region's gateway node, but it could in some deployment
situations be an end host, if the PCN-region extends out that far. 
 
PCN Boundary Node would be consistent with rfc2474 terminology.
PCN Border Node is a similar possibility that Michael has suggested. 
 
PCN Edge Node allows us to continue to use the nice acronym PEN, with
its hint of 'penning in' the PCN-region. 
 
I favour PCN Edge Node, and also ok with PCN Boundary / Border Node

A4    "Pre-emption Marking term" Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting
existing flows/sessions to allow additional new flows/sessions to be
admitted.  This scenario is not allowed in some markets due to
regulations.  Should a better term be used instead of Pre-emption
Marking to indicate the need to reduce the offered traffic load to the
congested portions of the network?

Michael suggested "excess traffic mark" - what do you reckon?

Best wishes

phil

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 02 Oct 2006 10:42:56 -0400

Some other suggestions related to Issue A4 of:

>A4    “Pre-emption Marking term” Issue
>
>Pre-emption Marking may seem to indicate the 
>requirement of pre-empting existing 
>flows/sessions to allow additional new 
>flows/sessions to be admitted.  This scenario is 
>not allowed in some markets due to 
>regulations.  Should a better term be used 
>instead of Pre-emption Marking to indicate the 
>need to reduce the offered traffic load to the 
>Michael suggested “excess traffic mark” – what do you reckon?

How about the terms of:
"Admissible Rate Marking" for the marking 
indication of exceeding the "Admissible Rate"
and
"Supportable Rate Marking" for the marking 
indication of exceeding the "Supportable Rate" ?

It is then up to the Policy Decision to take the 
appropriate action when the rate of traffic is
not "Supportable" anymore.  With Preemption being 
one of the possible policy decision actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006, [email-masked] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF"
>
>
>Thought I’d try to close a few more of the 
>Issues – covering the Issues “A. Terminology 
>Issues” listed at 
><http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt>http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
>
>
>Should the region running the PCN mechanism be 
>called the PCN-Region or PCN-Domain?
>Personally I don’t mind, happy to stick with 
>PCN-region as currently used in draft-chan-problem-statement.
>
>A2      "PIN Term" Issue
>Should we use the terminology PCN Interior Node 
>or PCN Intermediate Node (function)?
>Personally I slightly prefer PCN Interior Node, 
>though I don’t mind much. So happy to stick with 
>PCN Interior Node as currently used in draft-chan-problem-statement
>
>
>A3      "PEN Term" Issue
>Should we use the terminology PCN End Node or 
>PCN Edge Node or PCN Boundary Node or PCN Border 
>Node or PCN Gateway Node (function)?
>Personally I don’t like the term PCN End Node – 
>the problem is that it will probably get 
>shortened to end node (already seen this 
>happening on the list). I think this will get 
>confusing as [1] the innocent may think it means 
>‘end host’; [2] the deployment models will 
>probably show how PCN fits into the ‘big 
>picture’ of end-to-end QoS, in which case we’d 
>I also think PCN Gateway Node (function) could 
>be slightly confusing. The actual physical node 
>where the “PCN End Node” function sits is 
>typically the PCN-region’s gateway node, but it 
>could in some deployment situations be an end 
>host, if the PCN-region extends out that far.
>
>PCN Edge Node allows us to continue to use the 
>nice acronym PEN, with its hint of ‘penning in’ the PCN-region.
>
>A4    “Pre-emption Marking term” Issue
>Pre-emption Marking may seem to indicate the 
>requirement of pre-empting existing 
>flows/sessions to allow additional new 
>flows/sessions to be admitted.  This scenario is 
>not allowed in some markets due to 
>regulations.  Should a better term be used 
>instead of Pre-emption Marking to indicate the 
>need to reduce the offered traffic load to the 
>Michael suggested “excess traffic mark” – what do you reckon?
>
>Best wishes
>phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 2 Oct 2006 16:51:32 +0200

Hi Kwock
 
What about using the term "severe congestion marking"?
 
Best Regards,
Georgios

  _____  

From: Kwok-Ho Chan [mailto:[email-masked]] 
Sent: maandag 2 oktober 2006 16:43
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Issue A4 Preemption Marking Term

Pre-emption Marking may seem to indicate the requirement of pre-empting
existing flows/sessions to allow additional new flows/sessions to be
admitted.  This scenario is not allowed in some markets due to regulations.
Should a better term be used instead of Pre-emption Marking to indicate the
need to reduce the offered traffic load to the congested portions of the
network?

How about the terms of:
"Admissible Rate Marking" for the marking indication of exceeding the
"Admissible Rate"
and 
"Supportable Rate Marking" for the marking indication of exceeding the
"Supportable Rate" ?

It is then up to the Policy Decision to take the appropriate action when the
rate of traffic is
not "Supportable" anymore.  With Preemption being one of the possible policy
decision actions.

Thanks!
-- Kwok --

Thought I'd try to close a

few more of the Issues - covering the Issues "A. Terminology Issues"

listed at

 <http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt> 

 

Should the region running

the PCN mechanism be called the PCN-Region or

PCN-Domain?

 Reference:

draft-chan-problem-statement-00.txt section

2.1.

 RFC2998 supports use

of Region, RFC2474 supports use of

Domain.

Personally I don't mind,

happy to stick with PCN-region as currently used in

draft-chan-problem-statement.

A2      "PIN Term" Issue

Should we use the

terminology PCN Interior Node or PCN Intermediate Node

(function)?

 Reference:

draft-chan-problem-statement-00.txt section

2.1.

 RFC2475 supports use

of PCN Interior

Node

Personally I slightly

prefer PCN Interior Node, though I don't mind much. So happy to stick

with PCN Interior Node as currently used in

 

A3      "PEN Term"

Issue

Should we use the

terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN

Border Node or PCN Gateway Node

(function)?

 Reference:

draft-chan-problem-statement-00.txt section

2.1.

 The term currently

used in draft-chan-problem-statement is PCN End

Node

Personally I don't like the

term PCN End Node - the problem is that it will probably get shortened to

end node (already seen this happening on the list). I think this will get

confusing as [1] the innocent may think it means 'end host'; [2] the

deployment models will probably show how PCN fits into the 'big picture'

of end-to-end QoS, in which case we'd have both end hosts & PCN End

Nodes. 

I also think PCN Gateway

Node (function) could be slightly confusing. The actual physical node

where the "PCN End Node" function sits is typically the PCN-region's

gateway node, but it could in some deployment situations be an end host,

if the PCN-region extends out that far.

PCN Boundary Node would be

consistent with rfc2474

terminology.

PCN Border Node is a

similar possibility that Michael has suggested.

PCN Edge Node allows us to

continue to use the nice acronym PEN, with its hint of 'penning in' the

PCN-region. 

I favour PCN Edge Node, and

also ok with PCN Boundary / Border

Node

 
A4    "Pre-emption Marking term" Issue
Pre-emption Marking may seem to indicate the requirement of pre-empting
existing flows/sessions to allow additional new flows/sessions to be
admitted.  This scenario is not allowed in some markets due to regulations.
Should a better term be used instead of Pre-emption Marking to indicate the
need to reduce the offered traffic load to the congested portions of the
network?
Michael suggested "excess traffic mark" - what do you reckon?
 
Best wishes
phil

---

From: <[email-masked]>
Date: Mon, 2 Oct 2006 15:58:37 +0100

I like "Admissible Rate Marking" & "Admissible Rate" or maybe
"configured-admissible-rate" also seem nice to me. 

I'm not so sure about "Supportable Rate Marking" & "Supportable Rate". 

As well as the "Admissible Rate" there are 2 other rates associated with
a link

-         the rate at which pkts are Pre-emption Marked (to use the
current terminology!)

-          the rate at which pkts are dropped, ie the line rate. 

To me, "Supportable Rate" suggests the latter rather than the former.
Maybe this is just me. Will try and think of something else.

phil

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]] 
Sent: 02 October 2006 15:43
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Issue A4 Preemption Marking Term

How about the terms of:

It is then up to the Policy Decision to take the appropriate action when
the rate of traffic is
not "Supportable" anymore.  With Preemption being one of the possible
policy decision actions.

Thanks!
-- Kwok --

 

 Reference:

 RFC2998 supports use

Personally I don't mind,

 
A2      "PIN Term" Issue

Should we use the

 Reference:

 RFC2475 supports use
of PCN Interior
Node

Personally I slightly

 

A3      "PEN Term"
Issue

Should we use the

 Reference:

 The term currently

Personally I don't like the
term PCN End Node - the problem is that it will probably get shortened
to
end node (already seen this happening on the list). I think this will
get
confusing as [1] the innocent may think it means 'end host'; [2] the
deployment models will probably show how PCN fits into the 'big picture'
of end-to-end QoS, in which case we'd have both end hosts & PCN End
Nodes. 

I also think PCN Gateway

PCN Border Node is a

 

 

Best wishes
phil

---

From: <[email-masked]>
Date: Mon, 2 Oct 2006 16:01:48 +0100

Not sure I like this, as the idea of this (pre-emption) marking is that
action is taken so the link should never be congested. 

Perhaps "severe pre-congestion marking"?

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 02 October 2006 15:52
To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] Issue A4 Preemption Marking Term

Hi Kwock

Best Regards,

Georgios

________________________________

How about the terms of:

Thanks!
-- Kwok --

 

 Reference:

 RFC2998 supports use

Personally I don't mind,

 
A2      "PIN Term" Issue

Should we use the

 Reference:

 RFC2475 supports use
of PCN Interior
Node

Personally I slightly

 

A3      "PEN Term"
Issue

Should we use the

 Reference:

 The term currently

 

I also think PCN Gateway

PCN Border Node is a

 

 

Best wishes
phil

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 02 Oct 2006 11:12:42 -0400

Georgios:
I agree with Phil:  that the use of "servere 
congestion marking" will not be appropriate as Phil indicated.
Lets see if there are more suggestions and let 
all of us to allow some of these ideas to sink in a bit.
-- Kwok --

At 11:01 AM 10/2/2006, [email-masked] wrote:
>Not sure I like this, as the idea of this 
>(pre-emption) marking is that action is taken so 
>the link should never be congested.
>
>Perhaps “severe pre-congestion marking”?
>
>
>----------
>not "Supportable" anymore.  With Preemption 
>being one of the possible policy decision actions.
>
>Thanks!
>-- Kwok --
>
>Thought I’d try to close a
>few more of the Issues – covering the Issues “A. Terminology Issues”
>listed at
>
>
>Personally I don’t mind,
>prefer PCN Interior Node, though I don’t mind much. So happy to stick
>Personally I don’t like the
>term PCN End Node – the problem is that it will probably get shortened to
>confusing as [1] the innocent may think it means ‘end host’; [2] the
>deployment models will probably show how PCN fits into the ‘big picture’
>of end-to-end QoS, in which case we’d have both end hosts & PCN End
>Nodes.
>
>
>
>I also think PCN Gateway
>where the “PCN End Node” function sits is typically the PCN-region’s
>continue to use the nice acronym PEN, with its hint of ‘penning in’ the
>PCN-region.
>
>
>

---

From: Michael Menth <[email-masked]>
Date: Mon, 02 Oct 2006 17:21:05 +0200

Hi,

what do you think about the terms

* admissible link rate and "admission stop marking" using an admission 
stop bit
* tolerable link rate and "excess traffic marking" using an excess 
traffic bit
* supportED link rate (now = physical or virtual link rate used for 
interface traffic shaping (Phil), but I'm not sure whether this 
expression is required at all: maybe just link rate?)

Admission control is a requirement in our context, but preemption is 
just an option when the tolerable link rate is exceeded (I think I read 
that somewhere). Therefore, I don't like the term "preemption marking" 
since this suggests preemption as mandatory. IF preemption is a 
mandatory feature, the term preemption marking is fine.

Regards,

Michael

[email-masked] wrote:
>
> Not sure I like this, as the idea of this (pre-emption) marking is 
> that action is taken so the link should never be congested.
>
> *From:* Georgios Karagiannis [mailto:[email-masked]]
> *Sent:* 02 October 2006 15:52
> *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R
> *Cc:* [email-masked]
> *Subject:* RE: [PCN] Issue A4 Preemption Marking Term
>
> Hi Kwock
>
> ------------------------------------------------------------------------
>
> *From:* Kwok-Ho Chan [mailto:[email-masked]]
> *Sent:* maandag 2 oktober 2006 16:43
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [PCN] Issue A4 Preemption Marking Term
>
> Pre-emption Marking may seem to indicate the requirement of 
> pre-empting existing flows/sessions to allow additional new 
> flows/sessions to be admitted. This scenario is not allowed in some 
> markets due to regulations. Should a better term be used instead of 
> Pre-emption Marking to indicate the need to reduce the offered traffic 
> load to the congested portions of the network?
>
> It is then up to the Policy Decision to take the appropriate action 
> when the rate of traffic is
> _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_
>
>  
>
>  
> Pre-emption Marking may seem to indicate the requirement of 
> pre-empting existing flows/sessions to allow additional new 
> flows/sessions to be admitted. This scenario is not allowed in some 
> markets due to regulations. Should a better term be used instead of 
> Pre-emption Marking to indicate the need to reduce the offered traffic 
> load to the congested portions of the network?
> ------------------------------------------------------------------------
>

-- 
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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 2 Oct 2006 17:30:10 +0200

Hi Kwok 
 
yes I agree with your proposal!
Best regards,
Georgios

  _____  

From: Kwok-Ho Chan [mailto:[email-masked]] 
Sent: maandag 2 oktober 2006 17:13
To: [email-masked]
Cc: [email-masked]; Kwok-Ho Chan; [email-masked]
Subject: RE: [PCN] Issue A4 Preemption Marking Term

Georgios:
I agree with Phil:  that the use of "servere congestion marking" will not be
appropriate as Phil indicated.
Lets see if there are more suggestions and let all of us to allow some of
these ideas to sink in a bit.
-- Kwok --

 

-----Original Message-----
From: Georgios Karagiannis [  <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: 02 October 2006 15:52
To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] Issue A4 Preemption Marking Term
 
Hi Kwock

Best Regards,
Georgios

  _____  

From: Kwok-Ho Chan [  <mailto:[email-masked]> mailto:[email-masked]] 

How about the terms of:

Thanks!
-- Kwok --

Thought I'd try to close

a

few more of the Issues -

covering the Issues "A. Terminology

Issues"

listed

at

 

 

A1      "PCN-Region Term"

Issue

Should the region

running

the PCN mechanism be called

the PCN-Region

or

PCN-Domain?

 Reference:

draft-chan-problem-statement-00.txt

section

2.1.

 RFC2998 supports

use

of Region, RFC2474 supports

use of

Domain.

Personally I don't

mind,

happy to stick with

PCN-region as currently used

in

 

A2      "PIN Term"

Issue

Should we use

the

terminology PCN Interior

Node or PCN Intermediate

Node

(function)?

 Reference:

draft-chan-problem-statement-00.txt

section

2.1.

 RFC2475 supports

use

of PCN

Interior

Node

Personally I

slightly

prefer PCN Interior Node,

though I don't mind much. So happy to

stick

with PCN Interior Node as

currently used

in

 

 

A3      "PEN

Term"

Issue

Should we use

the

terminology PCN End Node or

PCN Edge Node or PCN Boundary Node or

PCN

Border Node or PCN Gateway

Node

(function)?

 Reference:

draft-chan-problem-statement-00.txt

section

2.1.

 The term

currently

used in

draft-chan-problem-statement is PCN

End

Node

Personally I don't like

the

term PCN End Node - the

problem is that it will probably get shortened

to

end node (already seen this

happening on the list). I think this will

get

confusing as [1] the

innocent may think it means 'end host'; [2]

the

deployment models will

probably show how PCN fits into the 'big

picture'

of end-to-end QoS, in which

case we'd have both end hosts & PCN

End

Nodes.

 

I also think PCN

Gateway

Node (function) could be

slightly confusing. The actual physical

node

where the "PCN End Node"

function sits is typically the

PCN-region's

gateway node, but it could

in some deployment situations be an end

host,

if the PCN-region extends

out that

far.

PCN Boundary Node would

be

consistent with

rfc2474

terminology.

PCN Border Node is

a

similar possibility that

Michael has

suggested.

PCN Edge Node allows us

to

continue to use the nice

acronym PEN, with its hint of 'penning in'

the

PCN-region.

 

I favour PCN Edge Node,

and

also ok with PCN Boundary /

Border

Node

 
 
Best wishes
phil

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 2 Oct 2006 12:46:06 -0400

I like what Michael is suggesting with the following minor changes.
"admissible rate" drop the word link because only some of the traffic on
the link is being measured e.g., per service class. 
I'm OK with "admission stop marking" or just "admission marking" meaning
this is when admission of additional flows should be stopped.

For the second level I support using "supportable rate" and for the
marking "excess traffic marking" where the excess traffic is greater
then the configured supportable rate and may or may not be above the
actual link rate. I would expect that normally supportable rate would
loss that link rate and possible less than the forwarding rate of the
queue used. Preemption is an action of removing flows that some solution
may take to get ride of excess traffic and return to provide good QoS to
remaining traffic.

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 11:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Issue A4 Preemption Marking Term

Hi,

Regards,

Michael

to
get

---

From: Michael Menth <[email-masked]>
Date: Mon, 02 Oct 2006 19:05:06 +0200

Hi,

I think that the word "link" in "admissible link rate" indicates that 
the respective rate is link specific in contrast to the 
"border-to-border (b2b)" (received, admission-stop, excess traffic) 
rates (or estimates) that are measured at the egress per b2b aggregate. 
Thus, the "link" within the term avoids misunderstandings with other 
possible scopes (e.g. admissible rate for a specific ingress, admissible 
rate for specific b2b aggregates, ...). Initially, I had a hard time to 
understand the draft since the scope of the rates was not clear to me. 
If we know what we mean, we don't need the "link", but it makes it 
easier for new people to understand the architecture.

Best wishes,

    Michael

Jozef Babiarz wrote:
>> deployment models will probably show how PCN fits into the 'big
>>     
> picture'
>   
>> gateway node, but it could in some deployment situations be an end
>>     
> host,
>   
>> continue to use the nice acronym PEN, with its hint of 'penning in'
>>     
> the
>   
>> PCN-region. 
>>
>>  
>>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 2 Oct 2006 13:21:57 -0400

Phil on issue A3.

We have at least two deployment model that we would like the PCN
mechanism to be feasible in.

One is the "edge-to-edge deployment model as explained in
cl-architecture draft and the second being SIP controlled admission and
preemption which I will send a draft out in few days. 

In the edge-to-edge case decisions are made in network edge nodes which
is the end node for PCN and in the SIP controlled model, the decision is
make in the SIP controlled endpoint which is an application or service
control point. In SIP case the PCN end node is a phone, media gateway,
multi media terminal, boundary gateway, etc. 

To be generic and so that it works for both models, I like PCN End Node.

Regards, Joe 

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 10:10 AM
To: [email-masked]
Subject: [PCN] Issues A1, A2, A3, A4

 
A2      "PIN Term" Issue 

A3      "PEN Term" Issue

 

 

Best wishes

phil

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 2 Oct 2006 16:48:39 -0400

Yes Michael I see your point. I'm OK with "admissible link rate".

Regards, Joe
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 1:05 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Issue A4 Preemption Marking Term

Hi,

Best wishes,

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 4 Oct 2006 09:07:00 +0200

I agree too,

Regards, Rudiger

|I'm OK with "admissible link rate".
|
|Regards, Joe
|QoS & Network Architecture
|Telephone: 613-763-6098 (ESN 393-6098)
|Email: [email-masked]
|-----Original Message-----
|From: Michael Menth [mailto:[email-masked]] 
|Sent: Monday, October 02, 2006 1:05 PM
|To: Babiarz, Jozef (CAR:0S03)
|Cc: [email-masked]; [email-masked]
|Subject: Re: [PCN] Issue A4 Preemption Marking Term
|
|Hi,
|
|I think that the word "link" in "admissible link rate" indicates that 
|the respective rate is link specific in contrast to the 
|"border-to-border (b2b)" (received, admission-stop, excess traffic) 
|rates (or estimates) that are measured at the egress per b2b 
|aggregate. 
|Thus, the "link" within the term avoids misunderstandings with other 
|possible scopes (e.g. admissible rate for a specific ingress, 
|admissible
|
|rate for specific b2b aggregates, ...). Initially, I had a 
|hard time to 
|understand the draft since the scope of the rates was not clear to me. 
|If we know what we mean, we don't need the "link", but it makes it 
|easier for new people to understand the architecture.
|
|Best wishes,
|
|    Michael

---

From: <[email-masked]>
Date: Wed, 4 Oct 2006 08:37:54 +0100

A possibility to solve this is to call it the "PCN Edge Node" and
re-name what's in the cl-architecture draft the "gateway-to-gateway"
deployment model

Any other opinions?

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 02 October 2006 18:22
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Issues A1, A2, A3, A4

Phil on issue A3.

 

Regards, Joe 

 
 
A2      "PIN Term" Issue 

A3      "PEN Term" Issue

 

 

Best wishes

phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 4 Oct 2006 11:07:46 +0200

Hi Phil
 
I agree with Joe, I like PCN End Node.
Furthermore, the term associated with A2, 
in order to also be generic and be able to cover well both models, I like
the term:
PCN Intermediate Node.
 
Best regards,
Georgios

  _____  

From: Jozef Babiarz [mailto:[email-masked]] 
Sent: maandag 2 oktober 2006 19:22
To: [email-masked]; [email-masked]
Subject: RE: [PCN] Issues A1, A2, A3, A4

Phil on issue A3.

We have at least two deployment model that we would like the PCN mechanism
to be feasible in.

One is the "edge-to-edge deployment model as explained in cl-architecture
draft and the second being SIP controlled admission and preemption which I
will send a draft out in few days. 

In the edge-to-edge case decisions are made in network edge nodes which is
the end node for PCN and in the SIP controlled model, the decision is make
in the SIP controlled endpoint which is an application or service control
point. In SIP case the PCN end node is a phone, media gateway, multi media
terminal, boundary gateway, etc. 

Regards, Joe 

  _____  

Thought I'd try to close a few more of the Issues - covering the Issues "A.
Terminology Issues" listed at
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
Personally I don't mind, happy to stick with PCN-region as currently used in
 
A2      "PIN Term" Issue 
Should we use the terminology PCN Interior Node or PCN Intermediate Node
(function)?
 Reference: draft-chan-problem-statement-00.txt section 2.1.
 RFC2475 supports use of PCN Interior Node
Personally I slightly prefer PCN Interior Node, though I don't mind much. So
happy to stick with PCN Interior Node as currently used in
draft-chan-problem-statement

A3      "PEN Term" Issue
Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary
Node or PCN Border Node or PCN Gateway Node (function)?
 Reference: draft-chan-problem-statement-00.txt section 2.1.
 The term currently used in draft-chan-problem-statement is PCN End Node
 
Personally I don't like the term PCN End Node - the problem is that it will
probably get shortened to end node (already seen this happening on the
list). I think this will get confusing as [1] the innocent may think it
means 'end host'; [2] the deployment models will probably show how PCN fits
into the 'big picture' of end-to-end QoS, in which case we'd have both end
hosts & PCN End Nodes. 
 
I also think PCN Gateway Node (function) could be slightly confusing. The
actual physical node where the "PCN End Node" function sits is typically the
PCN-region's gateway node, but it could in some deployment situations be an
end host, if the PCN-region extends out that far. 

PCN Edge Node allows us to continue to use the nice acronym PEN, with its
hint of 'penning in' the PCN-region. 

 

Best wishes

phil

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 13 Oct 2006 12:37:57 -0400

Michael:
I think you bring up a good point.
We will need to make sure the reader can easily know these 
"admissible/supportable rate"
are for each router hop, and not the border-to-border notion.
But the use of the word "link" may not be correct.
This is because we don't want to indicate this rate is the physical link limit.
Or associated with the physical link itself.
We are talking more of the service limit, for example
the scheduler's maximum service rate for the EF queue,

Hence IMHO, we need to make sure the per each router hop notion is clear,
and may want to do so without adding the "link" word to it.
How about giving that a try for the next round?

Thanks!
-- Kwok --

At 01:05 PM 10/2/2006, Michael Menth wrote:
>Hi,
>
>I think that the word "link" in "admissible link rate" indicates 
>that the respective rate is link specific in contrast to the 
>rates (or estimates) that are measured at the egress per b2b 
>aggregate. Thus, the "link" within the term avoids misunderstandings 
>with other possible scopes (e.g. admissible rate for a specific 
>ingress, admissible rate for specific b2b aggregates, ...). 
>Initially, I had a hard time to understand the draft since the scope 
>of the rates was not clear to me. If we know what we mean, we don't 
>need the "link", but it makes it easier for new people to understand 
>the architecture.
>
>Best wishes,
>
>    Michael
>
>Jozef Babiarz wrote:
>>the link is being measured e.g., per service class. I'm OK with 
>>"admission stop marking" or just "admission marking" meaning
>>* admissible link rate and "admission stop marking" using an 
>>admission stop bit
>>Admission control is a requirement in our context, but preemption 
>>is just an option when the tolerable link rate is exceeded (I think 
>>I read that somewhere). Therefore, I don't like the term 
>>"preemption marking" since this suggests preemption as mandatory. 
>>IF preemption is a mandatory feature, the term preemption marking is fine.
>>
>>Regards,
>>
>>Michael
>>
>>>flows/sessions to be admitted. This scenario is not allowed in 
>>>some markets due to regulations. Should a better term be used 
>>>instead of Pre-emption Marking to indicate the need to reduce the 
>>>offered traffic
>>>
>>
>>
>>>"Admissible Rate Marking" for the marking indication of exceeding 
>>>the "Admissible Rate"
>>>and
>>>It is then up to the Policy Decision to take the appropriate 
>>>action when the rate of traffic is
>>>not "Supportable" anymore. With Preemption being one of the 
>>>possible policy decision actions.
>>>
>>>Thanks!
>>>-- Kwok --
>>>
>>>flows/sessions to be admitted. This scenario is not allowed in 
>>>some markets due to regulations. Should a better term be used 
>>>instead of Pre-emption Marking to indicate the need to reduce the 
>>>offered traffic
>>>
>>
>>

---

From: Michael Menth <[email-masked]>
Date: Fri, 13 Oct 2006 18:51:36 +0200

Hi Kwok,

well, I still think it is dangerous if the scope of the rates is missing 
in the terms because there are link- and b2b-specific rates and people 
usually like to jumble them. By clarifying what "admissible/tolerable 
link rate" means, confusion with physical limits can also be excluded. 
Maybe it is better to substitute "link" by "interface"?

Best wishes,

    Michael

Kwok-Ho Chan wrote:
>>> From: Michael Menth [mailto:[email-masked]] Sent: 
>>> Monday, October 02, 2006 11:21 AM
>>> just an option when the tolerable link rate is exceeded (I think I 
>>> read that somewhere). Therefore, I don't like the term "preemption 
>>> marking" since this suggests preemption as mandatory. IF preemption 
>>> is a mandatory feature, the term preemption marking is fine.
>>>
>>> Regards,
>>>
>>> Michael
>>>

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 13 Oct 2006 13:11:34 -0400

Michael:
Thank you for your guidance.
I am still on the fence.
Most likely write both options up and have it reviewed in context.

Thanks!
-- Kwok --

At 12:51 PM 10/13/2006, Michael Menth wrote:
>Hi Kwok,
>
>well, I still think it is dangerous if the scope of the rates is 
>missing in the terms because there are link- and b2b-specific rates 
>and people usually like to jumble them. By clarifying what 
>"admissible/tolerable link rate" means, confusion with physical 
>limits can also be excluded. Maybe it is better to substitute "link" 
>by "interface"?
>
>Best wishes,
>
>    Michael
>
>Kwok-Ho Chan wrote:
>>Michael:
>>>"border-to-border (b2b)" (received, admission-stop, excess 
>>>traffic) rates (or estimates) that are measured at the egress per 
>>>b2b aggregate. Thus, the "link" within the term avoids 
>>>misunderstandings with other possible scopes (e.g. admissible rate 
>>>for a specific ingress, admissible rate for specific b2b 
>>>aggregates, ...). Initially, I had a hard time to understand the 
>>>draft since the scope of the rates was not clear to me. If we know 
>>>what we mean, we don't need the "link", but it makes it easier for 
>>>new people to understand the architecture.
>>>
>>>Best wishes,
>>>
>>>    Michael
>>>
>>>Jozef Babiarz wrote:
>>>>* tolerable link rate and "excess traffic marking" using an 
>>>>excess traffic bit
>>>>* supportED link rate (now = physical or virtual link rate used 
>>>>for interface traffic shaping (Phil), but I'm not sure whether 
>>>>this expression is required at all: maybe just link rate?)
>>>>
>>>>is just an option when the tolerable link rate is exceeded (I 
>>>>think I read that somewhere). Therefore, I don't like the term 
>>>>>Not sure I like this, as the idea of this (pre-emption) marking 
>>>>>is that action is taken so the link should never be congested.
>>>>>
>>>>>instead of Pre-emption Marking to indicate the need to reduce 
>>>>>the offered traffic
>>>>
>>>>
>>>>>"Admissible Rate Marking" for the marking indication of 
>>>>>exceeding the "Admissible Rate"
>>>>>and
>>>>>instead of Pre-emption Marking to indicate the need to reduce 
>>>>>the offered traffic
>>>>
>>>>