Re: [PCN] PCN admission marking algorithm - consensus?

[Michael Menth <[e-mail]>]

Hi,

I would like to briefly comment some issues raised along this thread. 
Possibly there were also some misunderstandings.

There was the debate concerning whether the metering and marking 
function has to be done at the head end or tail end of a link. This has 
actually no impact on the obtained markings. Therefore, I do not 
understand why this must be standardized and the configuration must be 
consistent. If we say the location must be the same for all links of a 
domain, this is not enough for inter-operability when vendor A 
implements all function for the head end and vendor B for the tail end 
of a link. Therefore, we should provide either more flexibility or 
specify exactly where to implement the functions.

The question whether packet metering and marking is done before or after 
packet loss occurs has more impact on the correctness of PCN than the 
above aspect. For the case of termination marking see 3.2 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-Eval.pdf
Therefore, standardizing this issue could avoid different behavior of 
different equipment in challenging situations. However, this possibly 
reduces implementation options for vendors.

Regards,

Michael


[e-mail] wrote:
>
> Here are some replies to some comments that Joe sent me (Joe replied 
> to a draft version I sent directly, but all the comments below still 
> apply to the version I sent to list) (hope that’s ok joe).
>
> Thanks
>
> phil
>
> -----Original Message-----
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf 
> Of *[e-mail]
> *Sent:* 27 February 2008 11:02
> *To:* [e-mail]
> *Subject:* [PCN] PCN admission marking algorithm - consensus?
>
> I think we have consensus on the admission marking behaviour. This is 
> a first attempt to capture that in Stds language, is it any use?
>
> If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows:
>  
>    o  Packet classify - decide whether an incoming packet is a PCN-
>       packet or not.  Another PCN WG document will specify encoding,
>       using the DSCP and/or ECN fields.
>  
>    o  PCN-meter - measure the 'amount of PCN-traffic'.  The measurement
>       is made as an aggregate of all PCN-packets, and not per flow.
>  
>    o  PCN-mark - algorithms determine whether to PCN-mark PCN-packets
>       and what packet encoding is used (as specified in another PCN WG
>       document).
>
> These functions are now described in more detail.
>
> Note: The PCN-node MAY implement these three functions on either its 
> ingoing or outgoing interfaces. The same choice MUST be made for every 
> PCN-node in one PCN-domain.
>
> [Joe] Suggest rewording “The same choice MUST be made for every 
> PCN-node in one PCN-domain” to something like “The PCN-domain SHOULD 
> be configured so that all links within the PCN-domain support the PCN 
> function.
>
> The work MUST is to strong. I believe it is OK to have a node that 
> does not support the PCN function as long as other nodes provide the 
> PCN functions, i.e., a node may provide PCN-function on both ingoing 
> and outgoing interfaces to compensate for a node that does not provide 
> PCN function.
>
> My other issue is really a chart issue, if inside the PCN-domain an 
> operator configures his network in such a way that there are links 
> that can not be congested why would he need PCN-function on those links?
>
> [phil] the architecture draft says “However if it's known
>    that an interface cannot become pre-congested then it's not strictly
>    necessary for it to be capable of PCN-marking.  But this must be
>    known even in unusual circumstances, eg after the failure of some
>    links.
>
> I suppose this makes it a SHOULD
>
> Classify function:
>
> If a packet’s ECN/DSCP fields have the value PCN, as defined in 
> [RFC-encoding], then it MUST be classified as a PCN-packet.
>
> If a packet’s ECN/DSCP fields do not have the value PCN, as defined in 
> [RFC-encoding], then it MUST NOT be classified as a PCN-packet.
>
> [Joe] I would suggest that the second line be reword to say that “all 
> other packets are not PCN-packets”.
>
> [PHIL] Actually this needs to be updated, since we may need to take 
> account of [quoting arch draft]:
>
> There may be traffic that is more important than PCN, perhaps a
>       particular application or an operator's control messages.  A PCN-
>       node may dedicate capacity to such traffic or priority schedule it
>       over PCN.  In the latter case its traffic needs to contribute to
>       the PCN meters.
>
> Meter function:
>
> Note: The meter is described as a ‘token bucket with threshold’, 
> however the implementation is not standardised. For example, it could 
> equally well be implemented as a virtual queue (which operates with 
> negative tokens).
>
> A packet classified as a PCN-packet MUST be metered as follows.
>
> [Joe] change MUST to MAY in above as this is only an example.
>
> [phil] disagree. If we make this a MAY it means the PCN standard 
> doesn’t require any particular marking behaviour!!
>
> The interface MUST have:
>
> [1] a configured bit rate, termed PCN-lower-rate
>
> [2] a meter for PCN-packets, which MUST have the following behaviour:
>
> [Joe] The above MUST can be changed to SHOULD.
>
> [phil] MUST seems right to me.
>
> a token bucket, which
>
> 1A tokens are added at the PCN-lower-rate, to a maximum TB.size
>
> 1B tokens are removed equal to the size of the PCN-packet, to a 
> minimum TB.size=0
>
> 2 if TB.fill < TB.threshold, then the meter indicates “admission mark” 
> to the Mark function
>
> [Joe] Need to add that TB.threshold MUST be configured to be less than 
> maximum TB.size and grater than TB.size=0
>
> [phil] ok, although I suppose ‘equal to’ is ok in both cases
>
> Note: Step 1A can be triggered by a packet and so can be done at the 
> same time as Step 1B.
>
> Note: Step 2 can be performed before or after step 1
>
> [Joe] The two notes are not needed.
>
> [phil] they were meant to make it clear that numbering doesn’t imply 
> must be done in this order (which the reader might otherwise assume)?
>
> If TB.fill < size of the PCN-packet, then the meter MAY:
>
> a. leave TB.fill unaltered and indicate “admission mark” to the Mark 
> function
>
> b. set TB.fill = 0 and indicate “admission mark” to the Mark function
>
> c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is, 
> then indicate “admission mark” to the Mark function
>
> Note: Option a is expected to be the simplest to implement.
>
> [Joe] The above points are not needed as “1B” states that minimum TB 
> size=0, it should not go negative.
>
> [phil] note, if the meter does choice a, then TB.fill is unaltered. 
> This needs to stated I think.
>
> Mark function:
>
> If the meter indicates to “admission mark” a PCN-packet, then:
>
> [1] this step is REQUIRED, unless [RFC-encoding] standardises an 
> encoding that allows a PCN-packet to be simultaneously “admission 
> marked” and “termination marked”:
>
> If the PCN-packet’s codepoint is already “termination mark” then it 
> MUST NOT be altered, ie the following step is not performed.
>
> [2] the PCN-packet’s ECN/DSCP fields MUST be set to the codepoint 
> “admission marked”, as defined in [RFC-encoding]
>
> [Joe]Reword the Marking function to as:
>
> The “admission marking” is only applied to unmarked PCN packets.
>
> As note could state that “termination marked” packets MUST NOT be 
> remarked, but I believe it is not needed as there may be networks that 
> only do admission control and not flow termination.
>
> [phil] however, if the encoding chosen allows a pkt to be both ‘adm 
> marked’ & ‘termin marked’ then your check is unnecessary. This is what 
> the text tries to say. However, I don’t think this section should be 
> discussed too much at the moment, as hopefully we reach rapid 
> convergence on the encoding option & then we know better what to write 
> here.
>
> we could also add an example algorithm, such as that in 
> http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt 
> Fig 10.1 
> <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt%20Fig%2010.1> 
> on page 21.
>
> Comments?
>
> phil
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcn
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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