Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 17 Jun 2008 17:38:42 +0800

Hi,

I have some questions to ask after reading your I-D.

1) In a PCN domain, if the two-state node is between two three-states nodes, 
how the marking scheme will be?
   So is it ture if there is a two-state node along the route, that will be 
two-state scheme.
   This is important for a network administrator.
2) In section 2.2.  Classify and condition function
   "There may be traffic that is more important than PCN that shares the
   same capacity as PCN and is priority scheduled over PCN (perhaps an
   operator's control messages).  Such traffic MUST be metered as though
   it were PCN-traffic, but MUST NOT be PCN-marked.  Such packets,
   together with PCN-packets, are called "metered packets"."

   You mentioned the packet which contains an operator's control messages,
so my question is if the marking contexts are sent in control messages,
or PCN-capable nodes at ingress generat control messages when sending marks,
what the pcn will be?
Perhaps the second question is out of the scope of PCN,
but there was some schemes in ATM to send RM cell instead of marking each 
cell.

Regards,

Gengyu

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 09, 2008 6:41 PM
Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00

Rudiger

Thanks for the comments.

I think the slight lack of clarity about the conditioner comes because it's 
an issue we've thought about less than the "core" PCN meter/mark functions, 
and also because trying to leave some implementation openness.

Issue 1:
Yes, the conditioner will include a meter in for it to do its work (I don't 
see this as being "in front of" the conditioner - it's part of it). this is 
different from the PCN meters (at one point you seem to imply the PCN meter 
is the same thing as the conditioner's meter)
Will try & clarify. Will also take another look at some of the Diffserv 
stuff about conditioners, to try and use the same language [I did try to 
already, as this was an earlier comment by joe, but I'll try & make it 
better] & maybe add refs.

Issue 2:
Ok, I see that we're both thinking the same, as this is basically the answer 
I gave to issue 1!

Issue 3a:
I thought it was worth distinguishing the dropping/downgrading of PCN pkts, 
from the dropping/downgrading of other metered pkts (by which I meant, 
metered pkts that are not PCn pkts - these 2 terms are precisely defined)
I'll try & clarify

Issue 3b:
An interesting question. At the moment the doc says that Conditioning is a 
MUST, ie all routers of pcn-domain will have to support it. the doc implies 
that they don't all have to operate with the same choice; I think this is 
reasonable, but some standards language is needed. Inclined to make all the 
conditioning possibilities MAYs (ie dropping pcn pkts, downgrading pcn pkts, 
drop/downgrade metered, non-pcn pkts).

Please shout if you think something different, eg that one possibility is so 
much better that it needs to be a SHOULD.

Issue 4:
Excess-traffic-marked is defined elsewhere. It means marked by an (earlier 
PCN-node's) excess traffic meter /marker function.

This & issue 2 suggest that need to add a terminology section.

It's a deliberate choice that the threshold meter SHOULD NOT meter these 
pkts (ie not meter ones that are already excess-traffic-marked). The reason 
is that otherwise too much traffic is terminated (with some edge 
behaviours). This choice was one of the consensus decisions reached in 
Steven's Questions 1-6.

Issue 5:
Ok

Issue 6:
I think this change would be over-compression, and it's better to use a few 
more words & make it easier to understand.

Thanks!
phil

> -----Original Message-----
> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 09 May 2008 10:28
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
>
> Hi Phil,
>
> thanks for your early draft. The document is short
> and in a good shape. I still have some questions,
> mainly related to the conditioner.
>
> Regards,
>
> Rudiger
>
> -----------Issue 1-------------
>
> 1. Introduction
>
> o  Packet classify and condition -...
> also Figure 1 and a couple of other times in
> the text:
>
> The location of the conditioner and its
> functions to me are not well defined. Two
> main issues:
> - the conditioner drops or downgrades packets
>   above a threshold, so there's some meter in
>   front of it.
> - section 2.4 says
>   "A packet SHOULD NOT be metered (by this
>   excess traffic meter function) in the
>   following two cases:
>
>    o  If the packet is already
>       excess-traffic-marked;
>
>    o  If this PCN-node drops (downgrades) the
>       packet because the link is overloaded."
>
> If the conditioner is in front of the meter,
> then the packet can't be metered if it is
> dropped or downgraded.
>
> Michael published on the sequence of conditioner
> and marker in his "Performance Evaluation of
> PCN-based Flow Admission Control and Termination".
> Condition, then meter seems to be preferrable.
>
> All in all, the aspect of conditioning is rather
> unclear and if the authors don't take any
> position on the sequence meter/condition/mark,
> some argumentation in the document may be helpful.
>
> Unless anything speaks against meter, condition,
> mark, I prefer this sequence.
>
> -----------Issue 2-------------
>
> 2.2.  Classify and condition function
>
>    "If the level of traffic is sufficiently high to
>    overload the PCN behaviour aggregate(s), then
>    traffic MUST be conditioned."
>
> This implies another meter to determine the overload,
> doesn't it? Is the following holding:
>
> classify->overload-meter->condition->
> thresh/excess meter->mark?
>
> This sequence would be allright with me.
>
> -------Issue 3a------------------
>
> same section as issue 2, just continuing
>
> "The three possibilities are:
>
>    o  drop PCN-packets;
>
>    o  downgrade PCN-packets to a lower priority
>       behaviour aggregate, such as best effort or
>       assured forwarding, and perhaps drop lower
>       priority packets;
>
>    o  drop or downgrade other "metered packets".
>                         ^^^^^^
> Please delete "other" as it sounds unprecise and
> contradicts the earlier statement, that these
> packets are more important then PCN traffic.
> May be replaced by adding "in general".
>
> Or is this sequence of possibilities meant as a
> list of handling priorities?
>
> ------Issue 3b: Do all routers of a domain have to
> support this conditioning and do they all have to
> operate with the same choice? The document is
> unclear on that
>
> ---------Issue 4------------------
>
> same section as issue 3, just continuing
>
> "If PCN-packets are dropped (or downgraded) then:
>
>    o  excess-traffic-marked PCN-packets SHOULD be
>        preferentially dropped (downgraded);
>
>    o  PCN-packets that are dropped (downgraded)
>       SHOULD NOT be metered by the Excess traffic
>       Meter."
>
> Please define what is meant by
> "excess-traffic-marked". Do you mean CE marked?
>
> It is probably not harmful if the threshold meter
> counts these packets, but it doesn't make much
> sense either. But I don't ask for a change of
> text on that aspect (if thought useful, then
> generalise the text).
>
> -------Issue 5-----------------
>
> 2.3.  Threshold meter function
>
> ..
> "The meter is a token bucket, which..."
>            ^^
>
> Please replace by "acts like" (also in "2.4
> Excess meter"
>
> ------Issue 6-----------------
>
> 2.5.  Marking function
>
>  "o  if two encoding states are available (one
>      for excess-traffic-marked and one for
>      "not PCN-marked") then:
>
>       *  if the Excess traffic Meter indicates
>          marking, then the packet is
>          excess-traffic-marked;
>
>       *  otherwise the packet's encoding state
>          is not altered."
>
> and the same text earlier for threshold marking.
> Could both be replaced by:
>
>  o  if two encoding states are available (one
>     for Behaviour_mode and one for "not
>     PCN-marked") then:
>
>       *  if the Behaviour_Meter indicates
>          marking, then the packet is
>          Behaviour_marked;
>
>       *  otherwise the packet's encoding state
>          is not altered."
>
> Where the Behaviour is either Excess or Threshold.
>
> Ok, a minor comment, would save a few lines,
> but doesn't necessarily improve readability.
> ------------------------------
>
>
>
> Rüdiger Geib
>
> T-Systems Enterprise Services GmbH
> Systems Integration
> Rüdiger Geib
> Project Unit 6
> Line of Business Networks & Processes
> Deutsche-Telekom-Allee 7, 64295 Darmstadt
> Tel. +49 6151 937-2138
> Fax  +49 6151 937-4591
> Internet: http://www.t-systems.com
>
>
> T-Systems Enterprise Services GmbH
> Aufsichtsrat: René Obermann (Vorsitzender)
> Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Olaf
> Heyden*, Dr. Klaus Hofmann, Katrin Horstmann, Joachim Langmack*, Wilfried
> Peters*, Dr. Stefan Schloter, Dr. Matthias Schuster*, Zvezdana Seeger*,
> Dr. Rolf Werner
> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
> Sitz der Gesellschaft: Frankfurt am Main
> WEEE-Reg.-Nr. DE87523644
> *Geschäftsführer gem. § 35 GmbHG
>
>
>
>

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

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

---

From: <[email-masked]>
Date: Tue, 17 Jun 2008 11:14:08 +0100

Gengyu

Thanks very much for your comments!

1) I think this is covered in Section 2.1 (Scope), which states "The
same choice MUST be used throughout a PCN-domain." - this refers to the
same choice about encoding states in all the PCN links in the domain. 

In your example you have a node with 2 encoding states in the same
domain as nodes with 3 encoding states. Therefore the example breaks the
"MUST" in Section 2.1, ie the domain is misconfigured (and so strictly
speaking it isn't a PCN domain, so we don't need to worry about it).

If you've a suggestion how to clarify this, please let me know. 

2) if I understand you right, you're suggesting that when a link is
pre-congested, it sends a message (instead of marking packets). Yes,
this is a possible approach, but - as you say - it's out of scope of
PCN.

thanks
phil

{ -----Original Message-----
{ From: Wei Gengyu [mailto:[email-masked]]
{ Sent: 17 June 2008 10:39
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
{ 
{ Hi,
{ 
{ I have some questions to ask after reading your I-D.
{ 
{ 1) In a PCN domain, if the two-state node is between two three-states
{ nodes,
{ how the marking scheme will be?
{    So is it ture if there is a two-state node along the route, that
will
{ be
{ two-state scheme.
{    This is important for a network administrator.
{ 2) In section 2.2.  Classify and condition function
{    "There may be traffic that is more important than PCN that shares
the
{    same capacity as PCN and is priority scheduled over PCN (perhaps an
{    operator's control messages).  Such traffic MUST be metered as
though
{    it were PCN-traffic, but MUST NOT be PCN-marked.  Such packets,
{    together with PCN-packets, are called "metered packets"."
{ 
{    You mentioned the packet which contains an operator's control
messages,
{ so my question is if the marking contexts are sent in control
messages,
{ or PCN-capable nodes at ingress generat control messages when sending
{ marks,
{ what the pcn will be?
{ Perhaps the second question is out of the scope of PCN,
{ but there was some schemes in ATM to send RM cell instead of marking
each
{ cell.
{ 
{ Regards,
{ 
{ Gengyu
{ 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn