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

Michael Menth <menth@informatik.uni-wuerzburg.de> Wed, 24 June 2009 18:03 UTC

Return-Path: <menth@informatik.uni-wuerzburg.de>
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8843A6BE3 for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 11:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.306
X-Spam-Level:
X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0xR0v17El9q for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 11:03:23 -0700 (PDT)
Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id B585F3A6819 for <pcn@ietf.org>; Wed, 24 Jun 2009 11:03:22 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C6A341990E2; Wed, 24 Jun 2009 17:19:35 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B8B27199138; Wed, 24 Jun 2009 17:19:35 +0200 (CEST)
Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9451F1990DF; Wed, 24 Jun 2009 17:19:35 +0200 (CEST)
Message-ID: <4A424408.3040001@informatik.uni-wuerzburg.de>
Date: Wed, 24 Jun 2009 17:19:36 +0200
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: philip.eardley@bt.com
References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Cc: pcn@ietf.org
Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2009 18:03:24 -0000

Him

philip.eardley@bt.com 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; pcn@ietf.org
> *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:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On Behalf 
> Of *philip.eardley@bt.com
> *Sent:* 24 June 2009 09:23
> *To:* pcn@ietf.org
> *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
> PCN@ietf.org
> 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:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn