Subject: [PCN] Open issue with PCN marking behaviour draft

From: <[email-masked]>
Date: Wed, 30 Jul 2008 15:17:47 +0100

Hi,
an issue that some of us have been discussing in 'corridor' meetings here in Dublin. It would be good to have wider input, especially from others who might implement PCN in routers etc or operate it in networks (cores, enterprise, whatever). and perhaps from people who've had similar issue in other standards?
I'll also raise this in the PCN WG on Thursday morning, but wanted to alert you now & also seek input from those not in Dublin. 
 
In Philadelphia we decided on the threshold marking and excess marking behaviours. We decided both of these were MUSTs.
So, if in your network you have three encoding states available (Not PCN-marked; threshold-marking; excess-rate-marking) then it is obvious what this means in terms of what each PCN-interior-node does.
 
However, the real question comes in a network with two encoding states (Not PCN-marked; PCN-marked), where the PCN-markings may be driven by the output of either the threshold-meter or the excess-traffic-meter (depending on the operator's requirements etc).
 
The way that draft-eardley-pcn-marking-behaviour-01 is written, in this circumstance with two encoding states, the PCN-interior-node MUST actually run both threshold-meter and excess-traffic-meter (even though the results of only one of the meters is actually used). It doesn't seem a good idea to require both to be actually done - it consumes active resources on routers without benefit. This implication has probably got into the draft due to my poor writing (or my poor interpretation of the WG decision).
 
What the WG probably meant was: both the threshold-meter and excess-rate-meter MUST be *implemented*. However, if in a particular scenario only the results of one meter are used to make pkt marking decisions, then the other meter doesn't have to be *running*. 
The main advantage of making it mandatory to implement both meters is that it makes migration easier. For example migration from having two encoding states available to having three encoding states available - you know that your routers will already have the required capability. Also, when buying new routers and adding them to a network with routers (perhaps from another vendor), backwards compatibility issues are eased. Another example would be if a network still only has two encoding states but wants to move from using "single marking" (which uses excess-rate-metering) to doing admission control driven by the threshold-marking (perhaps using some other mechanism for flow termination), ie it simply re-configures which meter is turned on (no need to buy new routers).
Effectively making both MUSTs means there's one type of PCN-interior-node. WHereas if they're not mandatory to implement (see proposal at the end) then there are effectively three possible types of PCN-interior-node (threshold-meter; excess-traffic-meter; both meters).
 
However, making it MUSTs to implement both types of meter has a cost. For example:
- it makes the implementation requirements bigger. eg for vendors who believe their current equipment can already (or very easily) support excess-traffc-marking, but it would require some effort to add support for threshold-marking
- similarly, it toughens the requirements (or at least the initial requirements) for someone wanting to experiment with PCN where there's only two encoding states. Although interestingly when Joe and Anna talked about "their" initial experiements, one would use threshold-marking only and one excess-traffic-marking only!

The question is whether it would be better to remove the requirement that both meters MUST be implemented. Instead it would say something like:
- If a PCN-interior-node does threshold-marking then it MUST have a meter with behaviour that is functionally equivalent to the following [insert current S2.4]
- If a PCN-interior-node does excess traffic-marking then it MUST have a meter with behaviour that is functionally equivalent to the following [insert current S2.5]
 
We discussed this amongst a few of us (Joe, Anna, Bob) and there seemed tentative feeling that this change is sensible. 
 
Comments appreciated,
thanks!
phil
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jul 2008 16:18:42 +0100

I'm speaking for myself here, but it seems to me for the reasons you mentioned, 
the right thing is to require implementation of both. Otherwise network 
evolution becomes really messy.

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Jul 2008 18:07:37 +0200

Hi,

I think this question boils down to what PCN compliance as a marketing 
label means.

 From my perspective excess marking should be a MUST, otherwise flow 
termination cannot be implemented which is an important part of PCN. If 
it is enough to support aggregates with large aggregations, then excess 
marking suffices and SM works fine. If scenarios with small aggregates 
should be supported, then also threshold marking is a MUST, otherwise it 
can be a SHOULD.

I think that AC itself is especially attractive for low aggregation 
since for high aggregation overprovisioning can be done. Therefore, I am 
rather in favor of two "MUSTs"; otherwise it will possibly rather hard 
to find equipment for PCN-based AC in the low aggregation range. This is 
my academic view which does not include economic calculations of vendors 
or visions of operations what they want to use PCN for. The last 
question is probably most important: what do you want to use PCN for? If 
you cannot answer it yet, it's safer to have two MUSTs.

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