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

[Michael Menth <[e-mail]>]

Hi,


[e-mail] wrote:
>   
>> -----Original Message-----
>> From: Michael Menth [mailto:[e-mail]]
>> Sent: 05 March 2008 13:17
>> To: Eardley,PL,Philip,CXR9 R; pcn
>> Subject: Re: [PCN] PCN admission marking algorithm - consensus?
>>
>> 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.
>>     
>
> Yes, I think this is sensible. Does anyone have preferences (Joe has
> said he prefers the former)
>   
As far as I can remember the discussion was the following. If a 
processor cannot have several meters and markers per outgoing links, 
which may be implementation-specific, the marking functionality for 
admission may be implemented on the outgoing link and for termination on 
incoming links. It can also be done vice-versa. It was discussed as an 
implementation issue allowing more flexibility depending on existing code.

Regards,

    Michael

>   
>> 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
>>     
>
> I think I remember from 'corridor' discussions at last ietf that the
> router needs to ensure that it first drops pkts (if necessary) and then
> marks them. Then everything works as expected. If I got this right, then
> this seems a good thing to add. 
> Thanks
> phil
>
>   
>> 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
>>     

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