Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour

From: <[email-masked]>
Date: Wed, 24 Jun 2009 09:22:44 +0100

I've been editing in the various comments on
http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03 

In Section 2.4, both Michael and Ingemar said they found talk of MTU
obscure, so have been working on phrasing this better.

However I also realised another issue - S2.4 says:-

   A PCN-node MUST implement an excess-traffic-meter that has behaviour
   functionally equivalent to the following.

[description of 'base' excess-traffic-meter]

   In addition to the above, ... the meter SHOULD [do] ... packet size
independent marking

What this says, now I read it properly, is that you MUST implement
'base' marking behaviour AND also you SHOULD implement "packet size
independent marking".

Whereas what I think we actually wanted to say was: you MUST implement
some kind of excess-traffic-marking behaviour, either the 'base' marking
behaviour or "packet size independent marking" - the latter is suggested
ie you SHOULD implement "packet size independent marking" and if you do,
then you don't have to implement the 'base' marking behaviour as well. I
checked with michael and toby and this is their understanding as well.

If this isn't your understanding, then please shout now! I'm trying to
get a new version out COP tomorrow Thursday, taking account of all the
comments on -03, including the ietf last call ones. Thanks.

Assuming this is ok, I'm proposing the following wording, which also
gets rid of the obscure talk about MTU.

S2.4 now reads:-

...   A PCN-node MUST implement an excess-traffic-meter. The
excess-traffic-meter SHOULD indicate excess-traffic-marking independent
of packet size ("packet size independent marking") but otherwise MUST
use the "baseline" metering behaviour.
               
The "baseline" excess-traffic-meter has behaviour functionally
equivalent to the following.
 
   The meter acts like a token bucket, which is sized in bits and has a
configured reference rate.  The amount of tokens in the token bucket is
termed Tetm.  Tokens are added at the reference rate (PCN-excess-rate),
to a maximum value BSetm.  Tokens are removed equal to the size in bits
of the metered-packet, to a minimum Tetm=0.  If the token bucket is
empty (Tetm = 0), then the meter indicates to the marking function that
the packet is to be excess-traffic-marked. (Explanation of
abbreviations: T is short for Tokens, BS for bucket size, and etm for
excess-traffic-meter.)
 
"Packet size independent marking" means that the size of the packet does
not influence the decision about whether the meter indicates to the
marking function that the packet is to be excess-traffic-marked.

I also think it best to update Appendix A.2 so that it uses "packet size
independent marking":-

   The following steps are performed when a PCN-packet arrives on a
   link:
 
   o  Tetm = min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); //
      add tokens to token bucket
 
   o  if (packet_mark != excess-traffic-marked) then // do not meter
      packets that are already excess-traffic-marked
 
   o
 
      *  if (Tetm < 0) then packet_mark = excess-traffic-marked; // do
         excess-traffic-marking.  The algorithm ensures this is
         independent of packet size
 
      *  else Tetm = Tetm - packet_size; // remove tokens from token
         bucket if don't mark packet
 
   o  lastUpdate = now // Note: 'now' has the same value as in step 1

Also tweaked Appendix B.6:

   "Packet size independent marking" - excess-traffic-marking that is
independent of packet size - is specified as a SHOULD in Section 2.4.
With the "baseline" excess-traffic-meter behaviour, large packets are
more likely to be excess-traffic-marked than small packets, because
packets are marked if the number of tokens in the packet is smaller than
the packet size. This means that, with some edge behaviours, flows with
large packets are more likely to be terminated than flows with small
packets [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth09]. It can be achieved
by a small modification of the "baseline" excess-traffic-meter: the
number of tokens in the bucket can become negative; if this number is
negative at a packet's arrival, the packet is marked; otherwise, the
amount of tokens equal to the packet size is removed from the bucket. 

"Packet size independent marking" is a 'SHOULD', rather than a 'MUST',
because it may be slightly harder for some equipment to implement, and
the impact of not doing it is undesirable but moderate (sufficient
traffic is terminated, but flows with large packets are more likely to
be terminated).  
 
Thanks, 
phil

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 09:30:10 +0100

Btw, although this looks like a lot of text below, it is only slight
wording changes to improve the clarity - but I thought it easiest to
include paragraphs rather than isolated sentences.

The only substantive issue is the one explained at the start. 

-----Original Message-----
From: Eardley,PL,Philip,CXR9 R 
Sent: 24 June 2009 09:23
To: [email-masked]
Subject: Proposed Mod to draft-pcn-marking-behaviour

 

S2.4 now reads:-

 

 

 

   o

 

 
Thanks, 
phil

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 09:57:41 +0100

I /think/ your new text still says you MUST implement baseline and
SHOULD implement PSIM as well...

Suggested alternative text (though this is remarkably tricky to phrase
clearly!). You also need to put the description of PSIM into the main
body as this is the recommended action...:

A PCN-node MUST implement an excess-traffic-meter. The
excess-traffic-meter MUST be functionally equivalent to one of the
meters described below, "Baseline" or "packet size independent marking",
and SHOULD be the "packet-size independent marking" meter. To be clear,
the "baseline" meter is easier to implement but it also unduly favours
flows with small packets. Hence we recommend the use of the "packet-size
independent marking" meter.

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 24 June 2009 09:23
To: [email-masked]
Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour

 

S2.4 now reads:-

 

 

 

   o

 

 
Thanks, 
phil

---

From: Michael Menth <[email-masked]>
Date: Wed, 24 Jun 2009 11:00:38 +0200

Hi Phil, hi Toby,

I still find the text somewhat hard to read and reformulated it a bit 
without changing its contents. Also the cryptic variables make the text 
hard to read. Moreover, I believe the following version clearly says 
what excess marking is and that it is a must, but PSIM is a preferred 
option but is only a SHOULD.

A PCN-node MUST implement an excess-traffic-meter and marker. This 
algorithm has a reference rate which indicates the PCN packet rate that 
can remain unmarked after passing this function. Various implementations 
are possible.
* A simple implementation uses a token bucket [here we need a reference] 
with bucket size S (bits) and reference rate R (bits/sec). Its current 
fill state is denoted by F (bits). The bucket is continuously filled 
with tokens at rate R, and passing packets remove the amount of tokens 
equal to their size from the current fill state F. If F is smaller than 
the packet size B (F<B), the packet is marked and no tokens are removed 
from the bucket. According to our believes, this is a wide-spread 
implementation. However, it has the drawback that large packets are more 
likely to be marked than small packets which is an undesirable feature 
when information about marked packets is used to identify flows to be 
terminated.
* A simple modification of the above algorithm achieves packet-size 
independent marking (PSIM). The fill state is allowed to become negative 
and packets are marked only if the fill state is negative their arrival 
(F<0). This preferred behavior is only a SHOULD to allow legacy code to 
be used for excess marking.

Regards,

Michael

[email-masked] schrieb:
>
> I’ve been editing in the various comments on 
> However I also realised another issue – S2.4 says:-
>
> [description of ‘base’ excess-traffic-meter]
>
>    In addition to the above, ... the meter SHOULD [do] ... packet size independent marking
>
> ‘base’ marking behaviour AND also you SHOULD implement "packet size 
> independent marking".
>
> some kind of excess-traffic-marking behaviour, either the ‘base’ 
> marking behaviour or "packet size independent marking" – the latter is 
> suggested ie you SHOULD implement "packet size independent marking" 
> and if you do, then you don’t have to implement the ‘base’ marking 
> behaviour as well. I checked with michael and toby and this is their 
> understanding as well.
>
> If this isn’t your understanding, then please shout now! I’m trying to 
> Assuming this is ok, I’m proposing the following wording, which also 
> ...   A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the “baseline” metering behaviour.
>                
> The “baseline” excess-traffic-meter has behaviour functionally equivalent to the following.
>  
>    The meter acts like a token bucket, which is sized in bits and has a configured reference rate.  The amount of tokens in the token bucket is termed Tetm.  Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm.  Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=0.  If the token bucket is empty (Tetm = 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.)
>  
> "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked.
>  
>
> I also think it best to update Appendix A.2 so that it uses "packet 
> size independent marking”:-
>
>    "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the “baseline” excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. This means that, with some edge behaviours, flows with large packets are more likely to be terminated than flows with small packets [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth09]. It can be achieved by a small modification of the “baseline” excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket. 
>
> "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated).  
>  
> Thanks, 
> phil
> ------------------------------------------------------------------------
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> 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: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 13:35:03 +0100

Seems fine to me...

Toby

From: Eardley,PL,Philip,CXR9 R 
Sent: 24 June 2009 12:58
To: Moncaster,T,Toby,CXR9 R; [email-masked]'
Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour

1.	how about this? <<PCN-node MUST implement an
excess-traffic-meter. The excess-traffic-meter SHOULD indicate
excess-traffic-marking independent of packet size ("packet size
independent marking"); if "packet size independent marking" is not
implemented then the excess-traffic-meter MUST use the "baseline"
metering behaviour.>>
2.	ok, so a fuller description of "packet size independent marking"
needs to be in the main body:-

For "packet size independent marking" the excess-traffic-meter has
behaviour functionally equivalent to the following.
 
The meter acts like a token bucket, which is sized in bits and has a
configured reference rate.  The amount of tokens in the token bucket is
termed F_etm.  Tokens are added at the reference rate (PCN-excess-rate),
to a maximum value BS_etm. If the token bucket is negative (F_etm < 0),
then the meter indicates to the marking function that the packet is to
be excess-traffic-marked. If the token bucket is not negative, then
tokens are removed equal to the size in bits of the metered-packet (and
the meter does not indicate to the marking function that the packet is
to be excess-traffic-marked).  (Explanation of abbreviations: F is short
for Fill of the token bucket, BS for bucket size, and etm for
excess-traffic-meter.)

-----Original Message-----
From: Moncaster,T,Toby,CXR9 R 
Sent: 24 June 2009 09:58
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour

Toby

 

S2.4 now reads:-

 

 

 

   o

 

 
Thanks, 
phil

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 12:41:36 +0100

Note that the doc is structured so that normative text is in the main
body, and informative explanations are in the Appendix (your words
include both)

Will alter the abbreviation for the nu,ber of tokens in the bucket from
T to F. Also Toby suggested changing in abbreviations from etm to _etm -
so for instance instead of Tetm it will now say F_etm.

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 24 June 2009 10:01
{ To: Eardley,PL,Philip,CXR9 R; pcn; Moncaster,T,Toby,CXR9 R
{ Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
{ 
{ Hi Phil, hi Toby,
{ 
{ I still find the text somewhat hard to read and reformulated it a bit
{ without changing its contents. Also the cryptic variables make the
text
{ hard to read. Moreover, I believe the following version clearly says
{ what excess marking is and that it is a must, but PSIM is a preferred
{ option but is only a SHOULD.
{ 
{ A PCN-node MUST implement an excess-traffic-meter and marker. This
{ algorithm has a reference rate which indicates the PCN packet rate
that
{ can remain unmarked after passing this function. Various
implementations
{ are possible.
{ * A simple implementation uses a token bucket [here we need a
reference]
{ with bucket size S (bits) and reference rate R (bits/sec). Its current
{ fill state is denoted by F (bits). The bucket is continuously filled
{ with tokens at rate R, and passing packets remove the amount of tokens
{ equal to their size from the current fill state F. If F is smaller
than
{ the packet size B (F<B), the packet is marked and no tokens are
removed
{ from the bucket. According to our believes, this is a wide-spread
{ implementation. However, it has the drawback that large packets are
more
{ likely to be marked than small packets which is an undesirable feature
{ when information about marked packets is used to identify flows to be
{ terminated.
{ * A simple modification of the above algorithm achieves packet-size
{ independent marking (PSIM). The fill state is allowed to become
negative
{ and packets are marked only if the fill state is negative their
arrival
{ (F<0). This preferred behavior is only a SHOULD to allow legacy code
to
{ be used for excess marking.
{ 
{ Regards,
{ 
{ Michael
{ 
{ 
{ [email-masked] schrieb:
{ >
{ > I've been editing in the various comments on
{ > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03
{ >
{ > In Section 2.4, both Michael and Ingemar said they found talk of MTU
{ > obscure, so have been working on phrasing this better.
{ >
{ > However I also realised another issue - S2.4 says:-
{ >
{ >    A PCN-node MUST implement an excess-traffic-meter that has
behaviour
{ >    functionally equivalent to the following.
{ >
{ > [description of 'base' excess-traffic-meter]
{ >
{ >    In addition to the above, ... the meter SHOULD [do] ... packet
size
{ independent marking
{ >
{ > What this says, now I read it properly, is that you MUST implement
{ > 'base' marking behaviour AND also you SHOULD implement "packet size
{ > independent marking".
{ >
{ > Whereas what I think we actually wanted to say was: you MUST
implement
{ > some kind of excess-traffic-marking behaviour, either the 'base'
{ > marking behaviour or "packet size independent marking" - the latter
is
{ > suggested ie you SHOULD implement "packet size independent marking"
{ > and if you do, then you don't have to implement the 'base' marking
{ > behaviour as well. I checked with michael and toby and this is their
{ > understanding as well.
{ >
{ > If this isn't your understanding, then please shout now! I'm trying
to
{ > get a new version out COP tomorrow Thursday, taking account of all
the
{ > comments on -03, including the ietf last call ones. Thanks.
{ >
{ > Assuming this is ok, I'm proposing the following wording, which also
{ > gets rid of the obscure talk about MTU.
{ >
{ > S2.4 now reads:-
{ >
{ > ...   A PCN-node MUST implement an excess-traffic-meter. The excess-
{ traffic-meter SHOULD indicate excess-traffic-marking independent of
packet
{ size ("packet size independent marking") but otherwise MUST use the
{ "baseline" metering behaviour.
{ >
{ > The "baseline" excess-traffic-meter has behaviour functionally
{ equivalent to the following.
{ >
{ >    The meter acts like a token bucket, which is sized in bits and
has a
{ configured reference rate.  The amount of tokens in the token bucket
is
{ termed Tetm.  Tokens are added at the reference rate
(PCN-excess-rate), to
{ a maximum value BSetm.  Tokens are removed equal to the size in bits
of
{ the metered-packet, to a minimum Tetm=0.  If the token bucket is empty
{ (Tetm = 0), then the meter indicates to the marking function that the
{ packet is to be excess-traffic-marked. (Explanation of abbreviations:
T is
{ short for Tokens, BS for bucket size, and etm for
excess-traffic-meter.)
{ >
{ > "Packet size independent marking" means that the size of the packet
does
{ not influence the decision about whether the meter indicates to the
{ marking function that the packet is to be excess-traffic-marked.
{ >
{ >
{ > I also think it best to update Appendix A.2 so that it uses "packet
{ > size independent marking":-
{ >
{ >    The following steps are performed when a PCN-packet arrives on a
{ >    link:
{ >
{ >    o  Tetm = min(BSetm, Tetm + (now - lastUpdate) *
PCN-excess-rate); //
{ >       add tokens to token bucket
{ >
{ >    o  if (packet_mark != excess-traffic-marked) then // do not meter
{ >       packets that are already excess-traffic-marked
{ >
{ >    o
{ >
{ >       *  if (Tetm < 0) then packet_mark = excess-traffic-marked; //
do
{ >          excess-traffic-marking.  The algorithm ensures this is
{ >          independent of packet size
{ >
{ >       *  else Tetm = Tetm - packet_size; // remove tokens from token
{ >          bucket if don't mark packet
{ >
{ >    o  lastUpdate = now // Note: 'now' has the same value as in step
1
{ >
{ > Also tweaked Appendix B.6:
{ >
{ >    "Packet size independent marking" - excess-traffic-marking that
is
{ independent of packet size - is specified as a SHOULD in Section 2.4.
With
{ the "baseline" excess-traffic-meter behaviour, large packets are more
{ likely to be excess-traffic-marked than small packets, because packets
are
{ marked if the number of tokens in the packet is smaller than the
packet
{ size. This means that, with some edge behaviours, flows with large
packets
{ are more likely to be terminated than flows with small packets [I-
{ D.briscoe-tsvwg-byte-pkt-mark] [Menth09]. It can be achieved by a
small
{ modification of the "baseline" excess-traffic-meter: the number of
tokens
{ in the bucket can become negative; if this number is negative at a
{ packet's arrival, the packet is marked; otherwise, the amount of
tokens
{ equal to the packet size is removed from the bucket.
{ >
{ > "Packet size independent marking" is a 'SHOULD', rather than a
'MUST',
{ because it may be slightly harder for some equipment to implement, and
the
{ impact of not doing it is undesirable but moderate (sufficient traffic
is
{ terminated, but flows with large packets are more likely to be
terminated).
{ >
{ > Thanks,
{ > phil
{ >
------------------------------------------------------------------------
{ >
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > 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: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
{ mailto:[email-masked]
{ http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 12:57:55 +0100

-----Original Message-----
From: Moncaster,T,Toby,CXR9 R 
Sent: 24 June 2009 09:58
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour

Toby

 

S2.4 now reads:-

 

 

 

   o

 

 
Thanks, 
phil

---

From: Michael Menth <[email-masked]>
Date: Wed, 24 Jun 2009 17:19:36 +0200

Him

[email-masked] schrieb:
>       independent marking");
indicate packets to be marked by the marker independent of their size.

>    1. if "packet size independent marking" is not implemented then the
>       excess-traffic-meter MUST use the “baseline” metering behaviour.>>
>
I would not term the normal token bucket "baseline" metering behavior 
for two reasons:
1) this sounds like the preferred mechanism
2) the nomenclature clashes with baseline encoding

Regards,

Michael

>    1. ok, so a fuller description of "packet size independent marking"
> For "packet size independent marking" the excess-traffic-meter has behaviour functionally equivalent to the following.
>  
> The meter acts like a token bucket, which is sized in bits and has a configured reference rate.  The amount of tokens in the token bucket is termed F_etm.  Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. If the token bucket is not negative, then tokens are removed equal to the size in bits of the metered-packet (and the meter does not indicate to the marking function that the packet is to be excess-traffic-marked).  (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.)
>  
>  
>
> *From:* Moncaster,T,Toby,CXR9 R
> *Sent:* 24 June 2009 09:58
> *To:* Eardley,PL,Philip,CXR9 R; [email-masked]
> *Subject:* RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour
>
> body as this is the recommended action…:
>
> meters described below, “Baseline” or “packet size independent 
> marking”, and SHOULD be the “packet-size independent marking” meter. 
> To be clear, the “baseline” meter is easier to implement but it also 
> unduly favours flows with small packets. Hence we recommend the use of 
> the “packet-size independent marking” meter.
>
> Toby
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]
> *Sent:* 24 June 2009 09:23
> *To:* [email-masked]
> *Subject:* [PCN] Proposed Mod to draft-pcn-marking-behaviour
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jun 2009 15:34:53 +0200

Hi all 

I think that Michael is right! 
Please rephrase the text accordingly!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: woensdag 24 juni 2009 17:20
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
> 
> Him
> 
> >       excess-traffic-meter MUST use the "baseline" metering 
> > behaviour.>>
> >
> I would not term the normal token bucket "baseline" metering 
> behavior for two reasons:
> > For "packet size independent marking" the 
> excess-traffic-meter has behaviour functionally equivalent to 
> the following.
> >  
> > configured reference rate.  The amount of tokens in the 
> token bucket 
> > is termed F_etm.  Tokens are added at the reference rate 
> > (PCN-excess-rate), to a maximum value BS_etm. If the token 
> bucket is 
> > negative (F_etm < 0), then the meter indicates to the 
> marking function 
> > that the packet is to be excess-traffic-marked. If the 
> token bucket is 
> > not negative, then tokens are removed equal to the size in 
> bits of the 
> > metered-packet (and the meter does not indicate to the marking 
> > function that the packet is to be excess-traffic-marked).  
> > (Explanation of abbreviations: F is short for Fill of the token 
> > bucket, BS for bucket size, and etm for excess-traffic-meter.)
> >  
> >  
> >
> > body as this is the recommended action.:
> >
> > meters described below, "Baseline" or "packet size independent 
> > marking", and SHOULD be the "packet-size independent marking" meter.
> > To be clear, the "baseline" meter is easier to implement 
> but it also 
> > the "packet-size independent marking" meter.
> >
> > Toby
> >
> > some kind of excess-traffic-marking behaviour, either the 'base'
> > marking behaviour or "packet size independent marking" - 
> the latter is 
> > and if you do, then you don't have to implement the 'base' marking 
> > ...   A PCN-node MUST implement an excess-traffic-meter. 
> The excess-traffic-meter SHOULD indicate 
> excess-traffic-marking independent of packet size ("packet 
> size independent marking") but otherwise MUST use the 
> "baseline" metering behaviour.
> >                
> > The "baseline" excess-traffic-meter has behaviour 
> >    The meter acts like a token bucket, which is sized in 
> bits and has 
> > a configured reference rate.  The amount of tokens in the 
> token bucket 
> > is termed Tetm.  Tokens are added at the reference rate 
> > (PCN-excess-rate), to a maximum value BSetm.  Tokens are 
> removed equal 
> > to the size in bits of the metered-packet, to a minimum Tetm=0.  If 
> > the token bucket is empty (Tetm = 0), then the meter 
> indicates to the 
> > (Explanation of abbreviations: T is short for Tokens, BS for bucket 
> > size, and etm for excess-traffic-meter.)
> >  
> > "Packet size independent marking" means that the size of 
> the packet does not influence the decision about whether the 
> meter indicates to the marking function that the packet is to 
> be excess-traffic-marked.
> >  
> >
> > size independent marking":-
> >
> >    "Packet size independent marking" - 
> excess-traffic-marking that is independent of packet size - 
> is specified as a SHOULD in Section 2.4. With the "baseline" 
> excess-traffic-meter behaviour, large packets are more likely 
> to be excess-traffic-marked than small packets, because 
> packets are marked if the number of tokens in the packet is 
> smaller than the packet size. This means that, with some edge 
> behaviours, flows with large packets are more likely to be 
> terminated than flows with small packets 
> [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth09]. It can be 
> achieved by a small modification of the "baseline" 
> excess-traffic-meter: the number of tokens in the bucket can 
> become negative; if this number is negative at a packet's 
> arrival, the packet is marked; otherwise, the amount of 
> tokens equal to the packet size is removed from the bucket. 
> >
> > "Packet size independent marking" is a 'SHOULD', rather 
> than a 'MUST', because it may be slightly harder for some 
> equipment to implement, and the impact of not doing it is 
> undesirable but moderate (sufficient traffic is terminated, 
> but flows with large packets are more likely to be terminated).  
> >  
> > Thanks,
> > phil
> > 
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206