From slblake@petri-meat.com Sun Feb 8 20:52:11 2009 Return-Path: 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 55CB83A699A for ; Sun, 8 Feb 2009 20:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_05=-1.11] 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 JJCromH8BTlk for ; Sun, 8 Feb 2009 20:52:10 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id A54493A6987 for ; Sun, 8 Feb 2009 20:52:10 -0800 (PST) Received: from cpe-066-057-118-226.nc.res.rr.com ([66.57.118.226]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1LWO7s-0004mg-3C for pcn@ietf.org; Sun, 08 Feb 2009 23:52:08 -0500 From: Steven Blake To: pcn Content-Type: text/plain Date: Sun, 08 Feb 2009 23:52:12 -0500 Message-Id: <1234155132.2998.14.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 (2.24.3-1.fc10) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] IETF 74 is coming X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:52:11 -0000 IETF 74 is fast approaching. Here are the I-D submission deadlines: -00 drafts March 2 all I-Ds March 9 I would like to see new revisions of the marking behavior and baseline encoding drafts, and well as drafts on our other pending work. Unfortunately, I will not make it to San Francisco; Scott will be there however. Regards, // Steve From philip.eardley@bt.com Mon Feb 9 09:01:50 2009 Return-Path: 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 151CD3A6A6A for ; Mon, 9 Feb 2009 09:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, 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 5nuEhas9on76 for ; Mon, 9 Feb 2009 09:01:49 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 0466E3A6986 for ; Mon, 9 Feb 2009 09:01:48 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 15:33:40 +0000 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: Mon, 9 Feb 2009 15:33:37 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7939@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1234155132.2998.14.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] IETF 74 is coming Thread-Index: AcmKcjHHI2uh9lUeQA2+GvsKNBUoLAANgpzg From: To: , X-OriginalArrivalTime: 09 Feb 2009 15:33:40.0739 (UTC) FILETIME=[C8B9E530:01C98ACB] Subject: Re: [PCN] IETF 74 is coming X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:01:50 -0000 The status of the marking behaviour draft is, I think that it's complete - except that one technical proposal needs to be considered & lars wanted to wait for the architecture draft before any WG last call.=20 Ie It had consensus until Daisuke's email of 21st Jan with some proposed changes. I haven't yet studied this in detail, as Daisuke said he was working on a draft with simulations showing the performance of his proposals - I was intending to wait for this. Daisuke, perhaps you have an idea when this evaluation draft might be ready? If it's say this week, then I'll wait for it - but if it isnt until near the draft deadline then I'll try & just read your suggestions. Do yo have an idea of timescle please Daisuke? If there are any other comments on this doc, please shout! Thanks phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Steven Blake { Sent: 09 February 2009 04:52 { To: pcn { Subject: [PCN] IETF 74 is coming {=20 { IETF 74 is fast approaching. Here are the I-D submission deadlines: {=20 { -00 drafts March 2 { all I-Ds March 9 {=20 { I would like to see new revisions of the marking behavior and baseline { encoding drafts, and well as drafts on our other pending work. {=20 { Unfortunately, I will not make it to San Francisco; Scott will be there { however. {=20 {=20 { Regards, {=20 { // Steve {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Tue Feb 10 01:50:02 2009 Return-Path: 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 DC19028C192 for ; Tue, 10 Feb 2009 01:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Q05VGnhWP+xm for ; Tue, 10 Feb 2009 01:50:02 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id AEFDC28C185 for ; Tue, 10 Feb 2009 01:50:01 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Feb 2009 09:50:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2009 09:48:24 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] IETF 74 is coming Thread-Index: AcmKcjHUcZG9NG5AT5eIaD23Zp6+3wA8oWYA References: <1234155132.2998.14.camel@tachyon> From: To: , X-OriginalArrivalTime: 10 Feb 2009 09:50:03.0688 (UTC) FILETIME=[F26B5280:01C98B64] Subject: Re: [PCN] IETF 74 is coming X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:50:03 -0000 I am hoping to be able to get a revised baseline encoding draft out = later today. No major changes, mainly tidying up and cutting some = appendixes in light of comments and feedback during and since last IETF. =20 Toby ________________________________ From: pcn-bounces@ietf.org on behalf of Steven Blake Sent: Mon 2/9/2009 04:52 To: pcn Subject: [PCN] IETF 74 is coming IETF 74 is fast approaching. Here are the I-D submission deadlines: -00 drafts March 2 all I-Ds March 9 I would like to see new revisions of the marking behavior and baseline encoding drafts, and well as drafts on our other pending work. Unfortunately, I will not make it to San Francisco; Scott will be there however. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Tue Feb 10 02:16:21 2009 Return-Path: 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 94C6D28C1A1 for ; Tue, 10 Feb 2009 02:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 h9C0cdrp5ytZ for ; Tue, 10 Feb 2009 02:16:20 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A256828C1A0 for ; Tue, 10 Feb 2009 02:16:20 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6F6D219914A for ; Tue, 10 Feb 2009 11:16:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 62DD6199142 for ; Tue, 10 Feb 2009 11:16:22 +0100 (CET) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 50025199141 for ; Tue, 10 Feb 2009 11:16:22 +0100 (CET) Message-ID: <499153FA.6020805@informatik.uni-wuerzburg.de> Date: Tue, 10 Feb 2009 11:16:26 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] multipath routing 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 10:16:21 -0000 Hi all, the current PCN architecture does not support multipath routing, i.e. flows of a single ingress-egress-aggregate can be transmitted over different paths. With some modifications this support could be possible. Is multipath support a desired feature in the future? Or is it of no interest since PCN is intended to be used only in single-path routing networks or in combination with MPLS? Is multipath routing an issue at all in operational networks? Input from practitioners is highly appreciated. Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From Ruediger.Geib@telekom.de Tue Feb 10 02:40:54 2009 Return-Path: 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 0C94F3A67ED for ; Tue, 10 Feb 2009 02:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 010EduNCvUDb for ; Tue, 10 Feb 2009 02:40:53 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id BB31C3A6A47 for ; Tue, 10 Feb 2009 02:40:52 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 10 Feb 2009 11:40:53 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 11:40:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2009 11:40:50 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A56DD407@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <499153FA.6020805@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] multipath routing thread-index: AcmLaKgVfjr0WSVGTs6OlpnEg+RCKAAAf2hw References: <499153FA.6020805@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 10 Feb 2009 10:40:52.0687 (UTC) FILETIME=[0BC3A5F0:01C98B6C] Cc: pcn@ietf.org Subject: Re: [PCN] multipath routing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 10:40:54 -0000 Hi Michael, Equal Cost Multipath (ECMP) routing is a feature applied by my company = to=20 distribute the load more even on core network links. Should PCN ever be=20 deployed in our network, ECMP friendliness is a requirement.=20 MPLS friendliness is another, and over all strict DiffServ conformance=20 is to be respected. From my point of view. Regards, Rudiger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 Ruediger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Michael Menth Sent: Tuesday, February 10, 2009 11:16 AM To: pcn@ietf.org Subject: [PCN] multipath routing Hi all, the current PCN architecture does not support multipath routing, i.e.=20 flows of a single ingress-egress-aggregate can be transmitted over=20 different paths. With some modifications this support could be possible. Is multipath support a desired feature in the future? Or is it of no=20 interest since PCN is intended to be used only in single-path routing=20 networks or in combination with MPLS? Is multipath routing an issue at all in operational networks? Input from = practitioners is highly appreciated. Regards, Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From root@core3.amsl.com Tue Feb 10 03:00:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C52283A6801; Tue, 10 Feb 2009 03:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210110001.C52283A6801@core3.amsl.com> Date: Tue, 10 Feb 2009 03:00:01 -0800 (PST) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-02.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 11:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Baseline Encoding and Transport of Pre-Congestion Information Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-baseline-encoding-02.txt Pages : 11 Date : 2009-02-10 Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-baseline-encoding-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-10024521.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Feb 10 07:00:50 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E801528C161; Tue, 10 Feb 2009 07:00:50 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090210150050.E801528C161@core3.amsl.com> Date: Tue, 10 Feb 2009 07:00:50 -0800 (PST) Cc: pcn@ietf.org Subject: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:00:51 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Pre-Congestion Notification (PCN) Architecture ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16386&rfc_flag=0 From daisuke.satoh@ntt-at.co.jp Tue Feb 10 07:24:08 2009 Return-Path: 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 0388C3A682E for ; Tue, 10 Feb 2009 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.658 X-Spam-Level: * X-Spam-Status: No, score=1.658 tagged_above=-999 required=5 tests=[AWL=1.748, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 VnYJKo9zMIDI for ; Tue, 10 Feb 2009 07:24:07 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id B6C1D3A681C for ; Tue, 10 Feb 2009 07:24:06 -0800 (PST) Received: (qmail 26184 invoked by alias); 10 Feb 2009 15:24:09 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 10 Feb 2009 15:24:09 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n1AFO7j1002216 for ; Wed, 11 Feb 2009 00:24:07 +0900 Received: from gwall2.bb.ntt-at.co.jp (gwall2.bb.ntt-at.co.jp [192.168.5.202]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n1AFO8nN037694 for ; Wed, 11 Feb 2009 00:24:08 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id n1AFO3lx007977 for pcn@ietf.org; Wed, 11 Feb 2009 00:24:03 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall2.bb.ntt-at.co.jp with ESMTP id AAA07976; Wed, 11 Feb 2009 00:24:03 +0900 Received: from [192.168.21.66] (ip21-066.tec.ntt-at.co.jp [192.168.21.66]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 5B02253F61; Wed, 11 Feb 2009 00:24:03 +0900 (JST) Date: Wed, 11 Feb 2009 00:23:50 +0900 From: SATOH Daisuke To: pcn@ietf.org In-Reply-To: References: Message-Id: <20090210174821.BBEC.26AD349@ntt-at.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] Subject: Re: [PCN] PCN Digest, Vol 31, Issue 1 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:24:08 -0000 Dear Phil, Most simulation by NS2 finished, However, caluculating does not finish. I have not yet revised my draft. Could you wait until 23rd Feb? The abstract result of simulation is as follows. 1. Admission control I have time to choose an apropriate parameters: CLE threshold and EWMA weight of CLE although I have no time to choose them in November. The result is almost the same as CL. CL is superior to our algorithm in most cases but not all. The difference is small. 2. Synchronization The effect of synchronization to our algorithm is very small. Marking period of the excess traffic marking is short (if a packet is marked, all of the packets in the flow included in the packet are marked.), synchronization is not avoidable without traffic random. However, the marking period of our modified threshold marking is very long. Only when the amount of the token bucket for marking switch is less than the threshold and one-Nth the events: the amount of the token bucket for marking is the bit of one packet less than the token bucket size (marking candidate) occurs, a packet is marked. So, if a packet is marked, not all of the packets in the flow included in the packet are marked. Therefore, marking ratios among IEA becomes relatively same because a flow whose packets are all marked is very rare. Almost the same performance results between with and without traffic random support the description above. 3. Accuracy of Termination I modified termination. The most different point is that the egress always measure the receiving rate. We evaluate termination when the supportable rate is 40% of the link speed. The load is 1.25x and 2x supportable rate. When the load is 1.25x, our algorithm is almost the same as CL. Our algorithm is superior to CL in some cases and inferior to CL in others. When the load is 2.0x, our algorithm shows good performance. 4.Termination speed We are caluculating the data. So wait a while, please. Best regards, Daisuke > Date: Sun, 08 Feb 2009 23:52:12 -0500 > From: Steven Blake > Subject: [PCN] IETF 74 is coming > To: pcn > Message-ID: <1234155132.2998.14.camel@tachyon> > Content-Type: text/plain > > IETF 74 is fast approaching. Here are the I-D submission deadlines: > > -00 drafts March 2 > all I-Ds March 9 > > I would like to see new revisions of the marking behavior and baseline > encoding drafts, and well as drafts on our other pending work. > > Unfortunately, I will not make it to San Francisco; Scott will be there > however. > > > Regards, > > // Steve > > > > ------------------------------ > > Message: 2 > Date: Mon, 9 Feb 2009 15:33:37 -0000 > From: > Subject: Re: [PCN] IETF 74 is coming > To: , > Message-ID: > <4A916DBC72536E419A0BD955EDECEDEC04AD7939@E03MVB1-UKBR.domain1.systemhost.net> > > Content-Type: text/plain; charset="us-ascii" > > The status of the marking behaviour draft is, I think that it's complete > - except that one technical proposal needs to be considered & lars > wanted to wait for the architecture draft before any WG last call. > > Ie It had consensus until Daisuke's email of 21st Jan with some proposed > changes. I haven't yet studied this in detail, as Daisuke said he was > working on a draft with simulations showing the performance of his > proposals - I was intending to wait for this. Daisuke, perhaps you have > an idea when this evaluation draft might be ready? If it's say this > week, then I'll wait for it - but if it isnt until near the draft > deadline then I'll try & just read your suggestions. Do yo have an idea > of timescle please Daisuke? > > If there are any other comments on this doc, please shout! > > Thanks > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { Steven Blake > { Sent: 09 February 2009 04:52 > { To: pcn > { Subject: [PCN] IETF 74 is coming > { > { IETF 74 is fast approaching. Here are the I-D submission deadlines: > { > { -00 drafts March 2 > { all I-Ds March 9 > { > { I would like to see new revisions of the marking behavior and baseline > { encoding drafts, and well as drafts on our other pending work. > { > { Unfortunately, I will not make it to San Francisco; Scott will be > there > { however. > { > { > { Regards, > { > { // Steve > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > > > ------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > > End of PCN Digest, Vol 31, Issue 1 > ********************************** -- NTTアドバンステクノロジ（株）　ネットワークテクノロジセンタ 佐藤　大輔　(Daisuke SATOH, Ph.D.) tel:0422-36-7502 fax:0422-36-7591 mailto: daisuke.satoh@ntt-at.co.jp ※2008.7.7より電話番号、Fax番号が変更になりました。 From menth@informatik.uni-wuerzburg.de Tue Feb 10 12:05:52 2009 Return-Path: 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 2F5C83A6908 for ; Tue, 10 Feb 2009 12:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 GLMS+0KZjVCy for ; Tue, 10 Feb 2009 12:05:51 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 1B2103A67A4 for ; Tue, 10 Feb 2009 12:05:50 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id AE1A9A0765 for ; Tue, 10 Feb 2009 21:05:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A23BDA0764 for ; Tue, 10 Feb 2009 21:05:53 +0100 (CET) Received: from [92.229.218.66] (g229218066.adsl.alicedsl.de [92.229.218.66]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 75511199062 for ; Tue, 10 Feb 2009 21:05:53 +0100 (CET) Message-ID: <4991DE20.2000606@informatik.uni-wuerzburg.de> Date: Tue, 10 Feb 2009 21:05:52 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: pcn@ietf.org References: <49820386.9080008@rogers.com> <49822BA9.9090702@informatik.uni-wuerzburg.de> <4990F910.8090600@rogers.com> <49913FCA.5000901@informatik.uni-wuerzburg.de> <49917E36.9070302@rogers.com> In-Reply-To: <49917E36.9070302@rogers.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] Why is CL useful if SM works? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 20:05:52 -0000 Hi all, SM and CL were agreed to be both interesting to have as PCN mechanism at the meeting in Philadelphia. I am not so sure about the benefit of CL. SM is good enough for networks with large aggregates and single-path routing. CL does not a particular better job in these cases although it requires two DSCPs for signalling which is almost a show stopper. Therefore, I fear that CL in the form as discussed so far is not useful. When we have SM working, only another mechanism can be of interest that copes with multipath routing and small ingress-egress-aggregates (not necessarily small link aggregation). And if possible, waste of codepoints should be avoided. Comments? Please give feedback, have I overlooked something? Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From fqhuang@huawei.com Tue Feb 10 19:04:26 2009 Return-Path: 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 AC4D43A69C7; Tue, 10 Feb 2009 19:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.677 X-Spam-Level: ** X-Spam-Status: No, score=2.677 tagged_above=-999 required=5 tests=[AWL=3.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 haKrTFd1eQkt; Tue, 10 Feb 2009 19:04:25 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4DCE23A698C; Tue, 10 Feb 2009 19:04:25 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEV0098PSJ6DX@szxga03-in.huawei.com>; Wed, 11 Feb 2009 11:04:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEV00DA1SJ6E5@szxga03-in.huawei.com>; Wed, 11 Feb 2009 11:04:18 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEV00HW2SJ65J@szxml04-in.huawei.com>; Wed, 11 Feb 2009 11:04:18 +0800 (CST) Date: Wed, 11 Feb 2009 11:04:18 +0800 From: Fortune HUANG To: ietf@ietf.org Message-id: <006f01c98bf5$6df4fbf0$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_0Dg/js/2YQI551Vc3t3s8A)" Thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5Dg== Cc: magnus.westerlund@erricson.com, pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 03:04:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0Dg/js/2YQI551Vc3t3s8A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, There are still some places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" might be misused. Clarification or editorial changes are required in those places. Please see the detailed comments below. 6.2. Flow termination : "In one approach the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can actually be supported, and communicates this to the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and hence it can calculate the excess amount that should be terminated." Comment: It is the decision point but not the ingress node to be communicated by the egress and to decide the amount of termination. 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or flow termination. 7.4. Admission control functions: " There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement point [RFC2753], which polices incoming traffic to ensure it is part of an admitted PCN-flow. o The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked. o The decision is made at a centralised node (see Appendix; beyond scope of current PCN WG charter). Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a centralized node" by "the decision point may be co-located with the ingress or egress, or may be deployed on a standalone node". 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. 9.1.1. System options: "o Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node, see Appendix). " Comment: I suggest we replace this sentence by "o Where flow admission and termination decisions are made: co-located with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination". Best Regards, Fortune --Boundary_(ID_0Dg/js/2YQI551Vc3t3s8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
 
There are still some places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" might be misused. Clarification or editorial changes are required in those places. Please see the detailed comments below.
 
6.2.  Flow termination : "In one approach the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can actually be supported, and communicates this to the PCN-ingress-node.  Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and hence it can calculate the excess amount that should be terminated." Comment: It is the decision point but not the ingress node to be communicated by the egress and to decide the amount of termination.
 
6.4.       Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or flow termination.
 
7.4.  Admission control functions: "  There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used):   
 
 o  The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node.    
 
o  The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress-node.  The rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement       point [RFC2753], which polices incoming traffic to ensure it is part of an admitted PCN-flow.   
 
 o  The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node.  For example, it could signal the current fraction of PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised node (see Appendix; beyond scope of current PCN WG charter).  
 
 Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a centralized node" by "the decision point may be co-located with the ingress or egress, or may be deployed on a standalone node".
 
 
7.5.  Flow termination functions: "o  (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading.
 
 
9.1.1.  System options: "o  Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node,       see Appendix).  " Comment: I suggest we replace this sentence by "o  Where flow admission and termination decisions are made: co-located with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). "
 
 
9.5.  Security OAM: "o  A PCN-ingress-node receiving feedback signals about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination".
 
 
Best Regards,
Fortune
--Boundary_(ID_0Dg/js/2YQI551Vc3t3s8A)-- From tom.taylor@rogers.com Wed Feb 11 03:50:36 2009 Return-Path: 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 06E5F3A69BC for ; Wed, 11 Feb 2009 03:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] 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 B1lB1db4L915 for ; Wed, 11 Feb 2009 03:50:35 -0800 (PST) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by core3.amsl.com (Postfix) with SMTP id 0B9373A6A15 for ; Wed, 11 Feb 2009 03:50:34 -0800 (PST) Received: (qmail 98480 invoked from network); 11 Feb 2009 11:50:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZgWANhWb2vHRWQtv1Gm+KhaHLi0iUWfzHffRSuhC8WgnASQKfUeERU4v5GMdg1aAfrF8rmFw6qzx4vtn+jub/DOZYi5DaG4ZmjZw8ls4KCb/1oul0K/+Ed9YByCRwfNBj8Gn+bn9b0FjoWL7mpssBVLut5lAWfieC5pa6uQHzXI= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 11 Feb 2009 11:50:38 -0000 X-YMail-OSG: iGyRDZQVM1nvw0_wiFHTPeIIbg6hMF0e.lpquxzYbL3pwTnRFLM2uW7Gx6thFMQcSg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4992BB8B.1040604@rogers.com> Date: Wed, 11 Feb 2009 06:50:35 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <49820386.9080008@rogers.com> <49822BA9.9090702@informatik.uni-wuerzburg.de> <4990F910.8090600@rogers.com> <49913FCA.5000901@informatik.uni-wuerzburg.de> <49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> In-Reply-To: <4991DE20.2000606@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Why is CL useful if SM works? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 11:50:36 -0000 You may be right, depending on the interpretation of the admission marking threshold. If one chooses the admission stop point for the CLE on the basis that you want the statistical probability that you reach the maximum supportable rate to be less than x%, then there is a mathematical dependency between the admission marking threshold and the excess marking threshold that involves the statistical properties of the traffic flows. This dependency means that you can operate your network based observed flows most of the time, and use PCN marking only to cope with situations requiring flow termination. I can spell out the details. The catch is that in practice, statistical variances may be too high so you end up enforcing lower link occupancies than threshold marking would permit. Tom Michael Menth wrote: > Hi all, > > SM and CL were agreed to be both interesting to have as PCN mechanism at > the meeting in Philadelphia. > > I am not so sure about the benefit of CL. SM is good enough for networks > with large aggregates and single-path routing. CL does not a particular > better job in these cases although it requires two DSCPs for signalling > which is almost a show stopper. Therefore, I fear that CL in the form as > discussed so far is not useful. > > When we have SM working, only another mechanism can be of interest that > copes with multipath routing and small ingress-egress-aggregates (not > necessarily small link aggregation). And if possible, waste of > codepoints should be avoided. > > Comments? Please give feedback, have I overlooked something? > > Regards, > > Michael > From menth@informatik.uni-wuerzburg.de Wed Feb 11 04:37:34 2009 Return-Path: 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 8711A3A6AEE for ; Wed, 11 Feb 2009 04:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 aKV6xA01l-zC for ; Wed, 11 Feb 2009 04:37:33 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 76B0A3A6A5E for ; Wed, 11 Feb 2009 04:37:32 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A6431A0760; Wed, 11 Feb 2009 13:37:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 993D0A075F; Wed, 11 Feb 2009 13:37:35 +0100 (CET) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 82E85199083; Wed, 11 Feb 2009 13:37:35 +0100 (CET) Message-ID: <4992C68F.7060608@informatik.uni-wuerzburg.de> Date: Wed, 11 Feb 2009 13:37:35 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tom Taylor References: <49820386.9080008@rogers.com> <49822BA9.9090702@informatik.uni-wuerzburg.de> <4990F910.8090600@rogers.com> <49913FCA.5000901@informatik.uni-wuerzburg.de> <49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> <4992BB8B.1040604@rogers.com> In-Reply-To: <4992BB8B.1040604@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Why is CL useful if SM works? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:37:35 -0000 Hi Tom, you say the benefit of CL vs. SM is possibly increased resource efficiency since the admissible rate can be set to a larger value in CL than in SM because CL can cope better with variable traffic, right? So the argument for CL (as discussed so far) is possibly improved efficiency. I doubt that improved efficiency alone warrants the coexistence of two standards and the use of another DSCP. Are there other benefits and opinions? Regards, Michael Tom Taylor schrieb: > You may be right, depending on the interpretation of the admission > marking threshold. If one chooses the admission stop point for the CLE > on the basis that you want the statistical probability that you reach > the maximum supportable rate to be less than x%, then there is a > mathematical dependency between the admission marking threshold and > the excess marking threshold that involves the statistical properties > of the traffic flows. This dependency means that you can operate your > network based observed flows most of the time, and use PCN marking > only to cope with situations requiring flow termination. > > I can spell out the details. The catch is that in practice, > statistical variances may be too high so you end up enforcing lower > link occupancies than threshold marking would permit. > > Tom > > Michael Menth wrote: >> Hi all, >> >> SM and CL were agreed to be both interesting to have as PCN mechanism >> at the meeting in Philadelphia. >> >> I am not so sure about the benefit of CL. SM is good enough for >> networks with large aggregates and single-path routing. CL does not a >> particular better job in these cases although it requires two DSCPs >> for signalling which is almost a show stopper. Therefore, I fear that >> CL in the form as discussed so far is not useful. >> >> When we have SM working, only another mechanism can be of interest >> that copes with multipath routing and small ingress-egress-aggregates >> (not necessarily small link aggregation). And if possible, waste of >> codepoints should be avoided. >> >> Comments? Please give feedback, have I overlooked something? >> >> Regards, >> >> Michael >> -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From carlberg@g11.org.uk Wed Feb 11 04:43:50 2009 Return-Path: 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 530C53A6CED for ; Wed, 11 Feb 2009 04:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] 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 xVNWoHRsFly4 for ; Wed, 11 Feb 2009 04:43:49 -0800 (PST) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 622653A6A7F for ; Wed, 11 Feb 2009 04:43:49 -0800 (PST) Received: from c-69-255-250-27.hsd1.va.comcast.net ([69.255.250.27]:43581 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LXERO-0000Do-UP; Wed, 11 Feb 2009 12:43:47 +0000 Message-Id: <0F8CB53C-2556-48EE-9F30-4353EBD7DFFA@g11.org.uk> From: ken carlberg To: menth@informatik.uni-wuerzburg.de In-Reply-To: <4992C68F.7060608@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 07:43:48 -0500 References: <49820386.9080008@rogers.com> <49822BA9.9090702@informatik.uni-wuerzburg.de> <4990F910.8090600@rogers.com> <49913FCA.5000901@informatik.uni-wuerzburg.de> <49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> <4992BB8B.1040604@rogers.com> <4992C68F.7060608@informatik.uni-wuerzburg.de> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: pcn@ietf.org Subject: Re: [PCN] Why is CL useful if SM works? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:43:50 -0000 On Feb 11, 2009, at 7:37 AM, Michael Menth wrote: > I doubt that improved efficiency alone warrants the coexistence of > two standards and the use of another DSCP. Are there other benefits > and opinions? what other criteria do you feel needs to be in place? Also, out of curiosity (and just a general question), what are the chances that these efforts are initially migrated to experimental status by the IESG and the group is asked to use values from the experimental pool? -ken From menth@informatik.uni-wuerzburg.de Wed Feb 11 05:12:00 2009 Return-Path: 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 83BA83A68A5 for ; Wed, 11 Feb 2009 05:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 0edw-2O22Ypa for ; Wed, 11 Feb 2009 05:11:59 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A1DAF3A67A5 for ; Wed, 11 Feb 2009 05:11:59 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B4FB51990D0; Wed, 11 Feb 2009 14:12:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A72001990C7; Wed, 11 Feb 2009 14:12:03 +0100 (CET) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 8F7F51990BB; Wed, 11 Feb 2009 14:12:03 +0100 (CET) Message-ID: <4992CEA3.9060404@informatik.uni-wuerzburg.de> Date: Wed, 11 Feb 2009 14:12:03 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ken carlberg References: <49820386.9080008@rogers.com> <49822BA9.9090702@informatik.uni-wuerzburg.de> <4990F910.8090600@rogers.com> <49913FCA.5000901@informatik.uni-wuerzburg.de> <49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> <4992BB8B.1040604@rogers.com> <4992C68F.7060608@informatik.uni-wuerzburg.de> <0F8CB53C-2556-48EE-9F30-4353EBD7DFFA@g11.org.uk> In-Reply-To: <0F8CB53C-2556-48EE-9F30-4353EBD7DFFA@g11.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Why is CL useful if SM works? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:12:00 -0000 Hi Ken, ken carlberg schrieb: > > On Feb 11, 2009, at 7:37 AM, Michael Menth wrote: > >> I doubt that improved efficiency alone warrants the coexistence of >> two standards and the use of another DSCP. Are there other benefits >> and opinions? > > what other criteria do you feel needs to be in place? Coexistence of two similar PCN standards - a simple and a complex one - might make sense if this extends the applicability of PCN. Examples are networks with multipath routing or networks with low ingress-egress aggregation (with possibly large link aggregation). Regards, Michael > > Also, out of curiosity (and just a general question), what are the > chances that these efforts are initially migrated to experimental > status by the IESG and the group is asked to use values from the > experimental pool? > > -ken -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From acharny@cisco.com Wed Feb 11 05:56:10 2009 Return-Path: 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 E912C3A6A3D for ; Wed, 11 Feb 2009 05:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 O47EBc80GTeD for ; Wed, 11 Feb 2009 05:56:08 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 82FD53A6BF2 for ; Wed, 11 Feb 2009 05:56:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,192,1233532800"; d="scan'208";a="36686653" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2009 13:56:12 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1BDuCF8010819; Wed, 11 Feb 2009 08:56:12 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1BDuCsx002597; Wed, 11 Feb 2009 13:56:12 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 08:56:12 -0500 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, 11 Feb 2009 08:56:10 -0500 Message-ID: In-Reply-To: <4991DE20.2000606@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Why is CL useful if SM works? Thread-Index: AcmLuv8dcg9lpCWZTH2yBieSGe7PLwAlRCKA References: <49820386.9080008@rogers.com><49822BA9.9090702@informatik.uni-wuerzburg.de><4990F910.8090600@rogers.com><49913FCA.5000901@informatik.uni-wuerzburg.de><49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> From: "Anna Charny (acharny)" To: , X-OriginalArrivalTime: 11 Feb 2009 13:56:12.0180 (UTC) FILETIME=[7F8A1D40:01C98C50] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1772; t=1234360572; x=1235224572; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Why=20is=20CL=20useful=20if=20S M=20works? |Sender:=20 |To:=20,=20; bh=fC8QzsIyhmolNJxDuN2XmpHmkaXh6BfB/kJZEBtEDzI=; b=BsW2nVCH2kElFTPc7Mv3ZCFTpM862YvGrwywTKVsbxq0tq6Wj2zV0VJKlx yQg/J3pnx9u8NQMSF9PRZgnh+7yRGSBfYZRaCAijZyg3SKY1KtB7Y7s2tZaG sA2UNOX26M; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [PCN] Why is CL useful if SM works? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:56:11 -0000 Hi Michael, I think the area when CL is useful is exactly where SM performance suffers - which is in the presence of a very large number of small ingress-egress aggregates which together take a large portion of bottleneck capacity. Should this be the case in a network, CL clearly has superior performance over SM. Best, Anna=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Tuesday, February 10, 2009 3:06 PM To: pcn@ietf.org Subject: [PCN] Why is CL useful if SM works? Hi all, SM and CL were agreed to be both interesting to have as PCN mechanism at the meeting in Philadelphia. I am not so sure about the benefit of CL. SM is good enough for networks with large aggregates and single-path routing. CL does not a particular better job in these cases although it requires two DSCPs for signalling which is almost a show stopper. Therefore, I fear that CL in the form as discussed so far is not useful. When we have SM working, only another mechanism can be of interest that copes with multipath routing and small ingress-egress-aggregates (not necessarily small link aggregation). And if possible, waste of codepoints should be avoided. Comments? Please give feedback, have I overlooked something? Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Wed Feb 11 06:43:45 2009 Return-Path: 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 61BC73A6A24 for ; Wed, 11 Feb 2009 06:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 0otvicu5S8pw for ; Wed, 11 Feb 2009 06:43:44 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 13BC63A6935 for ; Wed, 11 Feb 2009 06:43:43 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8662D1990BC; Wed, 11 Feb 2009 15:43:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 79F331990B9; Wed, 11 Feb 2009 15:43:47 +0100 (CET) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5B5D61990B1; Wed, 11 Feb 2009 15:43:47 +0100 (CET) Message-ID: <4992E423.6070307@informatik.uni-wuerzburg.de> Date: Wed, 11 Feb 2009 15:43:47 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: <49820386.9080008@rogers.com><49822BA9.9090702@informatik.uni-wuerzburg.de><4990F910.8090600@rogers.com><49913FCA.5000901@informatik.uni-wuerzburg.de><49917E36.9070302@rogers.com> <4991DE20.2000606@informatik.uni-wuerzburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Why is CL useful if SM works? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:43:45 -0000 Hi Anna, Anna Charny (acharny) schrieb: > Hi Michael, > > I think the area when CL is useful is exactly where SM performance > suffers - which is in the presence of a very large number of small > ingress-egress aggregates which together take a large portion of > bottleneck capacity. Should this be the case in a network, CL clearly > has superior performance over SM. > The reason why CL and SM do not work well for small ingress-egress-aggregates (IEAs) is that many of these IEAs empty most of the time and cannot block. Figs. 5c and 5d in http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-8.pdf show that CL (exhaustive marking) reduces overadmission compared to SM (excess marking) if the average number of flows per IEA is about 1. Figs. 5a and 5b show that CL (exhaustive marking) cannot fight overload either the average number of flows per IEA it is smaller like 0.5. So CL just mitigates this situation, but I would not say that it can handle it. 100% overadmission is a lot. It's fine that SM cannot cope with a) small IEAs and b) multipath routing since it is just not designed for that. MPLS networks with fat pipes are happy to have this simple mechanism. But an improved PCN mechanism should be able to handle a) and b) especially if it costs another DSCP. Regards, Michael > Best, > Anna > > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: Tuesday, February 10, 2009 3:06 PM > To: pcn@ietf.org > Subject: [PCN] Why is CL useful if SM works? > > Hi all, > > SM and CL were agreed to be both interesting to have as PCN mechanism at > the meeting in Philadelphia. > > I am not so sure about the benefit of CL. SM is good enough for networks > with large aggregates and single-path routing. CL does not a particular > better job in these cases although it requires two DSCPs for signalling > which is almost a show stopper. Therefore, I fear that CL in the form as > discussed so far is not useful. > > When we have SM working, only another mechanism can be of interest that > copes with multipath routing and small ingress-egress-aggregates (not > necessarily small link aggregation). And if possible, waste of > codepoints should be avoided. > > Comments? Please give feedback, have I overlooked something? > > Regards, > > Michael > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am Hubland, > D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > 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/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From Ruediger.Geib@telekom.de Wed Feb 11 07:45:39 2009 Return-Path: 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 D8E8928C1E0 for ; Wed, 11 Feb 2009 07:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 ScIsh-+p0yvi for ; Wed, 11 Feb 2009 07:45:38 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 7CBD028C1D0 for ; Wed, 11 Feb 2009 07:45:36 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 11 Feb 2009 16:45:39 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 16:45:39 +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_01C98C5F.C9A0005C" Date: Wed, 11 Feb 2009 16:45:37 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5719794@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <006f01c98bf5$6df4fbf0$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTg References: <006f01c98bf5$6df4fbf0$7b27460a@china.huawei.com> From: To: X-OriginalArrivalTime: 11 Feb 2009 15:45:39.0471 (UTC) FILETIME=[C9F331F0:01C98C5F] Cc: pcn@ietf.org, magnus.westerlund@erricson.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:45:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98C5F.C9A0005C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune ------_=_NextPart_001_01C98C5F.C9A0005C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fortune,
 
any=20 changes to the formulations you suggest should respect the current = WG=20 charter. Please see in line for details.
 
Regards,
 
Rudiger
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Wednesday, February 11, 2009 4:04 AM
To: = ietf@ietf.org
Cc:=20 magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: = [PCN] Last=20 Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN)=20 Architecture) to Informational RFC

Hi = all,
 
There are = still some=20 places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" = might be=20 misused. Clarification or editorial = changes are=20 required in those places. Please see the detailed comments=20 below.
 
6.2.  Flow termination : "In one approach the=20 PCN-egress-node measures the rate of PCN-traffic that is not=20 excess-traffic-marked, which is the amount of PCN-traffic that can = actually be=20 supported, and communicates this to the PCN-ingress-node.  Also the = PCN-ingress-node measures the rate of PCN-traffic that is destined for = this=20 specific PCN-egress-node, and hence it can calculate the excess amount = that=20 should be terminated." Comment: It is the decision point but not the = ingress=20 node to be communicated by the egress and to decide the amount of=20 termination. 
 
[RG]=20 The charter says: "To = allow for=20 future extensions to the mechanisms and their application to new = deployment=20 scenarios, they are logically separated into several components, namely, = encoding and
transport along forward path from marker to egress, = metering of=20 congestion information at the egress, and transport of congestion = information=20 back to the controlling ingress."  and later:
(5)=20 encoding and transport of (pre-)congestion information between the = egress and=20 the controlling domain ingress
 
[RG] I=20 suggest to leave current meaning of text of the architecture as it is, = which=20 means conforming to the WG charter.
 
[RG]=20 The charter clearly states, that currently the only decision = point is the=20 ingress node. Your statement "it is the decision point but not the = ingress=20 node to be communicated by the egress to decide..." raises the = impression that=20 the ingress node can't be the decision point. The charter says exactly = the=20 opposite, there's no other decision point than the ingress node. So if = the term=20 "ingress node" is replaced by the "decision point", we must add some = text=20 clearly stating the the only decision point of this version of the=20 architecture document is the ingress node.
 
[RG]=20 So I'm open to something like: .....supported, and communicates this to = the=20 PCN-decision point (which is the PCN ingress node). I'm also open to an = entry in=20 the terminology defining the PCN-decision point to be the PCN ingress = node and a=20 stetement, that both terms are used interchangeably where applicable in = the=20 document.
 
 
6.4.       Information = transport: "Signalling is needed to transport PCN-feedback-information = between=20 the PCN-boundary-nodes, for example to convey the fraction of PCN-marked = traffic=20 from a PCN-egress-node to the relevant PCN-ingress-node." Comment:=20 PCN-feedback-information should transport from the egress to the = decision point=20 of admission control or flow termination. 
 
[RG] See above. 
 
7.4.  Admission control functions: "  = There are=20 various possibilities for how the functionality could be distributed (we = assume=20 the operator would configure which is used):    =
 
 o  The decision is made at the = PCN-egress-node and=20 the decision (admit or block) is signalled to the=20 PCN-ingress-node.    
 
o  The decision is recommended by the = PCN-egress-node=20 (admit or block) but the decision is definitively made by the=20 PCN-ingress-node.  The rationale is that the PCN-egress-node = naturally has=20 the necessary information about PCN-marking on the = ingress-egress-aggregate, but=20 the PCN-ingress-node is the policy=20 enforcement       point [RFC2753], which = polices=20 incoming traffic to ensure it is part of an admitted = PCN-flow.   =20
 
 o  The decision is made at the = PCN-ingress-node,=20 which requires that the PCN-egress-node signals PCN-feedback-information = to the=20 PCN-ingress-node.  For example, it could signal the current = fraction of=20 PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised = node (see=20 Appendix; beyond scope of current PCN WG charter).   =
 
 Note: Admission control functionality is not = performed=20 by normal PCN-interior-nodes." Comment: I would suggest we replace the = view "the=20 decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized=20 node" by "the decision point may be co-located with the ingress or = egress, or=20 may be deployed on a standalone node". 
 
[RG] I=20 suggest to leave the architecture document in a state conforming to the = WG=20 charter. As the architecture document correctly states, centralised = decision=20 points are beyond the scope of the current WG = charter. 
 
7.5.  Flow termination functions: "o  (if = required)=20 Communicate PCN-feedback-information to the node that makes the flow = termination=20 decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],=20 communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid=20 misleading.
 
[RG] I=20 think the example is not misleading, as it is in conformance with the = current WG=20 charter.
 
9.1.1.  System options: "o  Where flow = admission and=20 termination decisions are made: at PCN-ingress-nodes or at = PCN-egress-nodes (or=20 at a centralised node,       see = Appendix). =20 " Comment: I suggest we replace this sentence by "o  Where flow = admission=20 and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "
 
[RG] I=20 prefer the current statement, as the ingress or egress node being = decision=20 points is confoming to the current charter, whereas a standalone = node as a=20 decision point is not confoming to the current charter. Mentioning a = centralised=20 node in brackets is fair, I think.
 
9.5.  Security OAM: "o  A PCN-ingress-node = receiving=20 feedback signals about the pre-congestion level on a non-existent = aggregate, or=20 that are inconsistent with other signals (eg unexpected sequence = numbers,=20 inconsistent addressing, conflicting reports of the pre-congestion = level, etc)."=20 Comment: I suggest we replace the "PCN-ingress-node" by something like = "The=20 decision point of admission control or flow termination". 
 
[RG]=20 see comment at the top. 
 
 
Best=20 Regards,
Fortune
------_=_NextPart_001_01C98C5F.C9A0005C-- From fqhuang@huawei.com Wed Feb 11 22:06:18 2009 Return-Path: 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 1E90C3A6AB0 for ; Wed, 11 Feb 2009 22:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.768 X-Spam-Level: *** X-Spam-Status: No, score=3.768 tagged_above=-999 required=5 tests=[AWL=3.033, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 K35L9uhWjaEF for ; Wed, 11 Feb 2009 22:06:16 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 94C453A6A98 for ; Wed, 11 Feb 2009 22:06:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEX00CINVMGVH@szxga04-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 14:06:16 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEX00MVPVMGKL@szxga04-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 14:06:16 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEX00F8RVMGLJ@szxml05-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 14:06:16 +0800 (CST) Date: Thu, 12 Feb 2009 14:06:16 +0800 From: Fortune HUANG In-reply-to: <151C164FE2E066418D8D44D0801543A5719794@S4DE8PSAAQA.mitte.t-com.de> To: pcn@ietf.org Message-id: <003801c98cd8$03eba810$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Dfwi/cF6zV7soFQ94qjOiA)" Thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIA= Cc: magnus.westerlund@erricson.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 06:06:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Dfwi/cF6zV7soFQ94qjOiA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are not = part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune _____ =20 =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates this to = the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and = hence it can calculate the excess amount that should be terminated." Comment: It = is the decision point but not the ingress node to be communicated by the = egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion information back = to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not the ingress node to be communicated by the egress to decide..." raises the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than the = ingress node. So if the term "ingress node" is replaced by the "decision point", = we must add some text clearly stating the the only decision point of this version of the architecture document is the ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also open to = an entry in the terminology defining the PCN-decision point to be the PCN ingress node and a stetement, that both terms are used interchangeably = where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is = the policy enforcement point [RFC2753], which polices incoming traffic = to ensure it is part of an admitted PCN-flow. =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the ingress or = egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace this = sentence by "o Where flow admission and termination decisions are made: co-located = with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current charter. = Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune --Boundary_(ID_Dfwi/cF6zV7soFQ94qjOiA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi=20 Rudiger,
 
Thank you=20 very much for your response, but please let me clarify a little=20 bit.
 
PCN-ingress-node=20 (or PCN-egress-node) is only a logical set of functionalities = and=20 it=20 is not a physical device.
 
Please refer to=20 section 7.2 in PCN-arch and pay attention to the fact that the Admission = control=20 functions and Flow termination functions are not part of the = functionalities of=20 the PCN-ingress-node (nor = PCN-egress-node in=20 section 7.3).
 
We can implement both the Admission control = functions=20 and the PCN-ingress-node on the same = physical=20 device, but it doesn't change the fact that the Admission control = functions are=20 not part of the PCN-ingress-node. Is = this=20 understanding correct?
 
Best=20 Regards,
Fortune

=B7=A2=BC=FE=C8=CB: = Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA2=D4=C211=C8=D5=20 23:46
=CA=D5=BC=FE=C8=CB: = fqhuang@huawei.com
=B3=AD=CB=CD:=20 magnus.westerlund@erricson.com; pcn@ietf.org
=D6=F7=CC=E2: RE: = [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi Fortune,
 
any=20 changes to the formulations you suggest should respect the current = WG=20 charter. Please see in line for details.
 
Regards,
 
Rudiger
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Wednesday, February 11, 2009 4:04 AM
To: = ietf@ietf.org
Cc:=20 magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: = [PCN] Last=20 Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN)=20 Architecture) to Informational RFC

Hi = all,
 
There are = still some=20 places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" = might be=20 misused. Clarification or editorial = changes are=20 required in those places. Please see the detailed comments=20 below.
 
6.2.  Flow termination : "In one approach the=20 PCN-egress-node measures the rate of PCN-traffic that is not=20 excess-traffic-marked, which is the amount of PCN-traffic that can = actually be=20 supported, and communicates this to the PCN-ingress-node.  Also the = PCN-ingress-node measures the rate of PCN-traffic that is destined for = this=20 specific PCN-egress-node, and hence it can calculate the excess amount = that=20 should be terminated." Comment: It is the decision point but not the = ingress=20 node to be communicated by the egress and to decide the amount of=20 termination. 
 
[RG]=20 The charter says: "To = allow for=20 future extensions to the mechanisms and their application to new = deployment=20 scenarios, they are logically separated into several components, namely, = encoding and
transport along forward path from marker to egress, = metering of=20 congestion information at the egress, and transport of congestion = information=20 back to the controlling ingress."  and later:
(5)=20 encoding and transport of (pre-)congestion information between the = egress and=20 the controlling domain ingress
 
[RG] I=20 suggest to leave current meaning of text of the architecture as it is, = which=20 means conforming to the WG charter.
 
[RG]=20 The charter clearly states, that currently the only decision = point is the=20 ingress node. Your statement "it is the decision point but not the = ingress=20 node to be communicated by the egress to decide..." raises the = impression that=20 the ingress node can't be the decision point. The charter says exactly = the=20 opposite, there's no other decision point than the ingress node. So if = the term=20 "ingress node" is replaced by the "decision point", we must add some = text=20 clearly stating the the only decision point of this version of the=20 architecture document is the ingress node.
 
[RG]=20 So I'm open to something like: .....supported, and communicates this to = the=20 PCN-decision point (which is the PCN ingress node). I'm also open to an = entry in=20 the terminology defining the PCN-decision point to be the PCN ingress = node and a=20 stetement, that both terms are used interchangeably where applicable in = the=20 document.
 
 
6.4.       Information = transport: "Signalling is needed to transport PCN-feedback-information = between=20 the PCN-boundary-nodes, for example to convey the fraction of PCN-marked = traffic=20 from a PCN-egress-node to the relevant PCN-ingress-node." Comment:=20 PCN-feedback-information should transport from the egress to the = decision point=20 of admission control or flow termination. 
 
[RG] See above. 
 
7.4.  Admission control functions: "  = There are=20 various possibilities for how the functionality could be distributed (we = assume=20 the operator would configure which is used):    =
 
 o  The decision is made at the = PCN-egress-node and=20 the decision (admit or block) is signalled to the=20 PCN-ingress-node.    
 
o  The decision is recommended by the = PCN-egress-node=20 (admit or block) but the decision is definitively made by the=20 PCN-ingress-node.  The rationale is that the PCN-egress-node = naturally has=20 the necessary information about PCN-marking on the = ingress-egress-aggregate, but=20 the PCN-ingress-node is the policy=20 enforcement       point [RFC2753], which = polices=20 incoming traffic to ensure it is part of an admitted = PCN-flow.   =20
 
 o  The decision is made at the = PCN-ingress-node,=20 which requires that the PCN-egress-node signals PCN-feedback-information = to the=20 PCN-ingress-node.  For example, it could signal the current = fraction of=20 PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised = node (see=20 Appendix; beyond scope of current PCN WG charter).   =
 
 Note: Admission control functionality is not = performed=20 by normal PCN-interior-nodes." Comment: I would suggest we replace the = view "the=20 decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized=20 node" by "the decision point may be co-located with the ingress or = egress, or=20 may be deployed on a standalone node". 
 
[RG] I=20 suggest to leave the architecture document in a state conforming to the = WG=20 charter. As the architecture document correctly states, centralised = decision=20 points are beyond the scope of the current WG = charter. 
 
7.5.  Flow termination functions: "o  (if = required)=20 Communicate PCN-feedback-information to the node that makes the flow = termination=20 decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],=20 communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid=20 misleading.
 
[RG] I=20 think the example is not misleading, as it is in conformance with the = current WG=20 charter.
 
9.1.1.  System options: "o  Where flow = admission and=20 termination decisions are made: at PCN-ingress-nodes or at = PCN-egress-nodes (or=20 at a centralised node,       see = Appendix). =20 " Comment: I suggest we replace this sentence by "o  Where flow = admission=20 and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "
 
[RG] I=20 prefer the current statement, as the ingress or egress node being = decision=20 points is confoming to the current charter, whereas a standalone = node as a=20 decision point is not confoming to the current charter. Mentioning a = centralised=20 node in brackets is fair, I think.
 
9.5.  Security OAM: "o  A PCN-ingress-node = receiving=20 feedback signals about the pre-congestion level on a non-existent = aggregate, or=20 that are inconsistent with other signals (eg unexpected sequence = numbers,=20 inconsistent addressing, conflicting reports of the pre-congestion = level, etc)."=20 Comment: I suggest we replace the "PCN-ingress-node" by something like = "The=20 decision point of admission control or flow termination". 
 
[RG]=20 see comment at the top. 
 
 
Best=20 Regards,
Fortune
--Boundary_(ID_Dfwi/cF6zV7soFQ94qjOiA)-- From Ruediger.Geib@telekom.de Thu Feb 12 00:36:42 2009 Return-Path: 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 8B5F63A6AEF for ; Thu, 12 Feb 2009 00:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.086 X-Spam-Level: X-Spam-Status: No, score=0.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 4EFG8h2ISWzE for ; Thu, 12 Feb 2009 00:36:40 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 5D36E3A6AD8 for ; Thu, 12 Feb 2009 00:36:37 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 12 Feb 2009 09:36:28 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 09:36:28 +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_01C98CEC.FF53ABAE" Date: Thu, 12 Feb 2009 09:36:27 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5719B0E@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <003801c98cd8$03eba810$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUA== References: <151C164FE2E066418D8D44D0801543A5719794@S4DE8PSAAQA.mitte.t-com.de> <003801c98cd8$03eba810$7b27460a@china.huawei.com> From: To: X-OriginalArrivalTime: 12 Feb 2009 08:36:28.0433 (UTC) FILETIME=[FF8C6010:01C98CEC] Cc: pcn@ietf.org, magnus.westerlund@erricson.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:36:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98CEC.FF53ABAE Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any = details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a = separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node = (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes = following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the = architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard = confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of = either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture = draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 _____ =20 From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of = functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are = not part of the functionalities of the PCN-ingress-node (nor = PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the = PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune _____ =20 =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune ------_=_NextPart_001_01C98CEC.FF53ABAE Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Fortune,
 
of=20 course section 7.2 of the current architecture does not describe any = details of=20 the admission control. 
Look for  "7.4  Admission = control=20 functions" and for section "6 High = level=20 functional architecture" determining
that the detailed specification of admission = control=20 will follow in a separate document.
 
Please carefully read the whole document = before you=20 distribute statements like
 
[Fortune Huang]: "Admission control functions = and Flow=20 termination functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in = section=20 7.3)"
 
The architecture draft clearly specifies the = opposite,=20 as the quotes following below show (I've = shortened it all=20 to the relevant text).
 
To answer your question: your understanding = is not=20 conforming to the architecture. It is a fact, that admission control is = an=20
ingress node functionality (the egress node = being the=20 only standard=20 confroming alternative).
Admission Control is an ingress node=20 functionality which will be = specified in=20 detail by a separate document (egress nodes =
are an alternate point for implementation).=20
"Admission Control" may of course be a=20 separate logical functionality of either = each PCN ingress or egress node, but it = is=20
part of all physical devices which are = either=20 ingress (or egress) nodes.
 
If the charter is adapted, also centralised = approaches=20 may be standardised by IETF.
 
Regards,
 
Rudiger
 
-------------------Quotes from the PCN = architecture=20 draft----------------------------
 
"6.  High-level functional=20 architecture
 
   The high-level approach is to = split=20 functionality between:
 
   o =20 [snip]
 
   o  PCN-boundary-nodes at = the edge of=20 the PCN-domain, which control
      = admission of new=20 PCN-flows and termination of existing=20 PCN-flows,
      based on information from=20 PCN-interior-nodes.  This information = is
     =20 in the form of the PCN-marked data packets (which are=20 intercepted
      by the PCN-egress-nodes) = and not=20 signalling messages.  Generally
     =20 PCN-ingress-nodes are flow-aware.
[RG: readers, please note that = PCN-boundary-nodes are=20 the PCN-ingress
 and the = PCN-egress-node]
 
   The aim of this split is to keep = the bulk=20 of the network simple,
   scalable and robust, whilst = confining=20 policy, application-level and
   security interactions to = the edge=20 of the PCN-domain.  [snip]
 
   The PCN-boundary-nodes monitor = the=20 PCN-marked packets in order to
   extract information about = the=20 current state of the PCN-domain.  Based
   on this = monitoring,=20 a distributed decision is made about whether to
   admit a=20 prospective new flow or whether to terminate existing
  =20 flow(s).  Sections 7.4 and 7.5 mention various possibilities for=20 how
   the functionality could be=20 distributed.
 
6.1.  Flow=20 admission
 
   = [snip]
   Exactly how the admission = control decision=20 is made will be defined
   separately in informational=20 documents. 
 

7.4. =20 Admission control functions
 
[snip]
 
   There=20 are various possibilities for how the functionality could = be
  =20 distributed (we assume the operator would configure which is = used):
 
  =20 o  The decision is made at the PCN-egress-node and the=20 decision
      (admit or block) is signalled = to the=20 PCN-ingress-node.
 
  =20 o  The decision is recommended by the PCN-egress-node (admit=20 or
      block) but the decision is = definitively=20 made by the PCN-ingress-
     =20 node.  [snip]
 
   o  The decision is made at the=20 PCN-ingress-node, [snip]
 
  =20 o  The decision is made at a centralised node (see = Appendix).
  
=
From: Fortune HUANG = [mailto:fqhuang@huawei.com]=20
Sent: Thursday, February 12, 2009 7:06 AM
To:=20 pcn@ietf.org
Cc: magnus.westerlund@erricson.com; Geib, = R=A8=B9diger;=20 philip.eardley@bt.com
Subject: Re: [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi=20 Rudiger,
 
Thank you=20 very much for your response, but please let me clarify a little=20 bit.
 
PCN-ingress-node=20 (or PCN-egress-node) is only a logical set of functionalities = and=20 it=20 is not a physical device.
 
Please refer to=20 section 7.2 in PCN-arch and pay attention to the fact that the Admission = control=20 functions and Flow termination functions are not part of the = functionalities of=20 the PCN-ingress-node (nor = PCN-egress-node in=20 section 7.3).
 
We can implement both the Admission control = functions=20 and the PCN-ingress-node on the same = physical=20 device, but it doesn't change the fact that the Admission control = functions are=20 not part of the PCN-ingress-node. Is = this=20 understanding correct?
 
Best=20 Regards,
Fortune

=B7=A2=BC=FE=C8=CB: = Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA2=D4=C211=C8=D5=20 23:46
=CA=D5=BC=FE=C8=CB: = fqhuang@huawei.com
=B3=AD=CB=CD:=20 magnus.westerlund@erricson.com; pcn@ietf.org
=D6=F7=CC=E2: RE: = [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi Fortune,
 
any=20 changes to the formulations you suggest should respect the current = WG=20 charter. Please see in line for details.
 
Regards,
 
Rudiger
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Wednesday, February 11, 2009 4:04 AM
To: = ietf@ietf.org
Cc:=20 magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: = [PCN] Last=20 Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN)=20 Architecture) to Informational RFC

Hi = all,
 
There are = still some=20 places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" = might be=20 misused. Clarification or editorial = changes are=20 required in those places. Please see the detailed comments=20 below.
 
6.2.  Flow termination : "In one approach the=20 PCN-egress-node measures the rate of PCN-traffic that is not=20 excess-traffic-marked, which is the amount of PCN-traffic that can = actually be=20 supported, and communicates this to the PCN-ingress-node.  Also the = PCN-ingress-node measures the rate of PCN-traffic that is destined for = this=20 specific PCN-egress-node, and hence it can calculate the excess amount = that=20 should be terminated." Comment: It is the decision point but not the = ingress=20 node to be communicated by the egress and to decide the amount of=20 termination. 
 
[RG]=20 The charter says: "To = allow for=20 future extensions to the mechanisms and their application to new = deployment=20 scenarios, they are logically separated into several components, namely, = encoding and
transport along forward path from marker to egress, = metering of=20 congestion information at the egress, and transport of congestion = information=20 back to the controlling ingress."  and later:
(5)=20 encoding and transport of (pre-)congestion information between the = egress and=20 the controlling domain ingress
 
[RG] I=20 suggest to leave current meaning of text of the architecture as it is, = which=20 means conforming to the WG charter.
 
[RG]=20 The charter clearly states, that currently the only decision = point is the=20 ingress node. Your statement "it is the decision point but not the = ingress=20 node to be communicated by the egress to decide..." raises the = impression that=20 the ingress node can't be the decision point. The charter says exactly = the=20 opposite, there's no other decision point than the ingress node. So if = the term=20 "ingress node" is replaced by the "decision point", we must add some = text=20 clearly stating the the only decision point of this version of the=20 architecture document is the ingress node.
 
[RG]=20 So I'm open to something like: .....supported, and communicates this to = the=20 PCN-decision point (which is the PCN ingress node). I'm also open to an = entry in=20 the terminology defining the PCN-decision point to be the PCN ingress = node and a=20 stetement, that both terms are used interchangeably where applicable in = the=20 document.
 
 
6.4.       Information = transport: "Signalling is needed to transport PCN-feedback-information = between=20 the PCN-boundary-nodes, for example to convey the fraction of PCN-marked = traffic=20 from a PCN-egress-node to the relevant PCN-ingress-node." Comment:=20 PCN-feedback-information should transport from the egress to the = decision point=20 of admission control or flow termination. 
 
[RG] See above. 
 
7.4.  Admission control functions: "  = There are=20 various possibilities for how the functionality could be distributed (we = assume=20 the operator would configure which is used):    =
 
 o  The decision is made at the = PCN-egress-node and=20 the decision (admit or block) is signalled to the=20 PCN-ingress-node.    
 
o  The decision is recommended by the = PCN-egress-node=20 (admit or block) but the decision is definitively made by the=20 PCN-ingress-node.  The rationale is that the PCN-egress-node = naturally has=20 the necessary information about PCN-marking on the = ingress-egress-aggregate, but=20 the PCN-ingress-node is the policy=20 enforcement       point [RFC2753], which = polices=20 incoming traffic to ensure it is part of an admitted = PCN-flow.   =20
 
 o  The decision is made at the = PCN-ingress-node,=20 which requires that the PCN-egress-node signals PCN-feedback-information = to the=20 PCN-ingress-node.  For example, it could signal the current = fraction of=20 PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised = node (see=20 Appendix; beyond scope of current PCN WG charter).   =
 
 Note: Admission control functionality is not = performed=20 by normal PCN-interior-nodes." Comment: I would suggest we replace the = view "the=20 decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized=20 node" by "the decision point may be co-located with the ingress or = egress, or=20 may be deployed on a standalone node". 
 
[RG] I=20 suggest to leave the architecture document in a state conforming to the = WG=20 charter. As the architecture document correctly states, centralised = decision=20 points are beyond the scope of the current WG = charter. 
 
7.5.  Flow termination functions: "o  (if = required)=20 Communicate PCN-feedback-information to the node that makes the flow = termination=20 decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],=20 communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid=20 misleading.
 
[RG] I=20 think the example is not misleading, as it is in conformance with the = current WG=20 charter.
 
9.1.1.  System options: "o  Where flow = admission and=20 termination decisions are made: at PCN-ingress-nodes or at = PCN-egress-nodes (or=20 at a centralised node,       see = Appendix). =20 " Comment: I suggest we replace this sentence by "o  Where flow = admission=20 and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "
 
[RG] I=20 prefer the current statement, as the ingress or egress node being = decision=20 points is confoming to the current charter, whereas a standalone = node as a=20 decision point is not confoming to the current charter. Mentioning a = centralised=20 node in brackets is fair, I think.
 
9.5.  Security OAM: "o  A PCN-ingress-node = receiving=20 feedback signals about the pre-congestion level on a non-existent = aggregate, or=20 that are inconsistent with other signals (eg unexpected sequence = numbers,=20 inconsistent addressing, conflicting reports of the pre-congestion = level, etc)."=20 Comment: I suggest we replace the "PCN-ingress-node" by something like = "The=20 decision point of admission control or flow termination". 
 
[RG]=20 see comment at the top. 
 
 
Best=20 Regards,
Fortune
------_=_NextPart_001_01C98CEC.FF53ABAE-- From fqhuang@huawei.com Thu Feb 12 02:02:47 2009 Return-Path: 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 0146A28C11D for ; Thu, 12 Feb 2009 02:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.304 X-Spam-Level: *** X-Spam-Status: No, score=3.304 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 tGp0XjZlEEbz for ; Thu, 12 Feb 2009 02:02:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 012513A6B32 for ; Thu, 12 Feb 2009 02:02:43 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEY000K16KE75@szxga03-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 18:02:38 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEY00E0S6KERS@szxga03-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 18:02:38 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEY006FY6KEEL@szxml06-in.huawei.com> for pcn@ietf.org; Thu, 12 Feb 2009 18:02:38 +0800 (CST) Date: Thu, 12 Feb 2009 18:02:37 +0800 From: Fortune HUANG In-reply-to: <151C164FE2E066418D8D44D0801543A5719B0E@S4DE8PSAAQA.mitte.t-com.de> To: pcn@ietf.org, Ruediger.Geib@telekom.de Message-id: <007101c98cf9$08daeb80$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/I6F1Mtumn7JnTPZmSNLRA)" Thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQ Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 10:02:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/I6F1Mtumn7JnTPZmSNLRA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the PCN-decision = point to be the PCN ingress node and a stetement, that both terms are used interchangeably where applicable in the document." =20 I agree with your proposal to add an entry in the terminology defining = the PCN-decision-point (or PCN-decision-node which I prefer). But in order = to make the draft more precise and future-proof, I suggest we use the terminologies PCN-decision-node and PCN-ingress-node carefully and precisely. That is to say, when refering to the admission control = functions or the flow termination functions, we use the terminology = PCN-decision-node, and when refering to other functionalities of the ingress we use = terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, the PCN = egress or the centralised node can act as the PCN-decision-node. However, the current charter of the PCN Working Group assumes only the PCN ingress = act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome. =20 Best Regards, Fortune =20 _____ =20 =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C212=C8=D5 16:36 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; philip.eardley@bt.com; = pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 _____ =20 From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are not = part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune _____ =20 =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates this to = the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and = hence it can calculate the excess amount that should be terminated." Comment: It = is the decision point but not the ingress node to be communicated by the = egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion information back = to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not the ingress node to be communicated by the egress to decide..." raises the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than the = ingress node. So if the term "ingress node" is replaced by the "decision point", = we must add some text clearly stating the the only decision point of this version of the architecture document is the ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also open to = an entry in the terminology defining the PCN-decision point to be the PCN ingress node and a stetement, that both terms are used interchangeably = where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is = the policy enforcement point [RFC2753], which polices incoming traffic = to ensure it is part of an admitted PCN-flow. =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the ingress or = egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace this = sentence by "o Where flow admission and termination decisions are made: co-located = with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current charter. = Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune --Boundary_(ID_/I6F1Mtumn7JnTPZmSNLRA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi=20 Rudiger,
 
Thank you very=20 much for your answer. Things are getting clearer to=20 me now.
 
Back to your proposal as=20 follows:
 
[Rudiger]: "[RG] So I'm open to = something=20 like: .....supported, and communicates this to the PCN-decision point = (which is=20 the PCN ingress node). I'm also open to an entry in the terminology = defining the=20 PCN-decision point to be the PCN ingress node and a stetement, that both = terms=20 are used interchangeably where applicable in the document."
&nbs= p;
I=20 agree with your proposal to add an entry in the terminology = defining=20 the PCN-decision-point (or PCN-decision-node which I prefer). But in order to=20 make the draft more precise and future-proof, I suggest we use the = terminologies=20 PCN-decision-node and PCN-ingress-node carefully and precisely. = That is to=20 say, when refering to the admission control functions or the flow = termination=20 functions, we use the terminology PCN-decision-node, and when refering = to other=20 functionalities of the ingress we use terminology=20 PCN-ingress-node.=
 
Here = is my=20 initial text of the definition of=20 PCN-decision-node:
&nbs= p;
   o  PCN-decision-node: the = node that=20 makes admission and flow termination decisions in the PCN=20 domain. Theoretically, the PCN ingress, the PCN egress or the = centralised=20 node can act as the PCN-decision-node. However, the current charter = of the=20 PCN Working Group assumes only the PCN ingress act as the=20 PCN-decision-node.
&nbs= p;
Your=20 comments or revision are very=20 welcome.
&nbs= p;
Best=20 Regards,
Fortune
 

=B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA2=D4=C212=C8=D5=20 16:36
=CA=D5=BC=FE=C8=CB: = fqhuang@huawei.com
=B3=AD=CB=CD:=20 magnus.westerlund@erricson.com; philip.eardley@bt.com;=20 pcn@ietf.org
=D6=F7=CC=E2: RE: [PCN] Last Call: = draft-ietf-pcn-architecture=20 (Pre-Congestion Notification (PCN) Architecture) to Informational=20 RFC

Hi Fortune,
 
of=20 course section 7.2 of the current architecture does not describe any = details of=20 the admission control. 
Look for  "7.4  Admission = control=20 functions" and for section "6 High = level=20 functional architecture" determining
that the detailed specification of admission = control=20 will follow in a separate document.
 
Please carefully read the whole document = before you=20 distribute statements like
 
[Fortune Huang]: "Admission control functions = and Flow=20 termination functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in = section=20 7.3)"
 
The architecture draft clearly specifies the = opposite,=20 as the quotes following below show (I've = shortened it all=20 to the relevant text).
 
To answer your question: your understanding = is not=20 conforming to the architecture. It is a fact, that admission control is = an=20
ingress node functionality (the egress node = being the=20 only standard=20 confroming alternative).
Admission Control is an ingress node=20 functionality which will be = specified in=20 detail by a separate document (egress nodes =
are an alternate point for implementation).=20
"Admission Control" may of course be a=20 separate logical functionality of either = each PCN ingress or egress node, but it = is=20
part of all physical devices which are = either=20 ingress (or egress) nodes.
 
If the charter is adapted, also centralised = approaches=20 may be standardised by IETF.
 
Regards,
 
Rudiger
 
-------------------Quotes from the PCN = architecture=20 draft----------------------------
 
"6.  High-level functional=20 architecture
 
   The high-level approach is to = split=20 functionality between:
 
   o =20 [snip]
 
   o  PCN-boundary-nodes at = the edge of=20 the PCN-domain, which control
      = admission of new=20 PCN-flows and termination of existing=20 PCN-flows,
      based on information from=20 PCN-interior-nodes.  This information = is
     =20 in the form of the PCN-marked data packets (which are=20 intercepted
      by the PCN-egress-nodes) = and not=20 signalling messages.  Generally
     =20 PCN-ingress-nodes are flow-aware.
[RG: readers, please note that = PCN-boundary-nodes are=20 the PCN-ingress
 and the = PCN-egress-node]
 
   The aim of this split is to keep = the bulk=20 of the network simple,
   scalable and robust, whilst = confining=20 policy, application-level and
   security interactions to = the edge=20 of the PCN-domain.  [snip]
 
   The PCN-boundary-nodes monitor = the=20 PCN-marked packets in order to
   extract information about = the=20 current state of the PCN-domain.  Based
   on this = monitoring,=20 a distributed decision is made about whether to
   admit a=20 prospective new flow or whether to terminate existing
  =20 flow(s).  Sections 7.4 and 7.5 mention various possibilities for=20 how
   the functionality could be=20 distributed.
 
6.1.  Flow=20 admission
 
   = [snip]
   Exactly how the admission = control decision=20 is made will be defined
   separately in informational=20 documents. 
 

7.4. =20 Admission control functions
 
[snip]
 
   There=20 are various possibilities for how the functionality could = be
  =20 distributed (we assume the operator would configure which is = used):
 
  =20 o  The decision is made at the PCN-egress-node and the=20 decision
      (admit or block) is signalled = to the=20 PCN-ingress-node.
 
  =20 o  The decision is recommended by the PCN-egress-node (admit=20 or
      block) but the decision is = definitively=20 made by the PCN-ingress-
     =20 node.  [snip]
 
   o  The decision is made at the=20 PCN-ingress-node, [snip]
 
  =20 o  The decision is made at a centralised node (see = Appendix).
  
=
From: Fortune HUANG = [mailto:fqhuang@huawei.com]=20
Sent: Thursday, February 12, 2009 7:06 AM
To:=20 pcn@ietf.org
Cc: magnus.westerlund@erricson.com; Geib, = R=A8=B9diger;=20 philip.eardley@bt.com
Subject: Re: [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi=20 Rudiger,
 
Thank you=20 very much for your response, but please let me clarify a little=20 bit.
 
PCN-ingress-node=20 (or PCN-egress-node) is only a logical set of functionalities = and=20 it=20 is not a physical device.
 
Please refer to=20 section 7.2 in PCN-arch and pay attention to the fact that the Admission = control=20 functions and Flow termination functions are not part of the = functionalities of=20 the PCN-ingress-node (nor = PCN-egress-node in=20 section 7.3).
 
We can implement both the Admission control = functions=20 and the PCN-ingress-node on the same = physical=20 device, but it doesn't change the fact that the Admission control = functions are=20 not part of the PCN-ingress-node. Is = this=20 understanding correct?
 
Best=20 Regards,
Fortune

=B7=A2=BC=FE=C8=CB: = Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA2=D4=C211=C8=D5=20 23:46
=CA=D5=BC=FE=C8=CB: = fqhuang@huawei.com
=B3=AD=CB=CD:=20 magnus.westerlund@erricson.com; pcn@ietf.org
=D6=F7=CC=E2: RE: = [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi Fortune,
 
any=20 changes to the formulations you suggest should respect the current = WG=20 charter. Please see in line for details.
 
Regards,
 
Rudiger
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Wednesday, February 11, 2009 4:04 AM
To: = ietf@ietf.org
Cc:=20 magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: = [PCN] Last=20 Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN)=20 Architecture) to Informational RFC

Hi = all,
 
There are = still some=20 places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" = might be=20 misused. Clarification or editorial = changes are=20 required in those places. Please see the detailed comments=20 below.
 
6.2.  Flow termination : "In one approach the=20 PCN-egress-node measures the rate of PCN-traffic that is not=20 excess-traffic-marked, which is the amount of PCN-traffic that can = actually be=20 supported, and communicates this to the PCN-ingress-node.  Also the = PCN-ingress-node measures the rate of PCN-traffic that is destined for = this=20 specific PCN-egress-node, and hence it can calculate the excess amount = that=20 should be terminated." Comment: It is the decision point but not the = ingress=20 node to be communicated by the egress and to decide the amount of=20 termination. 
 
[RG]=20 The charter says: "To = allow for=20 future extensions to the mechanisms and their application to new = deployment=20 scenarios, they are logically separated into several components, namely, = encoding and
transport along forward path from marker to egress, = metering of=20 congestion information at the egress, and transport of congestion = information=20 back to the controlling ingress."  and later:
(5)=20 encoding and transport of (pre-)congestion information between the = egress and=20 the controlling domain ingress
 
[RG] I=20 suggest to leave current meaning of text of the architecture as it is, = which=20 means conforming to the WG charter.
 
[RG]=20 The charter clearly states, that currently the only decision = point is the=20 ingress node. Your statement "it is the decision point but not the = ingress=20 node to be communicated by the egress to decide..." raises the = impression that=20 the ingress node can't be the decision point. The charter says exactly = the=20 opposite, there's no other decision point than the ingress node. So if = the term=20 "ingress node" is replaced by the "decision point", we must add some = text=20 clearly stating the the only decision point of this version of the=20 architecture document is the ingress node.
 
[RG]=20 So I'm open to something like: .....supported, and communicates this to = the=20 PCN-decision point (which is the PCN ingress node). I'm also open to an = entry in=20 the terminology defining the PCN-decision point to be the PCN ingress = node and a=20 stetement, that both terms are used interchangeably where applicable in = the=20 document.
 
 
6.4.       Information = transport: "Signalling is needed to transport PCN-feedback-information = between=20 the PCN-boundary-nodes, for example to convey the fraction of PCN-marked = traffic=20 from a PCN-egress-node to the relevant PCN-ingress-node." Comment:=20 PCN-feedback-information should transport from the egress to the = decision point=20 of admission control or flow termination. 
 
[RG] See above. 
 
7.4.  Admission control functions: "  = There are=20 various possibilities for how the functionality could be distributed (we = assume=20 the operator would configure which is used):    =
 
 o  The decision is made at the = PCN-egress-node and=20 the decision (admit or block) is signalled to the=20 PCN-ingress-node.    
 
o  The decision is recommended by the = PCN-egress-node=20 (admit or block) but the decision is definitively made by the=20 PCN-ingress-node.  The rationale is that the PCN-egress-node = naturally has=20 the necessary information about PCN-marking on the = ingress-egress-aggregate, but=20 the PCN-ingress-node is the policy=20 enforcement       point [RFC2753], which = polices=20 incoming traffic to ensure it is part of an admitted = PCN-flow.   =20
 
 o  The decision is made at the = PCN-ingress-node,=20 which requires that the PCN-egress-node signals PCN-feedback-information = to the=20 PCN-ingress-node.  For example, it could signal the current = fraction of=20 PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised = node (see=20 Appendix; beyond scope of current PCN WG charter).   =
 
 Note: Admission control functionality is not = performed=20 by normal PCN-interior-nodes." Comment: I would suggest we replace the = view "the=20 decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized=20 node" by "the decision point may be co-located with the ingress or = egress, or=20 may be deployed on a standalone node". 
 
[RG] I=20 suggest to leave the architecture document in a state conforming to the = WG=20 charter. As the architecture document correctly states, centralised = decision=20 points are beyond the scope of the current WG = charter. 
 
7.5.  Flow termination functions: "o  (if = required)=20 Communicate PCN-feedback-information to the node that makes the flow = termination=20 decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],=20 communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid=20 misleading.
 
[RG] I=20 think the example is not misleading, as it is in conformance with the = current WG=20 charter.
 
9.1.1.  System options: "o  Where flow = admission and=20 termination decisions are made: at PCN-ingress-nodes or at = PCN-egress-nodes (or=20 at a centralised node,       see = Appendix). =20 " Comment: I suggest we replace this sentence by "o  Where flow = admission=20 and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "
 
[RG] I=20 prefer the current statement, as the ingress or egress node being = decision=20 points is confoming to the current charter, whereas a standalone = node as a=20 decision point is not confoming to the current charter. Mentioning a = centralised=20 node in brackets is fair, I think.
 
9.5.  Security OAM: "o  A PCN-ingress-node = receiving=20 feedback signals about the pre-congestion level on a non-existent = aggregate, or=20 that are inconsistent with other signals (eg unexpected sequence = numbers,=20 inconsistent addressing, conflicting reports of the pre-congestion = level, etc)."=20 Comment: I suggest we replace the "PCN-ingress-node" by something like = "The=20 decision point of admission control or flow termination". 
 
[RG]=20 see comment at the top. 
 
 
Best=20 Regards,
Fortune
--Boundary_(ID_/I6F1Mtumn7JnTPZmSNLRA)-- From philip.eardley@bt.com Thu Feb 12 03:24:39 2009 Return-Path: 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 3A0343A68CC for ; Thu, 12 Feb 2009 03:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.952 X-Spam-Level: X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, MIME_CHARSET_FARAWAY=2.45, 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 zRFl0fQdulUq for ; Thu, 12 Feb 2009 03:24:36 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 250273A6841 for ; Thu, 12 Feb 2009 03:24:34 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 11:24:37 +0000 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_01C98D04.7C594224" Date: Thu, 12 Feb 2009 11:24:36 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7970@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <007101c98cf9$08daeb80$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Thread-Index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQAALmFrA= From: To: , , X-OriginalArrivalTime: 12 Feb 2009 11:24:37.0404 (UTC) FILETIME=[7D0B2DC0:01C98D04] Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:24:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98D04.7C594224 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Thanks for the feedback on the architecture draft. The good news is that = we=A1=AFre discussing a very small, fine point. However, this does mean = that, I think, we should be cautious about changes, such as introducing = new terminology, especially where everyone is already clear and in = agreement about what the draft means ie that the function making the = decision about admission or termination can be situated in various = places (including a centralised node, which I think is your interest = Fortune)..=20 =20 My comments fall somewhere between the two of you. =20 >From a terminology point of view, there are indeed terms that are = defined with respect to physical architecture (eg PCN-boundary-node) and = terms that are defined with respect to functional architecture (eg = PCN-ingress-node). I am very comfortable with this =A8C it reflects that = sometimes the architecture draft wants to talk about the physical & = sometimes about functional architecture. I think the terminology = proposal below actually make things worse (eg I can=A1=AFt tell whether = your PCN-decision-node definition is physical or functional, and it = refers to PCN ingress and egress which are not defined.) =20 So I=A1=AFd like to suggest the following ways of handling your original = comments:- =20 6.2. Flow termination : =A1=B0In one approach the PCN-egress-node = measures the rate of PCN-traffic that is not excess-traffic-marked, = which is the amount of PCN-traffic that can actually be supported, and = communicates this to the PCN-ingress-node. Also the PCN-ingress-node = measures the rate of PCN-traffic that is destined for this specific = PCN-egress-node, and hence it can calculate the excess amount that = should be terminated.=A1=B1 Comment: It is the decision point but not = the ingress node to be communicated by the egress and to decide the = amount of termination. =20 Proposal - Modify the last sentence: =A1=B0Also the PCN-ingress-node = measures the rate of PCN-traffic that is destined for this specific = PCN-egress-node. The difference represents the excess amount that should = be terminated.=A1=B1 =20 =20 6.4. Information transport: =A1=B0Signalling is needed to = transport PCN-feedback-information between the PCN-boundary-nodes, for = example to convey the fraction of PCN-marked traffic from a = PCN-egress-node to the relevant PCN-ingress-node.=A1=B1=20 =20 Proposal =A8C =A1=B0Signalling is needed to transport = PCN-feedback-information, for example to convey the fraction of = PCN-marked traffic from a PCN-egress-node to the relevant = PCN-ingress-node.=A1=B1 (The definition of PCN-feedback-information = makes clear that the example is only an example.)=20 =20 7.4. Admission control functions: =A1=B0 There are various = possibilities for how the functionality could be distributed (we assume = the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. [etc - cut] Comment: I would suggest we replace the view =A1=B0the decision is made = at the PCN-ingress-node or PCN-egress-node or a centralized node=A1=B1 = by =A1=B0the decision point may be co-located with the ingress or = egress, or may be deployed on a standalone node=A1=B1. =20 Proposal =A8C leave unaltered. I find your proposal less clear than the = original text as [1] =A1=AEingress=A1=AF and =A1=AEegress=A1=AF are = undefined; [2] PCN-ingress-node / PCN-egress-node at least makes it = clear that we=A1=AFre talking about the ingress/egress for this = particular flow ; [3] centralised seems more obvious than standalone to = me (standalone from what? =A1=AEcentralised=A1=AF hints that the same = physical node would be making the decision for every flow, which I guess = is what you have in mind); [4] an alternative would be to write = something like =A1=B0the decision may be made either at either of the = PCN-boundary-nodes relevant for the prospective or actual PCN-flow in = question, or else at a centralised node=A1=B1. But whilst this may be = slightly more exact, I think the meaning is much more obscure.=20 =20 7.5. Flow termination functions: =A1=B0o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the = PCN-ingress-node.=A1=B1 Comment: I suggest we remove the example = sentence in order to avoid misleading. =20 Proposal =A8C leave unaltered. The architecture draft is full of = examples; this is good, as examples help understanding. It is not = misleading. =20 =20 9.1.1. System options: =A1=B0o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). =A1=B1 Comment: I suggest we = replace this sentence by =A1=B0o Where flow admission and termination = decisions are made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). =A1=B1 =20 Proposal =A8C leave unaltered, for the reasons given under 7.4 comment=20 =20 9.5. Security OAM: =A1=B0o A PCN-ingress-node receiving feedback = signals about the pre-congestion level on a non-existent aggregate, or = that are inconsistent with other signals (eg unexpected sequence = numbers, inconsistent addressing, conflicting reports of the = pre-congestion level, etc).=A1=B1 Comment: I suggest we replace the = =A1=B0PCN-ingress-node=A1=B1 by something like =A1=B0The decision point = of admission control or flow termination=A1=B1. =20 Proposal =A8C leave unaltered. As the text above the list of bullets = makes clear, these bullets are a list of examples of the sorts of things = that the security oam should be aware of, so an operator would expect to = adapt the list according to the particular deployment.=20 =20 =20 Thanks phil =20 =20 =20 -----Original Message----- = =20 From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: 12 February 2009 10:03 To: pcn@ietf.org; Ruediger.Geib@telekom.de Cc: Eardley,PL,Philip,CXR9 R Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC =20 Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and = communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the = PCN-decision point to be the PCN ingress node and a stetement, that both = terms are used interchangeably where applicable in the document." =20 I agree with your proposal to add an entry in the terminology defining = the PCN-decision-point (or PCN-decision-node which I prefer). But in = order to make the draft more precise and future-proof, I suggest we use = the terminologies PCN-decision-node and PCN-ingress-node carefully and = precisely. That is to say, when refering to the admission control = functions or the flow termination functions, we use the terminology = PCN-decision-node, and when refering to other functionalities of the = ingress we use terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, = the PCN egress or the centralised node can act as the PCN-decision-node. = However, the current charter of the PCN Working Group assumes only the = PCN ingress act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome. =20 Best Regards, Fortune =20 =20 ________________________________ =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C212=C8=D5 16:36 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; philip.eardley@bt.com; = pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any = details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a = separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node = (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes = following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the = architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard = confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of = either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture = draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of = functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are = not part of the functionalities of the PCN-ingress-node (nor = PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the = PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune =20 ________________________________ =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune ------_=_NextPart_001_01C98D04.7C594224 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks for the feedback on the = architecture draft. The good news is that we=A1=AFre discussing a very small, fine = point. However, this does mean that, I think, we should be cautious about = changes, such as introducing new terminology, especially where everyone is = already clear and in agreement about what the draft means ie that the function making = the decision about admission or termination can be situated in various places = (including a centralised node, which I think is your interest Fortune)..

 

My comments fall somewhere between = the two of you.

 

From a terminology point of view, = there are indeed terms that are defined with respect to physical architecture = (eg PCN-boundary-node) and terms that are defined with respect to functional = architecture (eg PCN-ingress-node). I am very comfortable with this =A8C it reflects = that sometimes the architecture draft wants to talk about the physical & sometimes about functional architecture. I think the terminology = proposal below actually make things worse (eg I can=A1=AFt tell whether your = PCN-decision-node definition is physical or functional, and it refers to PCN ingress and = egress which are not defined.)

 

So I=A1=AFd like to suggest the = following ways of handling your original comments:-

 

6.2.  Flow termination : = =A1=B0In one approach the PCN-egress-node measures the rate of PCN-traffic that is = not excess-traffic-marked, which is the amount of PCN-traffic that can = actually be supported, and communicates this to the PCN-ingress-node.  Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for = this specific PCN-egress-node, and hence it can calculate the excess amount = that should be terminated.=A1=B1 Comment: It is the decision point but not = the ingress node to be communicated by the egress and to decide the amount of = termination.

 

Proposal - Modify the last = sentence: =A1=B0Also the PCN-ingress-node measures the rate of PCN-traffic that is destined = for this specific PCN-egress-node. The difference represents the excess amount = that should be terminated.=A1=B1  

 

6.4.     &n= bsp; Information transport: =A1=B0Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node.=A1=B1 =

 

Proposal =A8C =A1=B0Signalling is = needed to transport PCN-feedback-information, for example to convey the fraction = of PCN-marked traffic from a PCN-egress-node to the relevant = PCN-ingress-node.=A1=B1 (The definition of PCN-feedback-information makes clear that the example = is only an example.)

 

7.4.  Admission control = functions: =A1=B0  There are various possibilities for how the functionality could be = distributed (we assume the operator would configure which is = used):   

 o  The decision is made = at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node.     [etc - cut]

Comment: I would suggest we replace = the view =A1=B0the decision is made at the PCN-ingress-node or = PCN-egress-node or a centralized node=A1=B1 by =A1=B0the decision point may be co-located = with the ingress or egress, or may be deployed on a standalone node=A1=B1.

 

Proposal =A8C leave unaltered. I = find your proposal less clear than the original text as [1] =A1=AEingress=A1=AF = and =A1=AEegress=A1=AF are undefined; [2] PCN-ingress-node / PCN-egress-node at least makes it = clear that we=A1=AFre talking about the ingress/egress for this particular flow ; = [3] centralised seems more obvious than standalone to me (standalone from what? = =A1=AEcentralised=A1=AF hints that the same physical node would be making the decision for every flow, = which I guess is what you have in mind); [4] an alternative would be to write = something like =A1=B0the decision may be made either at either of the = PCN-boundary-nodes relevant for the prospective or actual PCN-flow in question, or else at a = centralised node=A1=B1. But whilst this may be slightly more exact, I think the = meaning is much more obscure.

 

7.5.  Flow termination = functions: =A1=B0o  (if required) Communicate PCN-feedback-information to the node that = makes the flow termination decision.  For example, as in = [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the = PCN-ingress-node.=A1=B1 Comment: I suggest we remove the example sentence in order to avoid = misleading.

 

Proposal =A8C leave unaltered. The architecture draft is full of examples; this is good, as examples help understanding. It is not misleading.  

 

9.1.1.  System options: = =A1=B0o  Where flow admission and termination decisions are made: at = PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node,       see Appendix).  =A1=B1 = Comment: I suggest we replace this sentence by =A1=B0o  Where flow admission = and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = =A1=B1

 

Proposal =A8C leave unaltered, for = the reasons given under 7.4 comment

 

9.5.  Security OAM: = =A1=B0o  A PCN-ingress-node receiving feedback signals about the pre-congestion = level on a non-existent aggregate, or that are inconsistent with other signals (eg = unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc).=A1=B1 Comment: I suggest we replace the = =A1=B0PCN-ingress-node=A1=B1 by something like =A1=B0The decision point of admission control or flow = termination=A1=B1.

 

Proposal =A8C leave unaltered. As = the text above the list of bullets makes clear, these bullets are a list of = examples of the sorts of things that the security oam should be aware of, so an = operator would expect to adapt the list according to the particular deployment. =

 

 

Thanks

phil

 

 

 

-----Original = Message-----          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      
From: Fortune HUANG [mailto:fqhuang@huawei.com]
Sent: 12 February 2009 10:03
To: pcn@ietf.org; Ruediger.Geib@telekom.de
Cc: = Eardley,PL,Philip,CXR9 R
Subject: Re: [PCN] Last = Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to Informational RFC

 

Hi Rudiger,

 

Thank you very much for your answer. Things are = getting clearer to me now.

 

Back to your proposal as = follows:

 

[Rudiger]: "[RG] So I'm open = to something like: .....supported, and communicates this to the = PCN-decision point (which is the PCN ingress node). I'm also open to an entry in the = terminology defining the PCN-decision point to be the PCN ingress node and a = stetement, that both terms are used interchangeably where applicable in the = document."

 

I agree with your proposal to = add an entry in the terminology defining the PCN-decision-point (or PCN-decision-node which I prefer). But in order to make the draft = more precise and future-proof, I suggest we use the terminologies = PCN-decision-node and PCN-ingress-node carefully and precisely. That is to say, when refering to the admission control functions or the flow termination = functions, we use the terminology PCN-decision-node, and when refering to other functionalities of the ingress we use terminology = PCN-ingress-node.

 

Here is my initial text of the definition of PCN-decision-node:

 

   o  = PCN-decision-node: the node that makes admission and flow termination decisions in the PCN domain. Theoretically, the PCN ingress, the PCN egress or the = centralised node can act as the PCN-decision-node. However, the current charter = of the PCN Working Group assumes only the PCN ingress act as the PCN-decision-node.

 

Your comments or revision are very welcome.

 

Best Regards,

Fortune

 

 

=B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C212=C8=D5 16:36
=CA=D5=BC=FE=C8=CB: fqhuang@huawei.com
=B3=AD=CB=CD: = magnus.westerlund@erricson.com; philip.eardley@bt.com; pcn@ietf.org
=D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to Informational RFC

Hi Fortune,

 

of course section 7.2 of the = current architecture does not describe any details of the admission = control. 

Look for  "7.4  Admission control functions" and for = section "6 High level functional architecture" determining =

that the detailed specification of admission control will follow in a separate document.

 

Please carefully read the whole = document before you distribute statements like

 

[Fortune Huang]: "Admission = control functions and Flow termination functions are not part of the = functionalities of the PCN-ingress-node (nor PCN-egress-node in section = 7.3)"

 

The architecture draft clearly = specifies the opposite, as the quotes following below show (I've shortened it all to the relevant text).

 

To answer your question: your understanding is not conforming to the architecture. It is a fact, that admission control is an

ingress node functionality (the = egress node being the only standard = confroming alternative).

Admission Control is an ingress = node functionality which will be specified in detail by a separate document = (egress nodes

are an alternate point for implementation).

"Admission Control" may = of course be a separate logical functionality of either each PCN = ingress or egress node, but it is

part of all physical = devices which are either ingress (or egress) nodes.

 

If the charter is adapted, also centralised approaches may be standardised by IETF.

 

Regards,

 

Rudiger

 

-------------------Quotes from the = PCN architecture draft----------------------------

 

"6.  High-level = functional architecture

 

   The high-level = approach is to split functionality between:

 

   o  = [snip]

 

   o  = PCN-boundary-nodes at the edge of the PCN-domain, which control
      admission of new PCN-flows and = termination of existing PCN-flows,
      based on information from PCN-interior-nodes.  This information is
      in the form of the PCN-marked data = packets (which are intercepted
      by the PCN-egress-nodes) and not = signalling messages.  Generally
      PCN-ingress-nodes are = flow-aware.

[RG: readers, please note that PCN-boundary-nodes are the PCN-ingress

 and the = PCN-egress-node]

 

   The aim of this split = is to keep the bulk of the network simple,
   scalable and robust, whilst confining policy, = application-level and
   security interactions to the edge of the PCN-domain.  = [snip]

 

   The PCN-boundary-nodes monitor the PCN-marked packets in order to
   extract information about the current state of the PCN-domain.  Based
   on this monitoring, a distributed decision is made about = whether to
   admit a prospective new flow or whether to terminate = existing
   flow(s).  Sections 7.4 and 7.5 mention various = possibilities for how
   the functionality could be distributed.

 

6.1.  Flow = admission

 

   = [snip]

   Exactly how the = admission control decision is made will be defined
   separately in informational documents.  =

 


7.4.  Admission control = functions

 

[snip]

 

   There are various possibilities for how the functionality could be
   distributed (we assume the operator would configure which = is used):

 

   o  The decision = is made at the PCN-egress-node and the decision
      (admit or block) is signalled to the PCN-ingress-node.

 

   o  The decision = is recommended by the PCN-egress-node (admit or
      block) but the decision is definitively = made by the PCN-ingress-
      node.  [snip]

 

   o  The decision = is made at the PCN-ingress-node, [snip]

 

   o  The decision = is made at a centralised node (see Appendix).

  

From: Fortune HUANG [mailto:fqhuang@huawei.com]
Sent: Thursday, February = 12, 2009 7:06 AM
To: pcn@ietf.org
Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com
Subject: Re: [PCN] Last = Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to Informational RFC

Hi Rudiger,

 

Thank you very much for your response, but please let me clarify a little = bit.

 

PCN-ingress-node (or = PCN-egress-node) is only = a logical set of functionalities and it is not a physical device.

 

Please refer to section 7.2 in PCN-arch and pay = attention to the fact that the Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3).

 

We can implement both the Admission control functions = and the PCN-ingress-node on the same physical device, but it doesn't change = the fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct?

 

Best Regards,

Fortune

 

=B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46
=CA=D5=BC=FE=C8=CB: fqhuang@huawei.com
=B3=AD=CB=CD: = magnus.westerlund@erricson.com; pcn@ietf.org
=D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to Informational RFC

Hi Fortune,

 

any changes to the formulations you suggest should respect the current WG charter. Please see in line = for details.

 

Regards,

 

Rudiger

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune HUANG
Sent: Wednesday, February = 11, 2009 4:04 AM
To: ietf@ietf.org
Cc: magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: [PCN] Last = Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to Informational RFC

Hi all,

 

There are still some places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" might be misused. Clarification or = editorial changes are required in those places. Please see the detailed comments = below.

 

6.2.  Flow termination : "In = one approach the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can = actually be supported, and communicates this to the = PCN-ingress-node.  Also the PCN-ingress-node = measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be = terminated." Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of = termination. 

 

[RG] The charter says: "To = allow for future extensions to the mechanisms and their application to new = deployment scenarios, they are logically separated into several components, namely, encoding and
transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion information back = to the controlling ingress."  and later:

(5) encoding and transport of (pre-)congestion information between the egress and the controlling = domain ingress

 

[RG] I suggest to leave current = meaning of text of the architecture as it is, which means conforming to the WG = charter.

 

[RG] The charter clearly states, = that currently the only decision point is the ingress node. Your = statement "it is the decision point but not the ingress node to be = communicated by the egress to decide..." raises the impression that the ingress = node can't be the decision point. The charter says exactly the opposite, there's no = other decision point than the ingress node. So if the term "ingress = node" is replaced by the "decision point", we must add some text = clearly stating the the only decision point of this version of the = architecture document is the ingress node.

 

[RG] So I'm open to something like: .....supported, and communicates this to the PCN-decision point (which = is the PCN ingress node). I'm also open to an entry in the terminology defining = the PCN-decision point to be the PCN ingress node and a stetement, that both = terms are used interchangeably where applicable in the = document.

 

 

6.4.       Information transport: = "Signalling is needed to transport PCN-feedback-information between the = PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a = PCN-egress-node to the relevant PCN-ingress-node." Comment: = PCN-feedback-information should transport from the egress to the decision point of admission = control or flow termination. 

 

[RG] See above. 

 

7.4.  Admission control functions: = "  There are various = possibilities for how the functionality could be distributed (we assume the operator would = configure which is used):   

 

 o  The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node.    

 

o  The decision is recommended = by the PCN-egress-node (admit or block) but the decision is definitively made = by the PCN-ingress-node.  The rationale is that the PCN-egress-node naturally has the necessary information about = PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement       point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow.   

 

 o  The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node.  For example, it could signal = the current fraction of PCN-traffic that is PCN-marked.  

 

  o  The decision is made at a = centralised node (see Appendix; beyond scope of current PCN WG = charter).  

 

 Note: Admission control functionality is not = performed by normal PCN-interior-nodes." Comment: I would suggest we replace = the view "the decision is made at the PCN-ingress-node or = PCN-egress-node or a centralized node" by "the decision point may be co-located = with the ingress or egress, or may be deployed on a standalone = node". 

 

[RG] I suggest to leave the = architecture document in a state conforming to the WG charter. As the architecture = document correctly states, centralised decision points are beyond the scope of = the current WG charter. 

 

7.5.  Flow termination functions: = "o  (if required) Communicate PCN-feedback-information to the node that makes the flow termination = decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove = the example sentence in order to avoid misleading.

 

[RG] I think the example is not misleading, as it is in conformance with the current WG = charter.

 

9.1.1.  System options: = "o  Where flow admission and = termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node,       see = Appendix).  " Comment: I suggest we = replace this sentence by "o  Where flow admission and = termination decisions are made: co-located with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "

 

[RG] I prefer the current = statement, as the ingress or egress node being decision points is confoming to the = current charter, whereas a standalone node as a decision point is not = confoming to the current charter. Mentioning a centralised node in brackets is fair, = I think.

 

9.5.  Security OAM: = "o  A PCN-ingress-node receiving = feedback signals about the pre-congestion level on a non-existent aggregate, or = that are inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination". 

 

[RG] see comment at the = top. 

 

 

Best Regards,

Fortune

=00 ------_=_NextPart_001_01C98D04.7C594224-- From toby.moncaster@bt.com Thu Feb 12 03:36:06 2009 Return-Path: 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 8B97028C0E7 for ; Thu, 12 Feb 2009 03:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=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 80GZ9X2XuAVp for ; Thu, 12 Feb 2009 03:36:04 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D405028C12A for ; Thu, 12 Feb 2009 03:36:03 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 11:36:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 11:36:06 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC Thread-Index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQAALmFrAAAueJPQ== References: <4A916DBC72536E419A0BD955EDECEDEC04AD7970@E03MVB1-UKBR.domain1.systemhost.net> From: To: , , , X-OriginalArrivalTime: 12 Feb 2009 11:36:08.0712 (UTC) FILETIME=[19186880:01C98D06] Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:36:06 -0000 I think Phil's proposed "3rd way" is a good compromise as it clarifies = any potential misunderstandings. leaves the architecture flexible enough = to allow for different deployment models yet limits the choices to a = manageable number (something the AD is extremely keen to ensure).=20 My belief is that we need to ensure we don't delay this document any = further than it has already been. recall that this was originally meant = to have been published over a year ago and is already 1 cycle behind on = its current charter milestone date (though that is largely as a result = of the time taken between WGLC and IETF LC). Currently the progress of = several other documents is being delayed as a result of the delays being = experienced by the architecture. What we HAVE to avoid is ending up with = a perfect architecture and system that will never be deployed because we = have dithered for too long and thus missed the opportunity to have it = deployed in the real world. Toby Moncaster -----Original Message----- From: pcn-bounces@ietf.org on behalf of philip.eardley@bt.com Sent: Thu 2/12/2009 11:24 To: fqhuang@huawei.com; pcn@ietf.org; Ruediger.Geib@telekom.de Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-CongestionNotification (PCN) Architecture) to Informational RFC =20 Thanks for the feedback on the architecture draft. The good news is that = we're discussing a very small, fine point. However, this does mean that, = I think, we should be cautious about changes, such as introducing new = terminology, especially where everyone is already clear and in agreement = about what the draft means ie that the function making the decision = about admission or termination can be situated in various places = (including a centralised node, which I think is your interest Fortune).. = =20 My comments fall somewhere between the two of you. =20 >From a terminology point of view, there are indeed terms that are = defined with respect to physical architecture (eg PCN-boundary-node) and = terms that are defined with respect to functional architecture (eg = PCN-ingress-node). I am very comfortable with this - it reflects that = sometimes the architecture draft wants to talk about the physical & = sometimes about functional architecture. I think the terminology = proposal below actually make things worse (eg I can't tell whether your = PCN-decision-node definition is physical or functional, and it refers to = PCN ingress and egress which are not defined.) =20 So I'd like to suggest the following ways of handling your original = comments:- =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination. =20 Proposal - Modify the last sentence: "Also the PCN-ingress-node measures = the rate of PCN-traffic that is destined for this specific = PCN-egress-node. The difference represents the excess amount that should = be terminated." =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node."=20 =20 Proposal - "Signalling is needed to transport PCN-feedback-information, = for example to convey the fraction of PCN-marked traffic from a = PCN-egress-node to the relevant PCN-ingress-node." (The definition of = PCN-feedback-information makes clear that the example is only an = example.)=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. [etc - cut] Comment: I would suggest we replace the view "the decision is made at = the PCN-ingress-node or PCN-egress-node or a centralized node" by "the = decision point may be co-located with the ingress or egress, or may be = deployed on a standalone node". =20 Proposal - leave unaltered. I find your proposal less clear than the = original text as [1] 'ingress' and 'egress' are undefined; [2] = PCN-ingress-node / PCN-egress-node at least makes it clear that we're = talking about the ingress/egress for this particular flow ; [3] = centralised seems more obvious than standalone to me (standalone from = what? 'centralised' hints that the same physical node would be making = the decision for every flow, which I guess is what you have in mind); = [4] an alternative would be to write something like "the decision may be = made either at either of the PCN-boundary-nodes relevant for the = prospective or actual PCN-flow in question, or else at a centralised = node". But whilst this may be slightly more exact, I think the meaning = is much more obscure.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 Proposal - leave unaltered. The architecture draft is full of examples; = this is good, as examples help understanding. It is not misleading. =20 =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 Proposal - leave unaltered, for the reasons given under 7.4 comment=20 =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination". =20 Proposal - leave unaltered. As the text above the list of bullets makes = clear, these bullets are a list of examples of the sorts of things that = the security oam should be aware of, so an operator would expect to = adapt the list according to the particular deployment.=20 =20 =20 Thanks phil =20 =20 =20 -----Original Message----- = =20 From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: 12 February 2009 10:03 To: pcn@ietf.org; Ruediger.Geib@telekom.de Cc: Eardley,PL,Philip,CXR9 R Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC =20 Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and = communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the = PCN-decision point to be the PCN ingress node and a stetement, that both = terms are used interchangeably where applicable in the document." =20 I agree with your proposal to add an entry in the terminology defining = the PCN-decision-point (or PCN-decision-node which I prefer). But in = order to make the draft more precise and future-proof, I suggest we use = the terminologies PCN-decision-node and PCN-ingress-node carefully and = precisely. That is to say, when refering to the admission control = functions or the flow termination functions, we use the terminology = PCN-decision-node, and when refering to other functionalities of the = ingress we use terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, = the PCN egress or the centralised node can act as the PCN-decision-node. = However, the current charter of the PCN Working Group assumes only the = PCN ingress act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome. =20 Best Regards, Fortune =20 =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 ????: 2009?2?12? 16:36 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; philip.eardley@bt.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion = Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any = details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a = separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node = (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes = following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the = architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard = confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of = either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture = draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=FCdiger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of = functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are = not part of the functionalities of the PCN-ingress-node (nor = PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the = PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 ????: 2009?2?11? 23:46 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion = Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune From Ruediger.Geib@telekom.de Thu Feb 12 03:48:37 2009 Return-Path: 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 979C63A68B8 for ; Thu, 12 Feb 2009 03:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=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 QLrRtG0rnPG4 for ; Thu, 12 Feb 2009 03:48:35 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 1F45F28C0FE for ; Thu, 12 Feb 2009 03:48:33 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 12 Feb 2009 12:48:37 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 12:48: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 12:48:35 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5719E93@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQAALmFrAAAueJPQAAjpgA References: <4A916DBC72536E419A0BD955EDECEDEC04AD7970@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 12 Feb 2009 11:48:37.0347 (UTC) FILETIME=[D7510B30:01C98D07] Cc: pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:48:37 -0000 Toby, Phil, it is also my interest to keep the architecture as clear and = non-ambiguous as possible. I agree with Phil's proposal. Regards, Rudiger=20 -----Original Message----- From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20 Sent: Thursday, February 12, 2009 12:36 PM To: philip.eardley@bt.com; fqhuang@huawei.com; pcn@ietf.org; Geib, = R=FCdiger Subject: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-CongestionNotification (PCN) Architecture) to Informational RFC I think Phil's proposed "3rd way" is a good compromise as it clarifies = any potential misunderstandings. leaves the architecture flexible enough = to allow for different deployment models yet limits the choices to a = manageable number (something the AD is extremely keen to ensure).=20 My belief is that we need to ensure we don't delay this document any = further than it has already been. recall that this was originally meant = to have been published over a year ago and is already 1 cycle behind on = its current charter milestone date (though that is largely as a result = of the time taken between WGLC and IETF LC). Currently the progress of = several other documents is being delayed as a result of the delays being = experienced by the architecture. What we HAVE to avoid is ending up with = a perfect architecture and system that will never be deployed because we = have dithered for too long and thus missed the opportunity to have it = deployed in the real world. Toby Moncaster -----Original Message----- From: pcn-bounces@ietf.org on behalf of philip.eardley@bt.com Sent: Thu 2/12/2009 11:24 To: fqhuang@huawei.com; pcn@ietf.org; Ruediger.Geib@telekom.de Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-CongestionNotification (PCN) Architecture) to Informational RFC =20 Thanks for the feedback on the architecture draft. The good news is that = we're discussing a very small, fine point. However, this does mean that, = I think, we should be cautious about changes, such as introducing new = terminology, especially where everyone is already clear and in agreement = about what the draft means ie that the function making the decision = about admission or termination can be situated in various places = (including a centralised node, which I think is your interest Fortune).. = =20 My comments fall somewhere between the two of you. =20 >From a terminology point of view, there are indeed terms that are = defined with respect to physical architecture (eg PCN-boundary-node) and = terms that are defined with respect to functional architecture (eg = PCN-ingress-node). I am very comfortable with this - it reflects that = sometimes the architecture draft wants to talk about the physical & = sometimes about functional architecture. I think the terminology = proposal below actually make things worse (eg I can't tell whether your = PCN-decision-node definition is physical or functional, and it refers to = PCN ingress and egress which are not defined.) =20 So I'd like to suggest the following ways of handling your original = comments:- =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination. =20 Proposal - Modify the last sentence: "Also the PCN-ingress-node measures = the rate of PCN-traffic that is destined for this specific = PCN-egress-node. The difference represents the excess amount that should = be terminated." =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node."=20 =20 Proposal - "Signalling is needed to transport PCN-feedback-information, = for example to convey the fraction of PCN-marked traffic from a = PCN-egress-node to the relevant PCN-ingress-node." (The definition of = PCN-feedback-information makes clear that the example is only an = example.)=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. [etc - cut] Comment: I would suggest we replace the view "the decision is made at = the PCN-ingress-node or PCN-egress-node or a centralized node" by "the = decision point may be co-located with the ingress or egress, or may be = deployed on a standalone node". =20 Proposal - leave unaltered. I find your proposal less clear than the = original text as [1] 'ingress' and 'egress' are undefined; [2] = PCN-ingress-node / PCN-egress-node at least makes it clear that we're = talking about the ingress/egress for this particular flow ; [3] = centralised seems more obvious than standalone to me (standalone from = what? 'centralised' hints that the same physical node would be making = the decision for every flow, which I guess is what you have in mind); = [4] an alternative would be to write something like "the decision may be = made either at either of the PCN-boundary-nodes relevant for the = prospective or actual PCN-flow in question, or else at a centralised = node". But whilst this may be slightly more exact, I think the meaning = is much more obscure.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 Proposal - leave unaltered. The architecture draft is full of examples; = this is good, as examples help understanding. It is not misleading. =20 =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 Proposal - leave unaltered, for the reasons given under 7.4 comment=20 =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination". =20 Proposal - leave unaltered. As the text above the list of bullets makes = clear, these bullets are a list of examples of the sorts of things that = the security oam should be aware of, so an operator would expect to = adapt the list according to the particular deployment.=20 =20 =20 Thanks phil =20 =20 =20 -----Original Message----- = =20 From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: 12 February 2009 10:03 To: pcn@ietf.org; Ruediger.Geib@telekom.de Cc: Eardley,PL,Philip,CXR9 R Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC =20 Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and = communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the = PCN-decision point to be the PCN ingress node and a stetement, that both = terms are used interchangeably where applicable in the document." =20 I agree with your proposal to add an entry in the terminology defining = the PCN-decision-point (or PCN-decision-node which I prefer). But in = order to make the draft more precise and future-proof, I suggest we use = the terminologies PCN-decision-node and PCN-ingress-node carefully and = precisely. That is to say, when refering to the admission control = functions or the flow termination functions, we use the terminology = PCN-decision-node, and when refering to other functionalities of the = ingress we use terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, = the PCN egress or the centralised node can act as the PCN-decision-node. = However, the current charter of the PCN Working Group assumes only the = PCN ingress act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome. =20 Best Regards, Fortune =20 =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 ????: 2009?2?12? 16:36 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; philip.eardley@bt.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion = Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any = details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a = separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node = (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes = following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the = architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard = confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of = either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture = draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=FCdiger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of = functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are = not part of the functionalities of the PCN-ingress-node (nor = PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the = PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 ????: 2009?2?11? 23:46 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion = Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune From Ruediger.Geib@telekom.de Thu Feb 12 03:57:05 2009 Return-Path: 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 CB5F328C0FE for ; Thu, 12 Feb 2009 03:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.086 X-Spam-Level: X-Spam-Status: No, score=0.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 a7bwTXblTHbi for ; Thu, 12 Feb 2009 03:56:49 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id D904C3A685D for ; Thu, 12 Feb 2009 03:56:46 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 12 Feb 2009 12:56:13 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 12:56:13 +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_01C98D08.E6F3D266" Date: Thu, 12 Feb 2009 12:56:12 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5719EB2@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <007101c98cf9$08daeb80$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQAAZw2TA= References: <151C164FE2E066418D8D44D0801543A5719B0E@S4DE8PSAAQA.mitte.t-com.de> <007101c98cf9$08daeb80$7b27460a@china.huawei.com> From: To: X-OriginalArrivalTime: 12 Feb 2009 11:56:13.0518 (UTC) FILETIME=[E73736E0:01C98D08] Cc: pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:57:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98D08.E6F3D266 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Fortune, =20 my reply see in line. =20 Regards,=20 =20 Rudiger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Thursday, February 12, 2009 11:03 AM To: pcn@ietf.org; Geib, R=A8=B9diger Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and = communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the = PCN-decision point to be the PCN ingress node and a stetement, that both = terms are used interchangeably where applicable in the document." =20 [Fortune Huang]: I agree with your proposal to add an entry in the = terminology defining the PCN-decision-point (or PCN-decision-node which = I prefer). But in order to make the draft more precise and future-proof, = I suggest we use the terminologies PCN-decision-node and = PCN-ingress-node carefully and precisely. That is to say, when refering = to the admission control functions or the flow termination functions, we = use the terminology PCN-decision-node, and when refering to other = functionalities of the ingress we use terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, = the PCN egress or the centralised node can act as the PCN-decision-node. = However, the current charter of the PCN Working Group assumes only the = PCN ingress act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome.=20 =20 [RG] I can't support your proposal, as it could raise the impression = that ingress node and decision point are separate entities by using = separate terminology. The architecture as it is by now is formulated = clearly and non ambiguous and in line with the charter. My interest in = standardisation is having standards, which leave no room for = interpretation and what you suggest is introducing terminology which = leaves room for interpretation. =20 So I support the position taken by Phil and Toby, which to me is = absolutely reasonable. =20 =20 Best Regards, Fortune =20 ________________________________ =A1=A4=A1=E91/4t=A8=A8?: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =A1=A4=A1=E9?=A8=AA=A8=BA=A1=C01/4?: 2009?=A8=BA2??12=A8=A8? 16:36 =A8=BA?1/4t=A8=A8?: fqhuang@huawei.com 3-?=A8=AA: magnus.westerlund@erricson.com; philip.eardley@bt.com; = pcn@ietf.org ?=A1=C2=A8=ACa: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any = details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a = separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node = (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes = following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the = architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard = confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of = either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture = draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of = functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are = not part of the functionalities of the PCN-ingress-node (nor = PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the = PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune ________________________________ =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C211=C8=D5 23:46 =CA=D5=BC=FE=C8=CB: fqhuang@huawei.com =B3=AD=CB=CD: magnus.westerlund@erricson.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments = below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates = this to the PCN-ingress-node. Also the PCN-ingress-node measures the = rate of PCN-traffic that is destined for this specific PCN-egress-node, = and hence it can calculate the excess amount that should be terminated." = Comment: It is the decision point but not the ingress node to be = communicated by the egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and=20 transport along forward path from marker to egress, metering of = congestion information at the egress, and transport of congestion = information back to the controlling ingress." and later: (5) encoding and transport of (pre-)congestion information between the = egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not = the ingress node to be communicated by the egress to decide..." raises = the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than = the ingress node. So if the term "ingress node" is replaced by the = "decision point", we must add some text clearly stating the the only = decision point of this version of the architecture document is the = ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also = open to an entry in the terminology defining the PCN-decision point to = be the PCN ingress node and a stetement, that both terms are used = interchangeably where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport = PCN-feedback-information between the PCN-boundary-nodes, for example to = convey the fraction of PCN-marked traffic from a PCN-egress-node to the = relevant PCN-ingress-node." Comment: PCN-feedback-information should = transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator = would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary = information about PCN-marking on the ingress-egress-aggregate, but the = PCN-ingress-node is the policy enforcement point [RFC2753], which = polices incoming traffic to ensure it is part of an admitted PCN-flow. = =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of = PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal = PCN-interior-nodes." Comment: I would suggest we replace the view "the = decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the = ingress or egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG = charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate = PCN-feedback-information to the node that makes the flow termination = decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], = communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid = misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace = this sentence by "o Where flow admission and termination decisions are = made: co-located with PCN-ingress-nodes or co-located with = PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being = decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current = charter. Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are = inconsistent with other signals (eg unexpected sequence numbers, = inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by = something like "The decision point of admission control or flow = termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune ------_=_NextPart_001_01C98D08.E6F3D266 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Fortune,
 
my reply see in line.
 
Regards,
 
Rudiger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Thursday, February 12, 2009 11:03 AM
To: pcn@ietf.org; Geib,=20 Rüdiger
Subject: Re: [PCN] Last Call: = draft-ietf-pcn-architecture=20 (Pre-Congestion Notification (PCN) Architecture) to Informational=20 RFC

Hi=20 Rudiger,
 
Thank you very=20 much for your answer. Things are getting clearer to=20 me now.
 
Back to your proposal as=20 follows:
 
[Rudiger]: "[RG] So I'm open to = something=20 like: .....supported, and communicates this to the PCN-decision point = (which is=20 the PCN ingress node). I'm also open to an entry in the terminology = defining the=20 PCN-decision point to be the PCN ingress node and a stetement, that both = terms=20 are used interchangeably where applicable in the document."
&nbs= p;
 [Fortune Huang]: I agree = with your=20 proposal to add an entry in the terminology defining=20 the PCN-decision-point (or PCN-decision-node which I prefer). But in order to make the draft more = precise and=20 future-proof, I suggest we use the terminologies PCN-decision-node and=20 PCN-ingress-node carefully and precisely. That is to say, when = refering to=20 the admission control functions or the flow termination functions, we = use the=20 terminology PCN-decision-node, and when refering to other = functionalities of the=20 ingress we use terminology=20 PCN-ingress-node.=
 
Here = is my=20 initial text of the definition of=20 PCN-decision-node:
&nbs= p;
   o  PCN-decision-node: the = node that=20 makes admission and flow termination decisions in the PCN=20 domain. Theoretically, the PCN ingress, the PCN egress or the = centralised=20 node can act as the PCN-decision-node. However, the current charter = of the=20 PCN Working Group assumes only the PCN ingress act as the=20 PCN-decision-node.
&nbs= p;
Your=20 comments or revision are very welcome. 
 
[RG] I can't support your proposal, as it = could raise=20 the impression that ingress node and decision point are separate = entities by=20 using separate terminology. The architecture as it is by now is = formulated=20 clearly and non ambiguous and in line with the charter. My interest in=20 standardisation is having standards, which leave no room for = interpretation and=20 what you suggest is introducing terminology which leaves room for=20 interpretation.
 
So I support the position taken by Phil and = Toby, which=20 to me is absolutely reasonable.
 
&nbs= p;
Best=20 Regards,
Fortune
 

·¢¼þÈË: = Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de] =
·¢ËÍʱ¼ä: = 2009Äê2ÔÂ12ÈÕ=20 16:36
ÊÕ¼þÈË: = fqhuang@huawei.com
³­ËÍ:=20 magnus.westerlund@erricson.com; philip.eardley@bt.com;=20 pcn@ietf.org
Ö÷Ìâ: RE: [PCN] Last Call: = draft-ietf-pcn-architecture=20 (Pre-Congestion Notification (PCN) Architecture) to Informational=20 RFC

Hi Fortune,
 
of=20 course section 7.2 of the current architecture does not describe any = details of=20 the admission control. 
Look for  "7.4  Admission = control=20 functions" and for section "6 High = level=20 functional architecture" determining
that the detailed specification of admission = control=20 will follow in a separate document.
 
Please carefully read the whole document = before you=20 distribute statements like
 
[Fortune Huang]: "Admission control functions = and Flow=20 termination functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in = section=20 7.3)"
 
The architecture draft clearly specifies the = opposite,=20 as the quotes following below show (I've = shortened it all=20 to the relevant text).
 
To answer your question: your understanding = is not=20 conforming to the architecture. It is a fact, that admission control is = an=20
ingress node functionality (the egress node = being the=20 only standard=20 confroming alternative).
Admission Control is an ingress node=20 functionality which will be = specified in=20 detail by a separate document (egress nodes =
are an alternate point for implementation).=20
"Admission Control" may of course be a=20 separate logical functionality of either = each PCN ingress or egress node, but it = is=20
part of all physical devices which are = either=20 ingress (or egress) nodes.
 
If the charter is adapted, also centralised = approaches=20 may be standardised by IETF.
 
Regards,
 
Rudiger
 
-------------------Quotes from the PCN = architecture=20 draft----------------------------
 
"6.  High-level functional=20 architecture
 
   The high-level approach is to = split=20 functionality between:
 
   o =20 [snip]
 
   o  PCN-boundary-nodes at = the edge of=20 the PCN-domain, which control
      = admission of new=20 PCN-flows and termination of existing=20 PCN-flows,
      based on information from=20 PCN-interior-nodes.  This information = is
     =20 in the form of the PCN-marked data packets (which are=20 intercepted
      by the PCN-egress-nodes) = and not=20 signalling messages.  Generally
     =20 PCN-ingress-nodes are flow-aware.
[RG: readers, please note that = PCN-boundary-nodes are=20 the PCN-ingress
 and the = PCN-egress-node]
 
   The aim of this split is to keep = the bulk=20 of the network simple,
   scalable and robust, whilst = confining=20 policy, application-level and
   security interactions to = the edge=20 of the PCN-domain.  [snip]
 
   The PCN-boundary-nodes monitor = the=20 PCN-marked packets in order to
   extract information about = the=20 current state of the PCN-domain.  Based
   on this = monitoring,=20 a distributed decision is made about whether to
   admit a=20 prospective new flow or whether to terminate existing
  =20 flow(s).  Sections 7.4 and 7.5 mention various possibilities for=20 how
   the functionality could be=20 distributed.
 
6.1.  Flow=20 admission
 
   = [snip]
   Exactly how the admission = control decision=20 is made will be defined
   separately in informational=20 documents. 
 

7.4. =20 Admission control functions
 
[snip]
 
   There=20 are various possibilities for how the functionality could = be
  =20 distributed (we assume the operator would configure which is = used):
 
  =20 o  The decision is made at the PCN-egress-node and the=20 decision
      (admit or block) is signalled = to the=20 PCN-ingress-node.
 
  =20 o  The decision is recommended by the PCN-egress-node (admit=20 or
      block) but the decision is = definitively=20 made by the PCN-ingress-
     =20 node.  [snip]
 
   o  The decision is made at the=20 PCN-ingress-node, [snip]
 
  =20 o  The decision is made at a centralised node (see = Appendix).
  
=
From: Fortune HUANG = [mailto:fqhuang@huawei.com]=20
Sent: Thursday, February 12, 2009 7:06 AM
To:=20 pcn@ietf.org
Cc: magnus.westerlund@erricson.com; Geib, = Rüdiger;=20 philip.eardley@bt.com
Subject: Re: [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi=20 Rudiger,
 
Thank you=20 very much for your response, but please let me clarify a little=20 bit.
 
PCN-ingress-node=20 (or PCN-egress-node) is only a logical set of functionalities = and=20 it=20 is not a physical device.
 
Please refer to=20 section 7.2 in PCN-arch and pay attention to the fact that the Admission = control=20 functions and Flow termination functions are not part of the = functionalities of=20 the PCN-ingress-node (nor = PCN-egress-node in=20 section 7.3).
 
We can implement both the Admission control = functions=20 and the PCN-ingress-node on the same = physical=20 device, but it doesn't change the fact that the Admission control = functions are=20 not part of the PCN-ingress-node. Is = this=20 understanding correct?
 
Best=20 Regards,
Fortune

发件人: Ruediger.Geib@telekom.de=20 [mailto:Ruediger.Geib@telekom.de] =
发送时间: = 2009年2月11日=20 23:46
收件人: = fqhuang@huawei.com
抄送:=20 magnus.westerlund@erricson.com; pcn@ietf.org
主题: = RE: [PCN] Last Call:=20 draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) = Architecture) to=20 Informational RFC

Hi Fortune,
 
any=20 changes to the formulations you suggest should respect the current = WG=20 charter. Please see in line for details.
 
Regards,
 
Rudiger
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune = HUANG
Sent:=20 Wednesday, February 11, 2009 4:04 AM
To: = ietf@ietf.org
Cc:=20 magnus.westerlund@erricson.com; pcn@ietf.org
Subject: Re: = [PCN] Last=20 Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN)=20 Architecture) to Informational RFC

Hi = all,
 
There are = still some=20 places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" = might be=20 misused. Clarification or editorial = changes are=20 required in those places. Please see the detailed comments=20 below.
 
6.2.  Flow termination : "In one approach the=20 PCN-egress-node measures the rate of PCN-traffic that is not=20 excess-traffic-marked, which is the amount of PCN-traffic that can = actually be=20 supported, and communicates this to the PCN-ingress-node.  Also the = PCN-ingress-node measures the rate of PCN-traffic that is destined for = this=20 specific PCN-egress-node, and hence it can calculate the excess amount = that=20 should be terminated." Comment: It is the decision point but not the = ingress=20 node to be communicated by the egress and to decide the amount of=20 termination. 
 
[RG]=20 The charter says: "To = allow for=20 future extensions to the mechanisms and their application to new = deployment=20 scenarios, they are logically separated into several components, namely, = encoding and
transport along forward path from marker to egress, = metering of=20 congestion information at the egress, and transport of congestion = information=20 back to the controlling ingress."  and later:
(5)=20 encoding and transport of (pre-)congestion information between the = egress and=20 the controlling domain ingress
 
[RG] I=20 suggest to leave current meaning of text of the architecture as it is, = which=20 means conforming to the WG charter.
 
[RG]=20 The charter clearly states, that currently the only decision = point is the=20 ingress node. Your statement "it is the decision point but not the = ingress=20 node to be communicated by the egress to decide..." raises the = impression that=20 the ingress node can't be the decision point. The charter says exactly = the=20 opposite, there's no other decision point than the ingress node. So if = the term=20 "ingress node" is replaced by the "decision point", we must add some = text=20 clearly stating the the only decision point of this version of the=20 architecture document is the ingress node.
 
[RG]=20 So I'm open to something like: .....supported, and communicates this to = the=20 PCN-decision point (which is the PCN ingress node). I'm also open to an = entry in=20 the terminology defining the PCN-decision point to be the PCN ingress = node and a=20 stetement, that both terms are used interchangeably where applicable in = the=20 document.
 
 
6.4.       Information = transport: "Signalling is needed to transport PCN-feedback-information = between=20 the PCN-boundary-nodes, for example to convey the fraction of PCN-marked = traffic=20 from a PCN-egress-node to the relevant PCN-ingress-node." Comment:=20 PCN-feedback-information should transport from the egress to the = decision point=20 of admission control or flow termination. 
 
[RG] See above. 
 
7.4.  Admission control functions: "  = There are=20 various possibilities for how the functionality could be distributed (we = assume=20 the operator would configure which is used):    =
 
 o  The decision is made at the = PCN-egress-node and=20 the decision (admit or block) is signalled to the=20 PCN-ingress-node.    
 
o  The decision is recommended by the = PCN-egress-node=20 (admit or block) but the decision is definitively made by the=20 PCN-ingress-node.  The rationale is that the PCN-egress-node = naturally has=20 the necessary information about PCN-marking on the = ingress-egress-aggregate, but=20 the PCN-ingress-node is the policy=20 enforcement       point [RFC2753], which = polices=20 incoming traffic to ensure it is part of an admitted = PCN-flow.   =20
 
 o  The decision is made at the = PCN-ingress-node,=20 which requires that the PCN-egress-node signals PCN-feedback-information = to the=20 PCN-ingress-node.  For example, it could signal the current = fraction of=20 PCN-traffic that is PCN-marked.  
 
  o  The decision is made at a centralised = node (see=20 Appendix; beyond scope of current PCN WG charter).   =
 
 Note: Admission control functionality is not = performed=20 by normal PCN-interior-nodes." Comment: I would suggest we replace the = view "the=20 decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized=20 node" by "the decision point may be co-located with the ingress or = egress, or=20 may be deployed on a standalone node". 
 
[RG] I=20 suggest to leave the architecture document in a state conforming to the = WG=20 charter. As the architecture document correctly states, centralised = decision=20 points are beyond the scope of the current WG = charter. 
 
7.5.  Flow termination functions: "o  (if = required)=20 Communicate PCN-feedback-information to the node that makes the flow = termination=20 decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],=20 communicate the PCN-egress-node's measurements to the PCN-ingress-node." = Comment: I suggest we remove the example sentence in order to avoid=20 misleading.
 
[RG] I=20 think the example is not misleading, as it is in conformance with the = current WG=20 charter.
 
9.1.1.  System options: "o  Where flow = admission and=20 termination decisions are made: at PCN-ingress-nodes or at = PCN-egress-nodes (or=20 at a centralised node,       see = Appendix). =20 " Comment: I suggest we replace this sentence by "o  Where flow = admission=20 and termination decisions are made: co-located with PCN-ingress-nodes or = co-located with PCN-egress-nodes or at a standalone node (see Appendix). = "
 
[RG] I=20 prefer the current statement, as the ingress or egress node being = decision=20 points is confoming to the current charter, whereas a standalone = node as a=20 decision point is not confoming to the current charter. Mentioning a = centralised=20 node in brackets is fair, I think.
 
9.5.  Security OAM: "o  A PCN-ingress-node = receiving=20 feedback signals about the pre-congestion level on a non-existent = aggregate, or=20 that are inconsistent with other signals (eg unexpected sequence = numbers,=20 inconsistent addressing, conflicting reports of the pre-congestion = level, etc)."=20 Comment: I suggest we replace the "PCN-ingress-node" by something like = "The=20 decision point of admission control or flow termination". 
 
[RG]=20 see comment at the top. 
 
 
Best=20 Regards,
Fortune
------_=_NextPart_001_01C98D08.E6F3D266-- From tom.taylor@rogers.com Sun Feb 15 08:36:28 2009 Return-Path: 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 25E993A696B for ; Sun, 15 Feb 2009 08:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FC8oXC363a6Y for ; Sun, 15 Feb 2009 08:36:27 -0800 (PST) Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by core3.amsl.com (Postfix) with SMTP id E6F333A691D for ; Sun, 15 Feb 2009 08:36:26 -0800 (PST) Received: (qmail 694 invoked from network); 15 Feb 2009 16:36:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Z8RprP2n8uCdh/LViKMvAuA4sGlawC/7xyuZcyXgbz1K4SpS/RSIsf4h9E/XaK+SJs/8hDOEcgn1FXEBZbgrajmLhaxMK6cOHTVmc51AEicRCOK+Z/mixllbU+kRzs8G/4z4O86Tr4MX9fMNXBh6zbiyKK54HKQzZuxscKZxmuE= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp131.rog.mail.re2.yahoo.com with SMTP; 15 Feb 2009 16:36:35 -0000 X-YMail-OSG: cas1zuMVM1mf3CBNoeoiIlfjk4hiPJfqKSb5z.WDvscuLd8qRqqvpIXvyk1poa1PIA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4998448F.50103@rogers.com> Date: Sun, 15 Feb 2009 11:36:31 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Steven Blake References: <1234155132.2998.14.camel@tachyon> In-Reply-To: <1234155132.2998.14.camel@tachyon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] IETF 74 is coming X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 16:36:28 -0000 I am sure we will have a CL edge behaviour draft by the -00 deadline. We have a working version that is still being improved within the informal design team (Michael, Philip, Fortune, myself as editor, Anna, and Daisuke). It is supposed to serve as a prototype for the SM and other drafts. Steven Blake wrote: > IETF 74 is fast approaching. Here are the I-D submission deadlines: > > -00 drafts March 2 > all I-Ds March 9 > > I would like to see new revisions of the marking behavior and baseline > encoding drafts, and well as drafts on our other pending work. > > Unfortunately, I will not make it to San Francisco; Scott will be there > however. > > > Regards, > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From tom.taylor@rogers.com Wed Feb 18 16:33:07 2009 Return-Path: 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 5F16C3A699C for ; Wed, 18 Feb 2009 16:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 9VoUr6YpqWtT for ; Wed, 18 Feb 2009 16:33:06 -0800 (PST) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by core3.amsl.com (Postfix) with SMTP id 6646C3A691E for ; Wed, 18 Feb 2009 16:33:06 -0800 (PST) Received: (qmail 36730 invoked from network); 19 Feb 2009 00:33:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZcZzV6srOHK8QJGYcB0RAQsY/NrXmwOqCguZQw6ROvNBr1Vtb/vX2oBMy45ruDGvvgtgdrhiDLtQD7u6M7VhEWEnE/7dp3nZ2HqZQknm09OKhnqqCDfsjC6DJl5BKNE6gDkXzE/SLAWQXCk6JVH+oJ3sIxLywvUYVu0yrbhXNg4= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 19 Feb 2009 00:33:18 -0000 X-YMail-OSG: KUkxKH8VM1lgTs.p9EjnKfv2Zt7EMFW8Z2qbnK5r_o_HuOAd5tzt_Na85e8z1p1lUA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499CA8CD.90606@rogers.com> Date: Wed, 18 Feb 2009 19:33:17 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <499153FA.6020805@informatik.uni-wuerzburg.de> In-Reply-To: <499153FA.6020805@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] multipath routing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:33:07 -0000 Could you give details of your proposed modification. From private conversation, it requires that only excess-traff-marked flows are terminated when flow termination has to happen. How would these flows be distinguished from the flows that were not excess-traffic-marked? Michael Menth wrote: > Hi all, > > the current PCN architecture does not support multipath routing, i.e. > flows of a single ingress-egress-aggregate can be transmitted over > different paths. With some modifications this support could be possible. > > Is multipath support a desired feature in the future? Or is it of no > interest since PCN is intended to be used only in single-path routing > networks or in combination with MPLS? > > Is multipath routing an issue at all in operational networks? Input from > practitioners is highly appreciated. > > Regards, > > Michael > From tom.taylor@rogers.com Wed Feb 18 17:04:04 2009 Return-Path: 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 7C1783A699C for ; Wed, 18 Feb 2009 17:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74] 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 MbzxgzohgEGP for ; Wed, 18 Feb 2009 17:04:03 -0800 (PST) Received: from smtp114.rog.mail.re2.yahoo.com (smtp114.rog.mail.re2.yahoo.com [68.142.225.230]) by core3.amsl.com (Postfix) with SMTP id 92EEF3A6909 for ; Wed, 18 Feb 2009 17:04:03 -0800 (PST) Received: (qmail 23320 invoked from network); 19 Feb 2009 01:04:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=Fx+LcchIrVHg23su1lyzcWOMrCUxDAtfWFzMIHCDnY4/L1bcrBkwj3HEttIPXWsvUNCetEgCwEu9crX8QwjzO3ZKPd7Cv97k+DhGftZ2csdtrhCkqbptaqkrOW/3jY0Nbgjbtalm5enGfx8RtcQVyUD2/XdzXOKF6tMsSCFrNZ8= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp114.rog.mail.re2.yahoo.com with SMTP; 19 Feb 2009 01:04:16 -0000 X-YMail-OSG: FWsGogwVM1mUNfMmAinAlrAqPCiFin7C_4.ZaNxoYsIWfL0t.MPLwtpnJfU4NP2nVQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <499CB00F.8000801@rogers.com> Date: Wed, 18 Feb 2009 20:04:15 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Michael Menth , pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Oscillation about the admission threshold X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 01:04:04 -0000 In private conversation you have suggested that it might not be desirable to have the system oscillate between "admit" and "block", and have suggested building in an additional CLE threshold for resumption of admission, to provide hysteresis. I suspect that wouldn't alter the essential characteristics of the system. What I might suggest as an alternative is to "put the brakes on" gradually, by defining a range of CLE values. At the lower end of the range, no new flows are blocked. At the upper end, all flows are blocked. In between, the fraction blocked increases linearly. Tom From menth@informatik.uni-wuerzburg.de Wed Feb 18 23:24:09 2009 Return-Path: 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 4097C28C153 for ; Wed, 18 Feb 2009 23:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 XDoxKEZQ28rk for ; Wed, 18 Feb 2009 23:24:08 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CCCD028C148 for ; Wed, 18 Feb 2009 23:24:07 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D417E1990AF; Thu, 19 Feb 2009 08:24:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C6D551990AA; Thu, 19 Feb 2009 08:24:18 +0100 (CET) Received: from [85.176.246.167] (e176246167.adsl.alicedsl.de [85.176.246.167]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 8A1D6A078A; Thu, 19 Feb 2009 08:24:18 +0100 (CET) Message-ID: <499D0921.9010305@informatik.uni-wuerzburg.de> Date: Thu, 19 Feb 2009 08:24:17 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tom Taylor References: <499153FA.6020805@informatik.uni-wuerzburg.de> <499CA8CD.90606@rogers.com> In-Reply-To: <499CA8CD.90606@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] multipath routing 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:24:09 -0000 Hi Tom and all, in case of multipath routing, flows of the same ingress-egress-aggregate can run over different paths. One path may be SR-precongested, the other path not. Then only terminating flows of the SR-precongested path helps and other flows should not be terminated. What's needed is that when an excess-marked packet arrives, the corresponding flow is marked for a while. This information is available at the egress node. There are two alternatives to take advantage of that information: 1) Signalling the IDs of the marked flows to the PCN ingress node which is in charge of termination. 2) Shifting the termination process from the ingress node to the egress node to avoid this signalling. Teardown messages terminate the flows along the path. If direct measured rate termination is used, no PCN signalling is required at all. Note: 1) The unwanted termination of non-marked flows is not a matter of accuracy but collateral damage: without this feature, admitted flows are terminated that do not run over precongested paths. A quantitative analysis of that phenomenon is available in Sect. IV.D of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf 2) For SM, this feature just mitigates the phenomenon of unwanted termination of non-marked flows, but it cannot remove it when one of the paths is AR-precongested and the other is SR-precongested. Regards, Michael Tom Taylor schrieb: > Could you give details of your proposed modification. From private > conversation, it requires that only excess-traff-marked flows are > terminated when flow termination has to happen. How would these flows > be distinguished from the flows that were not excess-traffic-marked? > > Michael Menth wrote: >> Hi all, >> >> the current PCN architecture does not support multipath routing, i.e. >> flows of a single ingress-egress-aggregate can be transmitted over >> different paths. With some modifications this support could be possible. >> >> Is multipath support a desired feature in the future? Or is it of no >> interest since PCN is intended to be used only in single-path routing >> networks or in combination with MPLS? >> >> Is multipath routing an issue at all in operational networks? Input >> from practitioners is highly appreciated. >> >> Regards, >> >> Michael >> -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From menth@informatik.uni-wuerzburg.de Wed Feb 18 23:37:10 2009 Return-Path: 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 EFA3528C185 for ; Wed, 18 Feb 2009 23:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ZoPhJ2AoaLIn for ; Wed, 18 Feb 2009 23:37:10 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 8571B3A6A42 for ; Wed, 18 Feb 2009 23:37:09 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 173D2A0773; Thu, 19 Feb 2009 08:37:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0ACDCA0749; Thu, 19 Feb 2009 08:37:22 +0100 (CET) Received: from [85.176.246.167] (e176246167.adsl.alicedsl.de [85.176.246.167]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CDB381990B4; Thu, 19 Feb 2009 08:37:21 +0100 (CET) Message-ID: <499D0C31.5030106@informatik.uni-wuerzburg.de> Date: Thu, 19 Feb 2009 08:37:21 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tom Taylor References: <499CB00F.8000801@rogers.com> In-Reply-To: <499CB00F.8000801@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Oscillation about the admission threshold 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:37:11 -0000 Hi Tom and all, Tom Taylor schrieb: > In private conversation you have suggested that it might not be > desirable to have the system oscillate between "admit" and "block", This is rather a question than a statement. When the link is operated just below the admissible rate, it may already be overloaded in the next step. Therefore, avoiding such states by blocking as long as the situation is not significantly improved (which is the hysteresis mechanism with two thresholds) would help. > and have suggested building in an additional CLE threshold for > resumption of admission, to provide hysteresis. I suspect that > wouldn't alter the essential characteristics of the system. What I > might suggest as an alternative is to "put the brakes on" gradually, > by defining a range of CLE values. At the lower end of the range, no > new flows are blocked. At the upper end, all flows are blocked. In > between, the fraction blocked increases linearly. This is more complex and leads to similar results. The main matter is at which CLE level to start and at which to stop blocking. That question is the same for the hysteresis mechanism and your proposed solution. In Fig. 10c of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08f.pdf we have shown that the hysteresis mechanism works quite well. Regards, Michael > > Tom -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From karagian@cs.utwente.nl Thu Feb 19 01:12:16 2009 Return-Path: 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 E254F28C1E4 for ; Thu, 19 Feb 2009 01:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 qzQPsANbaqu3 for ; Thu, 19 Feb 2009 01:12:16 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id F2CCD28C0E9 for ; Thu, 19 Feb 2009 01:12:15 -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 n1J9CMmq017351; Thu, 19 Feb 2009 10:12:26 +0100 (MET) From: "Georgios Karagiannis" To: "'Tom Taylor'" , References: <499153FA.6020805@informatik.uni-wuerzburg.de> <499CA8CD.90606@rogers.com> Date: Thu, 19 Feb 2009 10:12:16 +0100 Message-ID: <000601c99272$2d325490$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <499CA8CD.90606@rogers.com> Thread-Index: AcmSKa/yDwcjjHhLR0mvUociM7E+XQAR4msg 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, 19 Feb 2009 10:12:26 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] multipath routing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 09:12:17 -0000 Hi Tom, Hi Michael A solution for the ECMP routing issue, which is identical to the multi-path routing issue, is described in the LC-PCN draft, by using the PCN_Affected_Marking encoding and by supporting the flow termination features (detection and termination) of the excess-traff-marked flows at the egress. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: donderdag 19 februari 2009 1:33 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] multipath routing > > Could you give details of your proposed modification. From > private conversation, it requires that only > excess-traff-marked flows are terminated when flow > termination has to happen. How would these flows be > distinguished from the flows that were not excess-traffic-marked? > > Michael Menth wrote: > > Hi all, > > > > the current PCN architecture does not support multipath > routing, i.e. > > flows of a single ingress-egress-aggregate can be transmitted over > > different paths. With some modifications this support could > be possible. > > > > Is multipath support a desired feature in the future? Or is > it of no > > interest since PCN is intended to be used only in > single-path routing > > networks or in combination with MPLS? > > > > Is multipath routing an issue at all in operational networks? Input > > from practitioners is highly appreciated. > > > > Regards, > > > > Michael > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From sob@harvard.edu Thu Feb 19 18:06:14 2009 Return-Path: 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 5708D3A6A5A for ; Thu, 19 Feb 2009 18:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 20tLFO7PsX2g for ; Thu, 19 Feb 2009 18:06:13 -0800 (PST) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 8CEAA3A6A32 for ; Thu, 19 Feb 2009 18:06:13 -0800 (PST) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 9C9F713B01C6; Thu, 19 Feb 2009 21:06:25 -0500 (EST) To: pcn@ietf.org Message-Id: <20090220020625.9C9F713B01C6@newdev.eecs.harvard.edu> Date: Thu, 19 Feb 2009 21:06:25 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] agenda suggestions for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:06:14 -0000 PCN is currently scheduled for friday morning 9-11:30 let me if you want agenda time & how much tnx Scott From fqhuang@huawei.com Wed Feb 25 19:04:52 2009 Return-Path: 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 612593A68DA for ; Wed, 25 Feb 2009 19:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.428 X-Spam-Level: ** X-Spam-Status: No, score=2.428 tagged_above=-999 required=5 tests=[AWL=1.638, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45] 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 tCWZfD5EowbT for ; Wed, 25 Feb 2009 19:04:50 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 61F973A6844 for ; Wed, 25 Feb 2009 19:04:49 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN00AO1KKK7G@szxga04-in.huawei.com> for pcn@ietf.org; Thu, 26 Feb 2009 11:05:08 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN00A80KKKS3@szxga04-in.huawei.com> for pcn@ietf.org; Thu, 26 Feb 2009 11:05:08 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFN00IG6KKKX9@szxml05-in.huawei.com> for pcn@ietf.org; Thu, 26 Feb 2009 11:05:08 +0800 (CST) Date: Thu, 26 Feb 2009 11:05:07 +0800 From: Fortune HUANG To: pcn@ietf.org Message-id: <001a01c997bf$07abd820$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcmL9W3dG6Kb84lsR0yZlScWwiw5DgAJSjTgAC9TQIAAA7kJUAAB1NfQAALmFrAAAueJPQAAjpgAAhlIRvAAlC4qkA== Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 03:04:52 -0000 Hi all, Below is the email I sent on Feb. 23, saying that I can agree with = Phil's proposal. I am resending this comment since the email was not archived in the PCN = WG email list, sorry to bother phil, toby and Ruediger because you will = receive it again. P.S. I finally found out that when I sent emails to the PCN WG with the = "=B4=F0 =B8=B4:" (the "Re:" in Chinese, which was automatically created by my MS Outlook) in the title, the emails would not be archived to the PCN WG = email list. Best Regards, Fortune -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Fortune HUANG [mailto:fqhuang@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C223=C8=D5 12:13 =CA=D5=BC=FE=C8=CB: 'Ruediger.Geib@telekom.de'; 'toby.moncaster@bt.com'; 'philip.eardley@bt.com' =B3=AD=CB=CD: 'pcn@ietf.org' =D6=F7=CC=E2: =B4=F0=B8=B4: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC Hi Ruediger, Toby, Phil, Sorry to respond to this a little late, but I can also agree with Phil's proposal.=20 Best Regards, Fortune -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de] =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C212=C8=D5 19:49 =CA=D5=BC=FE=C8=CB: toby.moncaster@bt.com; philip.eardley@bt.com =B3=AD=CB=CD: fqhuang@huawei.com; pcn@ietf.org =D6=F7=CC=E2: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC Toby, Phil, it is also my interest to keep the architecture as clear and = non-ambiguous as possible. I agree with Phil's proposal. Regards, Rudiger=20 -----Original Message----- From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] Sent: Thursday, February 12, 2009 12:36 PM To: philip.eardley@bt.com; fqhuang@huawei.com; pcn@ietf.org; Geib, = R=A8=B9diger Subject: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC I think Phil's proposed "3rd way" is a good compromise as it clarifies = any potential misunderstandings. leaves the architecture flexible enough to allow for different deployment models yet limits the choices to a = manageable number (something the AD is extremely keen to ensure).=20 My belief is that we need to ensure we don't delay this document any = further than it has already been. recall that this was originally meant to have = been published over a year ago and is already 1 cycle behind on its current charter milestone date (though that is largely as a result of the time = taken between WGLC and IETF LC). Currently the progress of several other = documents is being delayed as a result of the delays being experienced by the architecture. What we HAVE to avoid is ending up with a perfect = architecture and system that will never be deployed because we have dithered for too = long and thus missed the opportunity to have it deployed in the real world. Toby Moncaster -----Original Message----- From: pcn-bounces@ietf.org on behalf of philip.eardley@bt.com Sent: Thu 2/12/2009 11:24 To: fqhuang@huawei.com; pcn@ietf.org; Ruediger.Geib@telekom.de Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC =20 Thanks for the feedback on the architecture draft. The good news is that we're discussing a very small, fine point. However, this does mean that, = I think, we should be cautious about changes, such as introducing new terminology, especially where everyone is already clear and in agreement about what the draft means ie that the function making the decision = about admission or termination can be situated in various places (including a centralised node, which I think is your interest Fortune)..=20 =20 My comments fall somewhere between the two of you. =20 >From a terminology point of view, there are indeed terms that are = defined with respect to physical architecture (eg PCN-boundary-node) and terms = that are defined with respect to functional architecture (eg = PCN-ingress-node). I am very comfortable with this - it reflects that sometimes the = architecture draft wants to talk about the physical & sometimes about functional architecture. I think the terminology proposal below actually make = things worse (eg I can't tell whether your PCN-decision-node definition is = physical or functional, and it refers to PCN ingress and egress which are not defined.) =20 So I'd like to suggest the following ways of handling your original comments:- =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates this to = the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and = hence it can calculate the excess amount that should be terminated." Comment: It = is the decision point but not the ingress node to be communicated by the = egress and to decide the amount of termination. =20 Proposal - Modify the last sentence: "Also the PCN-ingress-node measures = the rate of PCN-traffic that is destined for this specific PCN-egress-node. = The difference represents the excess amount that should be terminated." =20 =20 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node."=20 =20 Proposal - "Signalling is needed to transport PCN-feedback-information, = for example to convey the fraction of PCN-marked traffic from a = PCN-egress-node to the relevant PCN-ingress-node." (The definition of PCN-feedback-information makes clear that the example is only an = example.)=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. [etc - cut] Comment: I would suggest we replace the view "the decision is made at = the PCN-ingress-node or PCN-egress-node or a centralized node" by "the = decision point may be co-located with the ingress or egress, or may be deployed = on a standalone node". =20 Proposal - leave unaltered. I find your proposal less clear than the original text as [1] 'ingress' and 'egress' are undefined; [2] PCN-ingress-node / PCN-egress-node at least makes it clear that we're talking about the ingress/egress for this particular flow ; [3] = centralised seems more obvious than standalone to me (standalone from what? 'centralised' hints that the same physical node would be making the = decision for every flow, which I guess is what you have in mind); [4] an = alternative would be to write something like "the decision may be made either at = either of the PCN-boundary-nodes relevant for the prospective or actual = PCN-flow in question, or else at a centralised node". But whilst this may be = slightly more exact, I think the meaning is much more obscure.=20 =20 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. =20 Proposal - leave unaltered. The architecture draft is full of examples; = this is good, as examples help understanding. It is not misleading. =20 =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace this = sentence by "o Where flow admission and termination decisions are made: co-located = with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " =20 Proposal - leave unaltered, for the reasons given under 7.4 comment=20 =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination". =20 Proposal - leave unaltered. As the text above the list of bullets makes clear, these bullets are a list of examples of the sorts of things that = the security oam should be aware of, so an operator would expect to adapt = the list according to the particular deployment.=20 =20 =20 Thanks phil =20 =20 =20 -----Original Message----- From: Fortune HUANG [mailto:fqhuang@huawei.com] Sent: 12 February 2009 10:03 To: pcn@ietf.org; Ruediger.Geib@telekom.de Cc: Eardley,PL,Philip,CXR9 R Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC =20 Hi Rudiger, =20 Thank you very much for your answer. Things are getting clearer to me = now. =20 Back to your proposal as follows: =20 [Rudiger]: "[RG] So I'm open to something like: .....supported, and communicates this to the PCN-decision point (which is the PCN ingress = node). I'm also open to an entry in the terminology defining the PCN-decision = point to be the PCN ingress node and a stetement, that both terms are used interchangeably where applicable in the document." =20 I agree with your proposal to add an entry in the terminology defining = the PCN-decision-point (or PCN-decision-node which I prefer). But in order = to make the draft more precise and future-proof, I suggest we use the terminologies PCN-decision-node and PCN-ingress-node carefully and precisely. That is to say, when refering to the admission control = functions or the flow termination functions, we use the terminology = PCN-decision-node, and when refering to other functionalities of the ingress we use = terminology PCN-ingress-node. =20 Here is my initial text of the definition of PCN-decision-node: =20 o PCN-decision-node: the node that makes admission and flow = termination decisions in the PCN domain. Theoretically, the PCN ingress, the PCN = egress or the centralised node can act as the PCN-decision-node. However, the current charter of the PCN Working Group assumes only the PCN ingress = act as the PCN-decision-node.=20 =20 Your comments or revision are very welcome. =20 Best Regards, Fortune =20 =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] ????: 2009?2?12? 16:36 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; philip.eardley@bt.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 of course section 7.2 of the current architecture does not describe any details of the admission control.=20 Look for "7.4 Admission control functions" and for section "6 High = level functional architecture" determining=20 that the detailed specification of admission control will follow in a separate document. =20 Please carefully read the whole document before you distribute = statements like =20 [Fortune Huang]: "Admission control functions and Flow termination = functions are not part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3)" =20 The architecture draft clearly specifies the opposite, as the quotes following below show (I've shortened it all to the relevant text). =20 To answer your question: your understanding is not conforming to the architecture. It is a fact, that admission control is an=20 ingress node functionality (the egress node being the only standard confroming alternative). Admission Control is an ingress node functionality which will be = specified in detail by a separate document (egress nodes=20 are an alternate point for implementation).=20 "Admission Control" may of course be a separate logical functionality of either each PCN ingress or egress node, but it is=20 part of all physical devices which are either ingress (or egress) nodes. =20 If the charter is adapted, also centralised approaches may be = standardised by IETF. =20 Regards, =20 Rudiger =20 -------------------Quotes from the PCN architecture draft---------------------------- =20 "6. High-level functional architecture =20 The high-level approach is to split functionality between: =20 o [snip] =20 o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and not signalling messages. Generally PCN-ingress-nodes are flow-aware. [RG: readers, please note that PCN-boundary-nodes are the PCN-ingress and the PCN-egress-node] =20 The aim of this split is to keep the bulk of the network simple, scalable and robust, whilst confining policy, application-level and security interactions to the edge of the PCN-domain. [snip] =20 The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or whether to terminate existing flow(s). Sections 7.4 and 7.5 mention various possibilities for how the functionality could be distributed. =20 6.1. Flow admission =20 [snip] Exactly how the admission control decision is made will be defined separately in informational documents. =20 =20 7.4. Admission control functions =20 [snip] =20 There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): =20 o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. =20 o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress- node. [snip] =20 o The decision is made at the PCN-ingress-node, [snip] =20 o The decision is made at a centralised node (see Appendix). =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com] Sent: Thursday, February 12, 2009 7:06 AM To: pcn@ietf.org Cc: magnus.westerlund@erricson.com; Geib, R=A8=B9diger; = philip.eardley@bt.com Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Rudiger, =20 Thank you very much for your response, but please let me clarify a = little bit. =20 PCN-ingress-node (or PCN-egress-node) is only a logical set of functionalities and it is not a physical device.=20 =20 Please refer to section 7.2 in PCN-arch and pay attention to the fact = that the Admission control functions and Flow termination functions are not = part of the functionalities of the PCN-ingress-node (nor PCN-egress-node in section 7.3). =20 We can implement both the Admission control functions and the PCN-ingress-node on the same physical device, but it doesn't change the = fact that the Admission control functions are not part of the = PCN-ingress-node. Is this understanding correct? =20 Best Regards, Fortune =20 ________________________________ ???: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] ????: 2009?2?11? 23:46 ???: fqhuang@huawei.com ??: magnus.westerlund@erricson.com; pcn@ietf.org ??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi Fortune, =20 any changes to the formulations you suggest should respect the current = WG charter. Please see in line for details. =20 Regards,=20 =20 Rudiger =20 =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Wednesday, February 11, 2009 4:04 AM To: ietf@ietf.org Cc: magnus.westerlund@erricson.com; pcn@ietf.org Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture = (Pre-Congestion Notification (PCN) Architecture) to Informational RFC Hi all, =20 There are still some places in in draft-ietf-pcn-architecture-09 where = the "ingress/ingress-node" might be misused. Clarification or editorial = changes are required in those places. Please see the detailed comments below. =20 6.2. Flow termination : "In one approach the PCN-egress-node measures = the rate of PCN-traffic that is not excess-traffic-marked, which is the = amount of PCN-traffic that can actually be supported, and communicates this to = the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and = hence it can calculate the excess amount that should be terminated." Comment: It = is the decision point but not the ingress node to be communicated by the = egress and to decide the amount of termination.=20 =20 [RG] The charter says: "To allow for future extensions to the mechanisms = and their application to new deployment scenarios, they are logically = separated into several components, namely, encoding and transport along forward = path from marker to egress, metering of congestion information at the egress, = and transport of congestion information back to the controlling ingress." = and later: (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress =20 [RG] I suggest to leave current meaning of text of the architecture as = it is, which means conforming to the WG charter.=20 =20 [RG] The charter clearly states, that currently the only decision point = is the ingress node. Your statement "it is the decision point but not the ingress node to be communicated by the egress to decide..." raises the impression that the ingress node can't be the decision point. The = charter says exactly the opposite, there's no other decision point than the = ingress node. So if the term "ingress node" is replaced by the "decision point", = we must add some text clearly stating the the only decision point of this version of the architecture document is the ingress node. =20 [RG] So I'm open to something like: .....supported, and communicates = this to the PCN-decision point (which is the PCN ingress node). I'm also open to = an entry in the terminology defining the PCN-decision point to be the PCN ingress node and a stetement, that both terms are used interchangeably = where applicable in the document. =20 =20 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or = flow termination.=20 =20 [RG] See above.=20 =20 7.4. Admission control functions: " There are various possibilities = for how the functionality could be distributed (we assume the operator would configure which is used): =20 =20 o The decision is made at the PCN-egress-node and the decision (admit = or block) is signalled to the PCN-ingress-node. =20 =20 o The decision is recommended by the PCN-egress-node (admit or block) = but the decision is definitively made by the PCN-ingress-node. The = rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is = the policy enforcement point [RFC2753], which polices incoming traffic = to ensure it is part of an admitted PCN-flow. =20 =20 o The decision is made at the PCN-ingress-node, which requires that = the PCN-egress-node signals PCN-feedback-information to the = PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked. =20 =20 o The decision is made at a centralised node (see Appendix; beyond = scope of current PCN WG charter). =20 =20 Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a = centralized node" by "the decision point may be co-located with the ingress or = egress, or may be deployed on a standalone node".=20 =20 [RG] I suggest to leave the architecture document in a state conforming = to the WG charter. As the architecture document correctly states, = centralised decision points are beyond the scope of the current WG charter.=20 =20 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. =20 [RG] I think the example is not misleading, as it is in conformance with = the current WG charter. =20 9.1.1. System options: "o Where flow admission and termination = decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a = centralised node, see Appendix). " Comment: I suggest we replace this = sentence by "o Where flow admission and termination decisions are made: co-located = with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " =20 [RG] I prefer the current statement, as the ingress or egress node being decision points is confoming to the current charter, whereas a = standalone node as a decision point is not confoming to the current charter. = Mentioning a centralised node in brackets is fair, I think. =20 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals = about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion = level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination".=20 =20 [RG] see comment at the top.=20 =20 =20 Best Regards, Fortune