Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
<philip.eardley@bt.com> Wed, 24 June 2009 13:26 UTC
Return-Path: <philip.eardley@bt.com>
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 3C7B33A6C71 for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 06:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
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 31wKvaNvRRZi for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 06:26:04 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 633813A6B14 for <pcn@ietf.org>; Wed, 24 Jun 2009 06:26:04 -0700 (PDT)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 12:41:37 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Jun 2009 12:41:36 +0100
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0A@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <4A41EB36.5010003@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour
Thread-Index: Acn0qkEMbr4krEH0Q2OzbPDuiLj5aAAFgJig
From: philip.eardley@bt.com
To: menth@informatik.uni-wuerzburg.de, pcn@ietf.org, toby.moncaster@bt.com
X-OriginalArrivalTime: 24 Jun 2009 11:41:37.0055 (UTC) FILETIME=[BB5492F0:01C9F4C0]
Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 13:26:10 -0000
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:menth@informatik.uni-wuerzburg.de] { 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 { { { philip.eardley@bt.com 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 { > 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
- [PCN] Proposed Mod to draft-pcn-marking-behaviour philip.eardley
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… philip.eardley
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… toby.moncaster
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… Michael Menth
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… toby.moncaster
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… philip.eardley
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… philip.eardley
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… Michael Menth
- Re: [PCN] Proposed Mod to draft-pcn-marking-behav… Georgios Karagiannis