Subject: Re: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour

From: <[email-masked]>
Date: Wed, 10 Dec 2008 11:53:42 -0000

Fortune

Yes, you’re right - the sentences you quote from the marking behaviour draft S2.3 & 2.4 are correct, ie both meters MUST be implemented. However there is no compulsion about having them both ‘turned on’ – the question is which meter determines the pkt marking, if there is only the PCN-marked encoding.

I’m not sure which is better:

“…the deployment MUST choose whether the Threshold meter function or the Excess traffic meter function is activated;”

or

“…the deployment MUST choose whether the Threshold meter function or the Excess traffic meter function triggers a packet to be PCN-marked;” 

personally I think the former leaves it slightly unclear what “activated” means. However I think the latter could be improved, so will think more about this. 

perhaps it could be solved by keeping the existing text but adding some explanatory text to the Appendix on the lines you suggest, with a reference to the two MUSTs in S2.3 & 2.4?

thanks

phil 

-----Original Message-----
From: Fortune HUANG [mailto:[email-masked]] 
Sent: 10 December 2008 08:59
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: ??: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour

Hi Phil,

I think in the scenarios you mentioned, only one of the Threshold meter function and the Excess traffic meter takes effect.

If this understanding is correct, I propose to replace the second note by something like the following:

"In some deployment scenarios there may be only two PCN encoding states available (PCN-marked and not-marked). In such scenarios, the deployment MUST choose which of the Threshold meter function and the Excess traffic meter function to be activated/implemented and the other MUST be deactivated/not-implemented; a consistent choice MUST be made throughout a PCN-domain. "

Besides, I would like to draw people's attention on the following sentences in [draft-ietf-pcn-marking-behaviour]:

S2.3: "A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following."

S2.4: "A PCN-node MUST implement an Excess traffic Meter that has behaviour functionally equivalent to the following."

Best Regards,

Fortune

________________________________

发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2008年12月9日 20:24
收件人: [email-masked]
主题: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour

Prompted by a comment from Fortune, I’ve realised that a small issue needs clarifying in the marking draft. 

The draft has statements like: “PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped;”
The problem is that if the baseline encoding is being used, then NO pkts are ever excess-traffic-marked! – because they are actually PCN-marked. 
 
At the moment, this is the simplest way I can find of making the Standard say what we mean it to say(!) is to add two Notes, one to Section 1.1 Terminology & one to Section 2.5 Marking function:
 
S1.1: Note: excess-traffic-marked means a packet that is marked as a result of the excess traffic meter function; threshold-marked means a packet that is marked as a result of the threshold meter function. [baseline-encoding] defines only two PCN encoding states available (PCN-marked and not-marked); the deployment MUST choose whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked; a consistent choice MUST be made throughout a PCN-domain. 

S2.5: Note: In some deployment scenarios there may be only two PCN encoding states available (PCN-marked and not-marked). In such scenarios, the deployment MUST choose whether the Threshold meter function or the Excess traffic meter function triggers a packet to be PCN-marked; a consistent choice MUST be made throughout a PCN-domain. 
 
It’s a bit repetitive – is there a way of saying this just once?
It would also be possible to add a similar note to the Baseline encoding draft, although initial thought is that this isn’t necessary.

Comments?

Thanks

Phil/ 

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