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

<toby.moncaster@bt.com> Wed, 24 June 2009 08:57 UTC

Return-Path: <toby.moncaster@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 0EA9C28C474 for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 01:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 Tq2ObyQ36ClF for <pcn@core3.amsl.com>; Wed, 24 Jun 2009 01:57:29 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1386E28C470 for <pcn@ietf.org>; Wed, 24 Jun 2009 01:57:28 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 09:57:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4A9.D673BED8"
Date: Wed, 24 Jun 2009 09:57:41 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70BEB8A48@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour
Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8QAA17Rw
References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net>
From: toby.moncaster@bt.com
To: philip.eardley@bt.com, pcn@ietf.org
X-OriginalArrivalTime: 24 Jun 2009 08:57:44.0585 (UTC) FILETIME=[D6B8B790:01C9F4A9]
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 08:57:38 -0000

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