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

["Georgios Karagiannis" <[e-mail]>]

Hi all 

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

Best regards,
Georgios
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Michael Menth
> Sent: woensdag 24 juni 2009 17:20
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
> 
> Him
> 
> [e-mail] schrieb:
> >
> >    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");
> >
> 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"
> >       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; [e-mail]
> > *Subject:* RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour
> >
> > 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:* [e-mail] [mailto:[e-mail]] 
> *On Behalf 
> > Of *[e-mail]
> > *Sent:* 24 June 2009 09:23
> > *To:* [e-mail]
> > *Subject:* [PCN] Proposed Mod to draft-pcn-marking-behaviour
> >
> > 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
> > [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] (new), 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
>