Re: [PCN] PCN admission marking algorithm - consensus?
<philip.eardley@bt.com> Fri, 29 February 2008 08:21 UTC
Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CC628C4CE; Fri, 29 Feb 2008 00:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.467
X-Spam-Level: *
X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[AWL=-1.797, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.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 BfrzdJzOGxg0; Fri, 29 Feb 2008 00:20:53 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFEC28C476; Fri, 29 Feb 2008 00:20:53 -0800 (PST)
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 4E10728C476 for <pcn@core3.amsl.com>; Fri, 29 Feb 2008 00:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 UTqPNd5a6wai for <pcn@core3.amsl.com>; Fri, 29 Feb 2008 00:20:41 -0800 (PST)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 57D5D28C31B for <pcn@ietf.org>; Fri, 29 Feb 2008 00:20:38 -0800 (PST)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 08:20:31 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 29 Feb 2008 08:20:29 -0000
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34607@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EC@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] PCN admission marking algorithm - consensus?
Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAXygvEA==
From: philip.eardley@bt.com
To: pcn@ietf.org
X-OriginalArrivalTime: 29 Feb 2008 08:20:31.0151 (UTC) FILETIME=[F2CBFBF0:01C87AAB]
Subject: Re: [PCN] PCN admission marking algorithm - consensus?
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/pipermail/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>
Content-Type: multipart/mixed; boundary="===============1908593603=="
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org
Anna has pointed out to me that this email should talk about "PCN threshold marking" rather than "PCN Admission marking". Similarly the other email should be about "PCN excess marking" rather than "PCN termination marking". This reflects what we agreed a couple of ietfs ago & also the phrasing in the architecture draft. Sorry & thanks anna for spotting the mistake phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 27 February 2008 11:02 To: pcn@ietf.org Subject: [PCN] PCN admission marking algorithm - consensus? I think we have consensus on the admission marking behaviour. This is a first attempt to capture that in Stds language, is it any use? If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket with threshold', however the implementation is not standardised. For example, it could equally well be implemented as a virtual queue (which operates with negative tokens). A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, which 1A tokens are added at the PCN-lower-rate, to a maximum TB.size 1B tokens are removed equal to the size of the PCN-packet, to a minimum TB.size=0 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 If TB.fill < size of the PCN-packet, then the meter MAY: a. leave TB.fill unaltered and indicate "admission mark" to the Mark function b. set TB.fill = 0 and indicate "admission mark" to the Mark function c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is, then indicate "admission mark" to the Mark function Note: Option a is expected to be the simplest to implement. Mark function: If the meter indicates to "admission mark" a PCN-packet, then: [1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously "admission marked" and "termination marked": If the PCN-packet's codepoint is already "termination mark" then it MUST NOT be altered, ie the following step is not performed. [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "admission marked", as defined in [RFC-encoding] we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt% 20Fig%2010.1> on page 21. Comments? phil
_______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn
- [PCN] PCN admission marking algorithm - consensus? philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… Lars Eggert
- Re: [PCN] PCN admission marking algorithm - conse… philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… Michael Menth
- Re: [PCN] PCN admission marking algorithm - conse… Georgios Karagiannis
- Re: [PCN] PCN admission marking algorithm - conse… philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… Geib, Ruediger
- Re: [PCN] PCN admission marking algorithm - conse… Michael Menth
- Re: [PCN] PCN admission marking algorithm - conse… philip.eardley
- Re: [PCN] PCN admission marking algorithm - conse… Michael Menth