Re: [PCN] PCN termination marking algorithm - consensus?
"Georgios Karagiannis" <karagian@cs.utwente.nl> Thu, 28 February 2008 13:30 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 676EE3A6E84; Thu, 28 Feb 2008 05:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, 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 C0s2uVrBCenB; Thu, 28 Feb 2008 05:30:44 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB583A6DEA; Thu, 28 Feb 2008 05:30:44 -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 0E8853A6A40 for <pcn@core3.amsl.com>; Thu, 28 Feb 2008 05:30:43 -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 CHzok1yTiE+s for <pcn@core3.amsl.com>; Thu, 28 Feb 2008 05:30:29 -0800 (PST)
Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id CE2FA3A6964 for <pcn@ietf.org>; Thu, 28 Feb 2008 05:30:28 -0800 (PST)
Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m1SDT4UF000938; Thu, 28 Feb 2008 14:30:19 +0100 (MET)
From: Georgios Karagiannis <karagian@cs.utwente.nl>
To: philip.eardley@bt.com, pcn@ietf.org
References: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net>
Date: Thu, 28 Feb 2008 14:30:13 +0100
Message-ID: <004301c87a0e$0ca2b620$810c5982@dynamic.ewi.utwente.nl>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net>
Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78A==
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:30:21 +0100 (MET)
Subject: Re: [PCN] PCN termination 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="===============1967452027=="
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org
Hi Phil My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. 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. [Lars has commented: do we need to allow this choice?] 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. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) 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', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination 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 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in <http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PC N-MFT.pdf> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in <http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.tx t> http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt%20Fi g%2010.1> http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil
_______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn
- [PCN] PCN termination marking algorithm - consens… philip.eardley
- Re: [PCN] PCN termination marking algorithm - con… Michael Menth
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… philip.eardley
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… Georgios Karagiannis
- Re: [PCN] PCN termination marking algorithm - con… Anna Charny (acharny)
- Re: [PCN] PCN termination marking algorithm - con… philip.eardley