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

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 9 May 2008 11:28:25 +0200

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

---

From: <[email-masked]>
Date: Fri, 9 May 2008 11:41:00 +0100

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