From pcn-bounces@ietf.org Fri Feb 1 02:16:24 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB8A3A68E9; Fri, 1 Feb 2008 02:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.956 X-Spam-Level: * X-Spam-Status: No, score=1.956 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUpxcFuDqkvu; Fri, 1 Feb 2008 02:16:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB2E3A686F; Fri, 1 Feb 2008 02:16:24 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDD83A686F for ; Fri, 1 Feb 2008 02:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiQ2kslqBkw6 for ; Fri, 1 Feb 2008 02:16:21 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id D0FE43A68B5 for ; Fri, 1 Feb 2008 02:16:20 -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 m11ADxsq000310; Fri, 1 Feb 2008 11:14:05 +0100 (MET) From: "Georgios Karagiannis" To: Date: Fri, 1 Feb 2008 11:13:57 +0100 Message-ID: <000d01c864bb$2ad17090$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchkuyfW/SRYnB5hTKGGPg1stQU2Dw== 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]); Fri, 01 Feb 2008 11:14:05 +0100 (MET) Cc: pcn@ietf.org Subject: [PCN] affected marking (or router marking) discussion in pcn architecture draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil As mentioned in http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture-04.tx t Page 33, second bullet, the use of "'Router Marking' or "Affected Marking" can be used to solve the ECMP issue during flow termination. Can you please include this information in the PCN architecture draft, i.e., in the section that discusses the ECMP issue? Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From mailman-bounces@core3.amsl.com Fri Feb 1 06:30:18 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BAC28CBE3 for ; Fri, 1 Feb 2008 06:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV1K61xyJDgF for ; Fri, 1 Feb 2008 06:30:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0CC296B02 for ; Fri, 1 Feb 2008 06:07:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pcn-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:14 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/pcn/pcn-archive%40optimus.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:34:00 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E500293582 for ; Fri, 1 Feb 2008 06:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJR1kKWDfz2J for ; Fri, 1 Feb 2008 06:34:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648162934BF for ; Fri, 1 Feb 2008 06:07:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pcn-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:12 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/pcn/pcn-archive%40optimus.ietf.org From pcn-bounces@ietf.org Sun Feb 3 19:29:30 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24CF3A6DA9; Sun, 3 Feb 2008 19:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXpD7du8eGkw; Sun, 3 Feb 2008 19:29:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE49B3A6DA4; Sun, 3 Feb 2008 19:29:29 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B028D3A6DA2 for ; Sun, 3 Feb 2008 19:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvYRXEiQly3B for ; Sun, 3 Feb 2008 19:29:29 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BE6323A6D99 for ; Sun, 3 Feb 2008 19:29:28 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m143UuW14273; Mon, 4 Feb 2008 03:30:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Feb 2008 22:30:24 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465144EEF3F@zcarhxm1.corp.nortel.com> In-Reply-To: <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: AchfX8pMz1Zsz5/KToesptH3P4qTPAHfTvUA References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> From: "Jozef Babiarz" To: "Lars Eggert" Cc: PCN IETF Subject: Re: [PCN] Architecture draft- bi-directional flows 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org For admission control, the application needs to know that both directions are able to support the new flow before completing the bi-directional flow setup. For flow termination if there are multiple congestion points, termination of bi-directional flows may cause reduction of congestion on other paths. Any mechanisms that attempts to terminal traffic in one step will generally cause over termination (more bi-directional flows are terminated then needed). Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: January 25, 2008 9:37 AM To: Babiarz, Jozef (CAR:0S03) Cc: PCN IETF Subject: Re: [PCN] Architecture draft- bi-directional flows Hi, On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: > I believe that the PCN Architecture draft needs to discuss and explain > how admission control and flow termination works at high level for > telephony and video conferencing applications and that both, telephony > and video conferencing applications have bi-directional flows. For > admission control a new flow can not be admitted unless the traffic > level on both unidirectional paths is below the PCN-lower-rate. As > well > for flow termination, a bi-directional flow is terminated if one of > the > unidirectional paths is in excess of PCN-upper-rate. can you elaborate a bit why something more is needed than simply setting up both directions independently, and failing if that didn't work? Or, for termination, when the app realizes that one direction got torn down, it tears down the other direction? Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Feb 3 19:36:26 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FDB3A6D97; Sun, 3 Feb 2008 19:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9re0bDC2RRY; Sun, 3 Feb 2008 19:36:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A743A6DA1; Sun, 3 Feb 2008 19:36:25 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1B23A6D99 for ; Sun, 3 Feb 2008 19:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UDdiHb+03nF for ; Sun, 3 Feb 2008 19:36:23 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 49BC13A6D86 for ; Sun, 3 Feb 2008 19:36:22 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m143bpW14450; Mon, 4 Feb 2008 03:37:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Feb 2008 22:37:49 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465144EEF41@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1CB7E137@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgARhW3tABQYgmYAEk6VgA References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465142BF191@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1CB7E137@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" Cc: pcn@ietf.org Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ruediger, On section 3.3, yes, we are in agreement. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = Sent: January 29, 2008 3:18 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: AW: [PCN] Review of pcn-architecture-02 draft Joe, my response to two of your comments in line (further down). Where I'm not commenting I accept or agree with your = response. Regards, Ruediger = | -----Urspr=FCngliche Nachricht----- | Von: Jozef Babiarz [mailto:babiarz@nortel.com] = | Gesendet: Montag, 28. Januar 2008 17:42 | An: Geib, R=FCdiger; pcn@ietf.org | Betreff: RE: [PCN] Review of pcn-architecture-02 draft | = | Ruediger, see comments below. | = | Regards, Joe | email:babiarz@nortel.com | Telephone:613-763-6098 | = | -----Original Message----- | From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | Sent: January 17, 2008 5:34 AM | To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org | Subject: AW: [PCN] Review of pcn-architecture-02 draft | = | Hi Joe, | = | some comments on your comments: | = | One general remark is whether we should talk of "interfaces" = | (instead of links) whenever PCN node-functionalities are = | addressed. Up to now, there's a mix in the text. | [Joe] Logically the PCN metering and marking is applied to a = | link between two nodes. Physically, a vendor will implement = | metering and marking on an interface to or from a node. My = | view is that in an architecture document it should be worded = | so that equipment vendors have a choice where they build the = | metering and marking function. = | = | = | You introduce the concept of PCN functionality on either = | incoming or outgoing interfaces. PCN doesn't work, if there's = | a sequence of nodes | = | Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, = | = | there's a link between node 2 and 3 without PCN functionality = | on any interface. So a domain shouldn't mix these nodes. I'd = | prefer PCN functionality on outgoing IF's, if this is closer = | to todays DiffServ implementations. | [Joe] Yes. That is an issue. I'm suggesting that vendor of = | the node specifies on what interface(s) PCN metering and = | marking is supported. | Nodes from different vendors have different metering = | capabilities with metering (token bucket) being most common = | on incoming or ingress interfaces. At lest, I believe that = | the PCN architecture should provide freedom were vendor = | implements the PCN metering and marking function. | Should point out it will also depend on what method the = | vendor chooses to use for metering. If a token bucket = | approach is used than a common place would be ingress = | interface but if virtual queue approach is used than maybe = | egress interface would be the place. A vendor may also = | implement PCN metering and marking on both ingress and egress = | interfaces of a node therefore providing support for PCN on = | links to and from the node. | = | = | More details below. Please note that if I didn't comment a = | change you've proposed, this doesn't indicate agreement. Some = | of your comments aren't easy to understand for me. | = | Regards, | = | Ruediger | = | = | = | = | Terminology | = | [JB]: PCN-domain: a PCN-capable domain; a contiguous set of = | PCN-enabled nodes that provide the PCN function to at least = | one traffic class that is DiffServ scheduling; | = | [RG] if this needs to be changed, what about: | ...PCN-enabled nodes perfoming DiffServ scheduling with PCN = | functionality to the PCN coloured traffic.. | [Joe] I'm OK with above, but would deleted word *coloured*. | = | ------ | = | [JB]: PCN-boundary-node: a PCN-node that connects one = | PCN-domain to a node either in another PCN-domain or in a non = | PCN-domain. | = | PCN-edge-node: a node that is at ingress or egress point to = | the PCN-enabled network. Traffic entering or leaving the PCN = | network passes through it. | Note, | PCN-boundary-node is a special case of PCN-edge-node. | = | [RG]: I don't understand why the terminology is changed in = | the stage we have reached. Has this been agreed in Vancouver? = | I also don't understand the difference between the definitons. | [Joe]My confusion, after reading definition for DS Boundary = | node in RFC2475, I'm OK with using PCN-boundary-node. Please = | add reference to | RFC2475 Section 2.1.1 as definition of boundary-node. | = | ------- | = | 3.1. Assumption 1: Trust and support of PCN function - = | controlled environment | = | [JB]: o Similarly, a PCN-edge-node has to trust that all the = | PCN-nodes mark PCN traffic consistently. A link within the = | PCN-domain wouldn't be able to alert... | = | [RG]: The original sentence "A non-PCN-node within the PCN-domain..." | should | be used. Links aren't able to alert anyway, PCN is a node or = | interface function. This comment applies to all insertions of = | "links" following in | = | this paragraph. | [Joe]How about. "A node performing PCN metering and marking = | within the PCN-domain wouldn't be able to alert that it is = | suffering pre-congestion, which potentially would lead to too = | many PCN-flows being admitted (or too few being terminated)." * [RG] Allright with me. * = | ------- | = | 3.3. Assumption 3: Many flows and additional load | = | [JB]: We do not make explicit assumptions on how many = | PCN-flows are on each bottleneck link. Performance evaluation = | work may clarify whether it is necessary to make any = | additional assumption on aggregation on the bottleneck link. | = | [RG]: This section should stay like it was and discuss the = | PCN assumptions on ingress-egress aggregates. Our assumptions = | on aggregation on links are discussed in the preceding = | section and any necessary changes regarding link aggregation = | should be added there. | [Joe] My interpolation is that Assumption 3 is about = | aggregate at the point where the PCN metering and marking = | function is performed and not how many flows belong to an = | ingress-egress aggregate. These are different issues. = | = * [RG] I understand your comment and your point of view, I think. = "The original text referring to ingress-egress aggregates = doesn't fit to this section" is what you say, isn't it? This = is because this section is limited to traffic conditions at = marking and metering nodes. The remark about ingress egress aggregates may better fit to = e.g. section 4. The assumptions and relevance we make on = ingress egress aggregates needs to stay in the draft, but = you are right that this doesn't fit well to 3.3. End of my comments in this mail * | --------- | = | 4.1. Flow admission | = | [JB]the algorithm: a PCN-node meters the amount of = | PCN-traffic on a link (on its incoming or outgoing links). = | The measurement is made as an aggregate of all PCN-packets on = | that link, and not per flow. | = | [RG]: please change to | .... on each of its incoming or outgoing links... | and leave the orinial text: ...on each one of its links, and not... | If it should be emphasised that this is done per link aggregate: | ...on each single one of its links, and not.. | = | ________________________________ | = | Von: Jozef Babiarz [mailto:babiarz@nortel.com] = | Gesendet: Dienstag, 1. Januar 2008 21:03 | An: PCN IETF | Betreff: [PCN] Review of pcn-architecture-02 draft | = | = | = | Hi Phil, | = | The link below provides my detailed comments = | and suggested new text for draft-ietf-pcn-architecture-02. | = | Currently, my review covers, Section 1 through end of = | 5. New text to be added is underlined and text to be deleted = | is crossed out. = | = | = | http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc | | = | = | = | http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf | | = | = | Changes of note: | = | - On terminology, changed PCN-boundary-node to PCN-edge-node. = | = | - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. | = | - The changes in Section 5.7 on Tunneling that I made = | are with the assumption that PCN marking will be conformant = | to RFC 4774, Specifying Alternate Semantics for the Explicit = | Congestion Notification | (ECN) Field. | = | - Most of the other changes through out the draft are editorial. | = | I will send comments on remaining of the draft, Section = | 6 to end in few days. | = | Happy New Year! | = | Regards, Joe | = | email:babiarz@nortel.com | = | Telephone:613-763-6098 | = | = _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Feb 3 20:10:18 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93103A6D9A; Sun, 3 Feb 2008 20:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1V7rY2H6lla; Sun, 3 Feb 2008 20:10:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D822C3A6D86; Sun, 3 Feb 2008 20:10:14 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F16C3A6CEC for ; Sun, 3 Feb 2008 20:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPIL-E6l+svV for ; Sun, 3 Feb 2008 20:10:06 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 754A63A6D97 for ; Sun, 3 Feb 2008 20:10:06 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m144Bbu04716; Mon, 4 Feb 2008 04:11:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Feb 2008 23:11:35 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465144EEF52@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gVv4umgARvLrOA= References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: multipart/mixed; boundary="===============1149408396==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1149408396== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C866E4.09086DB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C866E4.09086DB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil,=20 I'm OK with PCN-boundary-node as long as we use the definition of boundary-node as in RFC2475 Section 2.1.1 and add the PCN stuff to it. =20 The reason why I'm suggesting that "aggregated" be deleted because in those parts it's not needed. The interior-nodes have no view of number of flows. =20 At the PCN-egress node, there are two approaches to measure or detect level of pre-congestion, one approach is to measure rate of marked or unmarked traffic and with this approach the level of ingress-egress aggregation is impotent. The second approach is to simply look at the marking and report it to ingress or the centralized entity, which does not have any dependency on level of ingress-egress aggregation. I think the architecture draft should be written so it can accommodate both approaches.=20 =20 Yes, S5 were the last changes that I sent you. Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: January 29, 2008 7:28 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: RE: [PCN] Review of pcn-architecture-02 draft =20 Joe =20 I'm now updating the architecture draft. Thanks for your comments! =20 Some initial questions: =20 - you used the term 'PCN-edge-node' (rather than PCN-boundary-node) with a new definition. I didn't understand why - in particular I didn't understand what the substantive difference is between the 2 definitions - in the abstract, you changed "..architecture for flow admission and termination based on aggregated pre-congestion information..." by deleting "aggregated". You also made similar change at several places in the doc, eg possibility of PCN-egress-node making measurements per flow (rather than per aggregate). My proposal: to leave the draft as it is, however there'll be a new section called something like "Beyond the current PCN charter" where I'll mention the per flow stuff. Steve Blake recommended (off list) to have such a section, and I'm going to move all the comments about charter scope to this new section. I think your per flow stuff will fit best there. Stokes, Deborah (RICH2:1A00)=20 More later =20 Thanks phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 Hi Phil, The link below provides my detailed comments and suggested new text for draft-ietf-pcn-architecture-02. Currently, my review covers, Section 1 through end of 5. New text to be added is underlined and text to be deleted is crossed out.=20 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf Changes of note: - On terminology, changed PCN-boundary-node to PCN-edge-node.=20 - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. - The changes in Section 5.7 on Tunneling that I made are with the assumption that PCN marking will be conformant to RFC 4774, Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. - Most of the other changes through out the draft are editorial. I will send comments on remaining of the draft, Section 6 to end in few days. Happy New Year! Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C866E4.09086DB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

Phil,

I’m OK with PCN-boundary-node = as long as we use the definition of boundary-node as in RFC2475 Section = 2.1.1 and add the PCN stuff to it.

 

The reason why I’m suggesting = that “aggregated” be deleted because in those parts it’s not needed. The = interior-nodes have no view of number of flows.

 

At the PCN-egress node, there are = two approaches to measure or detect level of pre-congestion, one approach is = to measure rate of marked or unmarked traffic and with this approach the = level of ingress-egress aggregation is impotent. The second approach is to simply look at the = marking and report it to ingress or the centralized entity, which does not have any = dependency on level of ingress-egress aggregation. I think the architecture draft = should be written so it can accommodate both approaches. =

  

Yes, S5 were the last changes that = I sent you.

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: January 29, 2008 = 7:28 AM
To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org
Subject: RE: [PCN] Review = of pcn-architecture-02 draft

 

Joe=

 

I’m now = updating the architecture draft. Thanks for your comments!

 

Some initial = questions:

 

- you used the = term ‘PCN-edge-node’ (rather than PCN-boundary-node) with a new definition. I didn’t understand why – in particular I = didn’t understand what the substantive difference is between the 2 = definitions

- in the = abstract, you changed “..architecture for flow admission and termination based = on aggregated pre-congestion information…” by deleting “aggregated”. You also made similar change at several places = in the doc, eg possibility of PCN-egress-node making measurements per flow = (rather than per aggregate). My proposal: to leave the draft as it is, however there’ll be a new section called something like “Beyond the = current PCN charter” where I’ll mention the per flow stuff. Steve = Blake recommended (off list) to have such a section, and I’m going to = move all the comments about charter scope to this new section. I think your per = flow stuff will fit best there.

Stokes, Deborah (RICH2:1A00) 

More = later

 

Thanks

phil

 

-----Original Message-----
From: Jozef Babiarz = [mailto:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [PCN] Review of = pcn-architecture-02 draft

 

Hi Phil,

The link below provides my detailed comments and suggested new text for draft-ietf-pcn-architecture-02.

Currently, my review covers, Section 1 through end of 5. New text to be added is underlined and text to be deleted is crossed out.

http://standards.nortel.com/= pcn/draft-ietf-pcn-architecture-02-jb.doc=

http://standards.nortel.com/= pcn/draft-ietf-pcn-architecture-02-jb.pdf

Changes of note:

- On terminology, changed PCN-boundary-node to PCN-edge-node. =

- Made several changes in Section 5.2, 5.3, 5.4 and 5.5.

- The changes in Section 5.7 on Tunneling that I made are with the assumption = that PCN marking will be conformant to RFC 4774, Specifying Alternate = Semantics for the Explicit Congestion Notification (ECN) Field.

- Most of the other changes through out the draft are = editorial.

I will send comments on remaining of the draft, Section 6 to end in few = days.

Happy New Year!

Regards, = Joe

email:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C866E4.09086DB2-- --===============1149408396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --===============1149408396==-- From pcn-bounces@ietf.org Sun Feb 3 20:21:06 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5143A6CD5; Sun, 3 Feb 2008 20:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCoCjfc8W4Q5; Sun, 3 Feb 2008 20:21:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BE83A6D99; Sun, 3 Feb 2008 20:21:05 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1AA3A6D99 for ; Sun, 3 Feb 2008 20:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDVqhH4XmhOW for ; Sun, 3 Feb 2008 20:21:03 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id ABF9F3A6CD5 for ; Sun, 3 Feb 2008 20:21:03 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m144MYv00757; Mon, 4 Feb 2008 04:22:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Feb 2008 23:22:32 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465144EEF56@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34504@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: AchfX9C1CRKalIWVQRSqH1x2AYFUawDIf8FQARinghA= References: <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34504@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , Cc: pcn@ietf.org Subject: Re: [PCN] Architecture draft- bi-directional flows 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, I'm OK with description of bi-directional flows in Section 6. My comment to Lars and PCN WG is that bi-directional flows have additional requirements that both admission control and flow termination mechanism need to accommodate. I believe that the different PCN marking drafts need to explain how their proposed mechanism works with bi-directional flows. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: January 29, 2008 9:21 AM To: lars.eggert@nokia.com; Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Architecture draft- bi-directional flows Note, bi-directional flows are discussed in the arch draft already. Section 6, http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#page-24 says o Bi-Directional Sessions: Many applications have bi-directional sessions - hence there are two flows that should be admitted (or terminated) as a pair - for instance a bi-directional voice call only makes sense if flows in both directions are admitted. However, PCN's mechanisms concern admission and termination of a single flow, and coordination of the decision for both flows is a matter for the signalling protocol and out of scope of PCN. One possible example would use SIP pre-conditions; there are others. Hopefully this is enough? > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 25 January 2008 14:37 > To: ext Jozef Babiarz > Cc: PCN IETF > Subject: Re: [PCN] Architecture draft- bi-directional flows > > Hi, > > On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: > > I believe that the PCN Architecture draft needs to discuss and explain > > how admission control and flow termination works at high level for > > telephony and video conferencing applications and that both, telephony > > and video conferencing applications have bi-directional flows. For > > admission control a new flow can not be admitted unless the traffic > > level on both unidirectional paths is below the PCN-lower-rate. As > > well > > for flow termination, a bi-directional flow is terminated if one of > > the > > unidirectional paths is in excess of PCN-upper-rate. > > can you elaborate a bit why something more is needed than simply > setting up both directions independently, and failing if that didn't > work? Or, for termination, when the app realizes that one direction > got torn down, it tears down the other direction? > > Lars > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 00:28:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA2F3A6A25; Mon, 4 Feb 2008 00:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb-5Gf6J2OMN; Mon, 4 Feb 2008 00:28:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E331D3A6DB4; Mon, 4 Feb 2008 00:28:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171C03A6DB4 for ; Mon, 4 Feb 2008 00:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DGLifj5yrmk for ; Mon, 4 Feb 2008 00:28:51 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 336F43A6A25 for ; Mon, 4 Feb 2008 00:28:51 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m148UeMO007054; Mon, 4 Feb 2008 02:31:31 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:30:09 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:30:09 +0200 Received: from esdhcp03637.research.nokia.com ([172.21.36.37]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:30:08 +0200 Message-Id: <0CD6DF87-AD10-4BB1-96BB-98FFA054F180@nokia.com> From: Lars Eggert To: ext Jozef Babiarz In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465144EEF3F@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 4 Feb 2008 10:30:07 +0200 References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> <9671A92C3C8B5744BC97F855F7CB6465144EEF3F@zcarhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 04 Feb 2008 08:30:09.0180 (UTC) FILETIME=[270075C0:01C86708] X-Nokia-AV: Clean Cc: PCN IETF Subject: Re: [PCN] Architecture draft- bi-directional flows 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 2008-2-4, at 5:30, ext Jozef Babiarz wrote: > For admission control, the application needs to know that both > directions are able to support the new flow before completing the > bi-directional flow setup. The way in which an application learns whether the path can support a flow is by trying to set it up. Either admission succeeds or it doesn't. For a bi-directional flow, it tries to set up both directions, and uses them if both setups succeed. I don't understand how an application would get information about whether an intended flow setup can succeed *before* attempting to set it up. > For flow termination if there are multiple congestion points, > termination of bi-directional flows may cause reduction of > congestion on > other paths. Any mechanisms that attempts to terminal traffic in one > step will generally cause over termination (more bi-directional flows > are terminated then needed). I think you argue here that PCN should have a mechanism to identify flows that are part of a bidirectional flow pair, and use that information in its termination decision. (With the assumption that tearing down one half of a flow pair will free up capacity in the other direction, too.) This seems to be an optimization of the flow termination scheme that hasn't seen much discussion in the WG so far, and the implication on the architecture are pretty complex. I also question the need to engineer such complex termination mechanisms in the first place - termination is a last resort to shed load, and optimizing its behavior doesn't seem critical. If you need to terminate, things have gone pretty badly within the PCN domain already, so its questionable if the PCN state is even accurate enough to allow any sort of intelligent behavior. Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 00:34:00 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA03A3A6E09; Mon, 4 Feb 2008 00:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkYYRs-kPPhg; Mon, 4 Feb 2008 00:34:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F5E3A6DFA; Mon, 4 Feb 2008 00:33:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF7C3A6DF8 for ; Mon, 4 Feb 2008 00:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVxyOVnSa7UQ for ; Mon, 4 Feb 2008 00:33:57 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2D8F93A6E2D for ; Mon, 4 Feb 2008 00:32:15 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m148XhS6024055; Mon, 4 Feb 2008 10:33:44 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:33:34 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:33:34 +0200 Received: from esdhcp03637.research.nokia.com ([172.21.36.37]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:33:34 +0200 Message-Id: From: Lars Eggert To: ext Jozef Babiarz In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465144EEF52@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 4 Feb 2008 10:33:32 +0200 References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB6465144EEF52@zcarhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 04 Feb 2008 08:33:34.0384 (UTC) FILETIME=[A1501B00:01C86708] X-Nokia-AV: Clean Cc: pcn@ietf.org Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 2008-2-4, at 6:11, ext Jozef Babiarz wrote: > The reason why I'm suggesting that "aggregated" be deleted because in > those parts it's not needed. The interior-nodes have no view of number > of flows. And that's why the mechanisms operate on aggregated information, rather than on per-flow information. PCN is all about marking volume vs. traffic volume - no decisions are made based on individual flow characteristics. Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 05:01:35 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529153A6EF7; Mon, 4 Feb 2008 05:01:35 -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 core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-IvgGy-JSHB; Mon, 4 Feb 2008 05:01:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768703A6E88; Mon, 4 Feb 2008 05:01:34 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3FC3A6E86 for ; Mon, 4 Feb 2008 05:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d96nXoV3ps6t for ; Mon, 4 Feb 2008 05:01:31 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1F4113A6E75 for ; Mon, 4 Feb 2008 05:01:30 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 13:03:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 13:03:02 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3452A@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000d01c864bb$2ad17090$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: affected marking (or router marking) discussion in pcn architecture draft Thread-Index: AchkuyfW/SRYnB5hTKGGPg1stQU2DwCcmSVg From: To: X-OriginalArrivalTime: 04 Feb 2008 13:03:03.0582 (UTC) FILETIME=[46E7EBE0:01C8672E] Cc: pcn@ietf.org Subject: Re: [PCN] affected marking (or router marking) discussion in pcn architecture draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios Please note the following text in S6 < The following are open issues. They are mainly taken from [I-D.briscoe-tsvwg-cl-architecture] which also describes some possible solutions. Note that some may be considered unimportant in general or in specific deployment scenarios or by some operators. NOTE: Potential solutions are out of scope for this document. > So I don't think it's right to include your statement below, as it's in solution space. As a side note, I think I remember that affected marking is done when an interface is 'admission marking' pkts (rather than when an interface is 'termination marking pkts). In that case, affected marking tackles the ecmp issue for flow admission (rather than for flow termination). phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 01 February 2008 10:14 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: affected marking (or router marking) discussion in pcn > architecture draft > > Hi Phil > > As mentioned in > http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture- > 04.tx > t > Page 33, second bullet, the use of "'Router Marking' or "Affected Marking" > can be used > to solve the ECMP issue during flow termination. > > Can you please include this information in the PCN architecture draft, > i.e., > in the section that > discusses the ECMP issue? > > > Best regards, > Georgios > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 06:26:57 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC2A3A6F4F; Mon, 4 Feb 2008 06:26:57 -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 core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACa8z6jpfYZ6; Mon, 4 Feb 2008 06:26:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26923A6DAA; Mon, 4 Feb 2008 06:26:56 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7030A3A6D2D for ; Mon, 4 Feb 2008 06:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGzkcz8i77gN for ; Mon, 4 Feb 2008 06:26:54 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1E19D3A6DFE for ; Mon, 4 Feb 2008 06:26:17 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 14:27:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 14:27:49 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3452F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchnCLR8SDTEpX1NSSizZwRRzl6tvQAKg4xg From: To: , X-OriginalArrivalTime: 04 Feb 2008 14:27:50.0706 (UTC) FILETIME=[1F117120:01C8673A] Cc: pcn@ietf.org Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Yes, the interior nodes only know about aggregated traffic. The architecture draft is clear, eg S1: o The PCN-marking behaviours only operate on the overall PCN-traffic on the link, not per flow. Yes, edge nodes (potentially) can base admission/termination decisions on aggregated traffic or an individual flow, based on the PCN marked pkts they see. The architecture draft tries to outline both possibilities. In the update I'm working on, I've tried to do some minor mods in a few places, on the lines you suggested Joe (in your edited doc on the Nortel website). Phil/ > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 04 February 2008 08:34 > To: ext Jozef Babiarz > Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Review of pcn-architecture-02 draft > > On 2008-2-4, at 6:11, ext Jozef Babiarz wrote: > > The reason why I'm suggesting that "aggregated" be deleted because in > > those parts it's not needed. The interior-nodes have no view of number > > of flows. > > And that's why the mechanisms operate on aggregated information, > rather than on per-flow information. PCN is all about marking volume > vs. traffic volume - no decisions are made based on individual flow > characteristics. > > Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 08:56:29 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0B93A6C70; Mon, 4 Feb 2008 08:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htEddjcbL9D6; Mon, 4 Feb 2008 08:56:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40673A6D22; Mon, 4 Feb 2008 08:56:28 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C233A6D22 for ; Mon, 4 Feb 2008 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+P7oHYGdx71 for ; Mon, 4 Feb 2008 08:56:26 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A5C833A6C70 for ; Mon, 4 Feb 2008 08:56:26 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m14Gw0iO016062 for ; Mon, 4 Feb 2008 10:58:00 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:58:00 -0600 Received: from [147.117.169.111] ([147.117.169.111]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 10:57:59 -0600 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Mon, 04 Feb 2008 11:57:59 -0500 Message-Id: <1202144279.3143.14.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 04 Feb 2008 16:57:59.0792 (UTC) FILETIME=[18E6DF00:01C8674F] Subject: [PCN] Draft deadlines 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org A friendly reminder: Initial (-00) drafts must be submitted no later than Monday, February 18 at 1700 EST. Pre-approval notification of -00 working group drafts by the working group chairs is appreciated by Monday, February 11 at 1700 EST. Non -00 draft submission cut-off is Monday, February 25 at 1700 EST. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 4 10:43:07 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29C63A7018; Mon, 4 Feb 2008 10:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, HTML_MESSAGE=1, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ2sywv+Pdxb; Mon, 4 Feb 2008 10:43:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4751A3A6FB5; Mon, 4 Feb 2008 10:43:01 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9413A6C7A for ; Mon, 4 Feb 2008 10:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Fnv-phsDMV for ; Mon, 4 Feb 2008 10:42:46 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 904933A6FB5 for ; Mon, 4 Feb 2008 10:42:45 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 18:44:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 18:44:17 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34533@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CB7E9A1@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWr7SMwAB6IdPAA3+hKgA== From: To: X-OriginalArrivalTime: 04 Feb 2008 18:44:18.0454 (UTC) FILETIME=[F2E17360:01C8675D] Cc: pcn@ietf.org Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: multipart/mixed; boundary="===============1989127003==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1989127003== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8675D.F2870B2F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8675D.F2870B2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ruediger =20 Yes, pcn pkts can be tunnelled across a non-pcn region, and the original pcn marking correctly recovered on decapsulation. However, for pcn to operate you're assuming that the non-pcn region cannot ever suffer problems, eg become congested. I think this is all captured in S3.1, which is about the restrictions imposed by the Charter (and principles of MBAC): =20 We assume that the PCN-domain is a controlled environment, i.e. all the nodes in a PCN-domain run PCN and trust each other. There are several reasons for proposing this assumption: =20 ... =20 o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes are doing PCN-marking. A non PCN-node wouldn't be able to alert that it is suffering pre-congestion, which potentially would lead to too many PCN-flows being admitted (or too few being terminated). Worse, a rogue node could perform various attacks, as discussed in the Security Considerations section. =20 ... Note: All PCN-nodes need to be trustworthy. However if it's known that an interface cannot become pre-congested then it's not strictly necessary for it to be capable of PCN-marking. But this must be known even in unusual circumstances, eg after the failure of some links. =20 [joe asked for some tweaking of this last para, and I'm toying with putting a mention of the issue somewhere else eg OAM section] =20 But the basic point is: a non-PCN region makes scenarios are interesting but not in the current work scope. so we shouldn't worry about them at the moment. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 31 January 2008 08:36 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] Review of pcn-architecture-02 draft =20 Phil, =20 if the PCN domain spans across an embedded non PCN domain, then the PCN marked packets may be tunneled without the outer header supporting PCN while the PCN marks of the inner header should be left unchanged. Examples are: =20 - backbone transit using a carrier IP VPN service - a business access connected via L2TP over DSL =20 In both cases the carrier providing connectivity may not support PCN, but the end point using that carrier connectivity product may be in a PCN domain. It is important that the tunnel starts and ends in the same PCN domain (which holds for the given examples). Once the charter allows for extended discussion, the tunnel may also connect two PCN domains. =20 This scenario should be supported, I support Joe's view. Picking up Joe's drafted text, what about the following (my changes marked): =20 A PCN domain may expand over a non PCN domain and wish to tunnel PCN-traffic across this non-PCN-capable domain. The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by encapsulating PCN packets with an outer header that does not support PCN. In this mode on decapsulation, the inner PCN-capable header is used without modification. =20 Deletions are hard to mark, that's why I highlighted "PCN". =20 I think, the scenario is somewhat similar to passing a non PCN capable node (without a tunnel) in a PCN domain. =20 Regards, Ruediger =20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, January 30, 2008 7:45 PM To: babiarz@nortel.com; pcn@ietf.org Subject: RE: [PCN] Review of pcn-architecture-02 draft Joe =20 You make some comments on Section 5.7 Tunnelling, which I didn't really understand. =20 After=20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. =20 You deleted this: The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by doing the PCN-colour function (Section 5.3 ) after all the other (PCN and tunnelling) functions. Why? Is this because you thought it too detailed to bother saying? Or because you think PCN-colouring isnt needed? If the latter, this is an argument about encoding - in which case I'll ignore the issue until the encoding draft is done.=20 =20 You added: Also operator may wish to tunnel PCN-traffic across a non-PCN-capable domain. The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by encapsulating PCN packets with an outer header that does not support the PCN function (tunnel). In this mode on decapsulation, the inner PCN-capable header is used without modification. I don't agree with this. if you send PCN-traffic outside the PCN-domain then it's no longer PCN-traffic.=20 =20 You made a lot of changes to the text about "partially PCN-capable tunnel", ie where only one tunnel endpoint is in the PCN domain Partly I think this is to do with encoding (again, I propose to park the text until the encoding draft has progressed).=20 However: In the case "1. The tunnel starts outside a PCN-domain and finishes inside it." You wrote: For this scenario when the tunnel ends, the PCN-ingress node function must be performed after decapsulation of packet. I don't agree. The main ingress functions like policing have to be done at the PCN-boundary-node. =20 Thanks, phil =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 Hi Phil, The link below provides my detailed comments and suggested new text for draft-ietf-pcn-architecture-02. Currently, my review covers, Section 1 through end of 5. New text to be added is underlined and text to be deleted is crossed out.=20 =09 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc =09 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf Changes of note: - On terminology, changed PCN-boundary-node to PCN-edge-node.=20 - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. - The changes in Section 5.7 on Tunneling that I made are with the assumption that PCN marking will be conformant to RFC 4774, Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. - Most of the other changes through out the draft are editorial. I will send comments on remaining of the draft, Section 6 to end in few days. Happy New Year! Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C8675D.F2870B2F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

Hi Ruediger

 

Yes, pcn pkts can be tunnelled = across a non-pcn region, and the original pcn marking correctly recovered on = decapsulation. However, for pcn to operate you’re assuming that the non-pcn = region cannot ever suffer problems, eg become congested. I think this is all = captured in S3.1, which is about the restrictions imposed by the Charter (and = principles of MBAC):

 

   We assume that the PCN-domain is =
a controlled environment, i.e. all
   the nodes in a PCN-domain run =
PCN and trust each other.  There are
   several reasons for proposing =
this assumption:
 
   =
...
 
   o  Similarly, a =
PCN-boundary-node has to trust that all the =
PCN-nodes
      are doing =
PCN-marking.  A non PCN-node wouldn't be able to =
alert
      that it is =
suffering pre-congestion, which potentially would =
lead
      to too many =
PCN-flows being admitted (or too few being
      =
terminated).  Worse, a rogue node could perform various =
attacks,
      as discussed =
in the Security Considerations section.

 

      =       …

   Note: All PCN-nodes need to be =
trustworthy.  However if it's known
   that an interface cannot become =
pre-congested then it's not strictly
   necessary for it to be capable =
of PCN-marking.  But this must be
   known even in unusual =
circumstances, eg after the failure of =
some
   =
links.
 

[joe asked for some tweaking of = this last para, and I’m toying with putting a mention of the issue somewhere else = eg OAM section]

 

But the basic point is: a non-PCN = region makes scenarios are interesting but not in the current work scope. so we = shouldn’t worry about them at the moment.

 

phil

 

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 31 January 2008 = 08:36
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] Review = of pcn-architecture-02 draft

 

Phil,

 

if the PCN domain spans across an = embedded non PCN domain, then the PCN marked packets may be tunneled without the = outer header supporting PCN while the PCN marks of the inner header = should be left unchanged. Examples are:

 

- backbone transit using a = carrier IP VPN service

- a business access connected via = L2TP over DSL

 

In both cases the carrier providing connectivity may not support PCN, but the end point using that carrier connectivity product may be in a PCN domain. It is important that the = tunnel starts and ends in the same PCN domain (which holds for the given = examples). Once the charter allows for extended discussion, the tunnel may also = connect two PCN domains.

 

This scenario should be supported, = I support Joe's view. Picking up Joe's drafted text, what about the = following (my changes marked):

 

A PCN domain may = expand over a non PCN domain and wish to tunnel PCN-traffic across this = non-PCN-capable domain. The PCN-marks shouldn't be visible outside the PCN-domain, which = can be achieved by encapsulating PCN packets with an outer header that does not support PCN. In this mode on decapsulation, the inner PCN-capable header is used without = modification.

 

Deletions are = hard to mark, that's why I highlighted "PCN".

 

I think, the = scenario is somewhat similar to passing a non PCN capable node (without a tunnel) in = a PCN domain.

 

Regards, Ruediger

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, January = 30, 2008 7:45 PM
To: babiarz@nortel.com; pcn@ietf.org
Subject: RE: [PCN] Review = of pcn-architecture-02 draft

Joe

 

You make some comments on Section = 5.7 Tunnelling, which I didn’t really understand.

 

After

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes.  =

You deleted this:

The PCN-marks shouldn't be visible outside =
the
   PCN-domain, which can be =
achieved by doing the PCN-colour function
   (Section 5.3) after all the other (PCN and tunnelling) =
functions.

Why? Is this because you thought it = too detailed to bother saying? Or because you think PCN-colouring isnt = needed? If the latter, this is an argument about encoding – in which case = I’ll ignore the issue until the encoding draft is done.

 

You added:

  Also operator may wish to tunnel = PCN-traffic across a non-PCN-capable domain.  The PCN-marks shouldn't be = visible outside the PCN-domain, which can be achieved by encapsulating PCN = packets with an outer header that does not support the PCN function (tunnel). In this = mode on decapsulation, the inner PCN-capable header is used without = modification.

I don’t agree with this. if = you send PCN-traffic outside the PCN-domain then it’s no longer = PCN-traffic.

 

You made a lot = of changes to the text about "partially = PCN-capable tunnel", ie where only one tunnel endpoint is in the PCN = domain

Partly I think this is to do with encoding = (again, I propose to park the text until the encoding draft has progressed). =

However:

In the case “1.  The tunnel starts = outside a PCN-domain and finishes inside it.”

You wrote:

       For this = scenario when the tunnel ends, the PCN-ingress node function must be performed = after decapsulation of packet.

I don’t agree. The main ingress = functions like policing have to be done at the PCN-boundary-node.

 

Thanks,

phil

 

 

-----Original Message-----
From: Jozef Babiarz = [mailto:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [PCN] Review of pcn-architecture-02 draft

 

Hi Phil,

The link below provides my detailed comments and suggested new text for draft-ietf-pcn-architecture-02.

Currently, my review covers, Section 1 through end of 5. New text to be added is underlined and text to be deleted is crossed out.

http://standards.nortel.com/= pcn/draft-ietf-pcn-architecture-02-jb.doc=

http://standards.nortel.com/= pcn/draft-ietf-pcn-architecture-02-jb.pdf

Changes of note:

- On terminology, changed PCN-boundary-node to PCN-edge-node. =

- Made several changes in Section 5.2, 5.3, 5.4 and 5.5.

- The changes in Section 5.7 on Tunneling that I made are with the = assumption that PCN marking will be conformant to RFC 4774, Specifying Alternate = Semantics for the Explicit Congestion Notification (ECN) Field.

- Most of the other changes through out the draft are = editorial.

I will send comments on remaining of the draft, Section 6 to end in few = days.

Happy New Year!

Regards, = Joe

email:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C8675D.F2870B2F-- --===============1989127003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --===============1989127003==-- From pcn-bounces@ietf.org Wed Feb 6 05:25:18 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24DF3A6D6B; Wed, 6 Feb 2008 05:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.927 X-Spam-Level: * X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAL58PVFcPV9; Wed, 6 Feb 2008 05:25:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCD13A6BD1; Wed, 6 Feb 2008 05:25:17 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314FD3A683D for ; Wed, 6 Feb 2008 05:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veay7Q+z3ILG for ; Wed, 6 Feb 2008 05:25: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 0567D3A6BD1 for ; Wed, 6 Feb 2008 05:25: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 m16DQSMG021376 for ; Wed, 6 Feb 2008 14:26:36 +0100 (MET) From: "Georgios Karagiannis" To: Date: Wed, 6 Feb 2008 14:26:23 +0100 Message-ID: <002601c868c3$e40603d0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Achow93ielZYMXotSD+E8HzFIDL/IQ== 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]); Wed, 06 Feb 2008 14:26:36 +0100 (MET) Subject: [PCN] possibilities of combining LC-PCN and SM (in at least PCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all After having some discussion off line with Anna, I think that it would be possible to at least combine the SM and LC-PCN features in the PCN-interior nodes! Please note that the below description does not describe how the use of the probing functionality during admission control and the use of affected marking for ECMP solution during flow termination should be performed. These two features can be added as optional, later on. * U is specified as in the SM draft! * N is specified as in the LC-PCN draft * Features in the PCN_interior_node: ------------------------ The excess rate measurement is done in a similar way as is done for SM, but the measurement should be done before drop but PCN_marking should be done after drop. This means that marked packets are preferentially not dropped. Furthermore the constant N should be used such that the marked excess rate can represent also high level of excess rate. The calculated excess rate should be divided by N (when N>=1) This can be implemented in SM by marking every N-th packet (or rather byte) instead of marking each packet (or byte) * Features in the PCN_egress_node ------------------------ The admission decision is similar to SM, based on the CLE, by measuring the rate of the received PCN_marked packets and by multiplying it by N. When CLE higher than a predefined/preconfigured threshold, e.g., 1% then in admission state. The PCN_egress_node informs the PCN_ingress node that the requesting flow is admitted or rejected (if in admission control state) The above feature is not an SM feature. When CLE is above a predefined/preconfigured percentage, e.g., 10%, then the PCN_egress_node goes in flow termination state. Note that this state does not exist for SM at the egress. The calculated excess rate above the flow termination threshold is used to calculate how many flows should be terminated. Before calculating the number of flows to be terminated the calculated excess rate above the flow termination threshold have to be divided with the constant U. For the flows that should be terminated the PCN_egress_node informs the PCN_ingress_node to terminate them. * Features in the PCN_ingress_node ------------------------ In Admission control: ----------------- Admits or rejects the flow depending on the sent report by the egress This feature is not a SM feature In Flow termination: -------------------- The flows that are termination notified by the PCN_egress node have to be terminated by PCN_ingress node. In addition the PCN_ingress node informs the associated flow sender about the problem. This feature is not a SM feature Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 07:16:35 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32D13A6E33; Wed, 6 Feb 2008 07:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc3P1RHP3Tfi; Wed, 6 Feb 2008 07:16:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A180F3A6E47; Wed, 6 Feb 2008 07:16:33 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137DC3A6D82 for ; Wed, 6 Feb 2008 07:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giHQAwdENIQY for ; Wed, 6 Feb 2008 07:16:30 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3A8853A6E33 for ; Wed, 6 Feb 2008 07:16:30 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 15:18:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 15:18:00 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34544@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some comments on pcn-architecture-02 Thread-Index: AcgzPyyK4uKTmDDHS5usTBXBuUnxhw1gsqcg From: To: X-OriginalArrivalTime: 06 Feb 2008 15:18:01.0279 (UTC) FILETIME=[7655ECF0:01C868D3] Cc: pcn@ietf.org Subject: Re: [PCN] some comments on pcn-architecture-02 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Rob I've finally got to dealing with these comments. Thanks for the careful scrutiny. Most excitingly, these all involved changes to the draft. In-line. phil > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 30 November 2007 10:53 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: some comments on pcn-architecture-02 > > Hi all, > > Some comments on the architecture draft, mainly (but not totally) > stimulated by the ECN discussion. > > 1. The draft is mainly about what building blocks are needed to > construct a PCN domain. That's fair enough; however, it would also be > nice to have some overview of how a PCN domain looks (as a "black > network") to the outside world. If I'm primarily interested in terminals > or edge networks then I don't really care about how ingress and egress > nodes communicate, or OAM, or internal encoding issues, but I do care > about how the introduction of PCN will affect my traffic. This > discussion would be short if the PCN domain was transparent in which > case that's all that needs to be said. However, if for example the > domain blocks packets with particular bit patterns in particular > circumstances, I'd like to know what those circumstances are, and what - > if anything - I can do about them (and to have that information > conveniently centralised). Added new para at end of S1 Intro: From the perspective of the outside world, a PCN-domain essentially looks like a DiffServ. PCN-traffic is either transported across it transparently or policed at the PCN-ingress-node (ie dropped or carried at a lower QoS). A couple of differences are that: PCN-traffic has better QoS guarantees than normal DiffServ traffic (because PCN's mechanisms better protects the QoS of admitted flows); and in rare circumstances (failures) on the one hand some PCN-flows may get terminated, but on the other hand other flows will get their QoS restored. Non PCN-traffic is treated transparently, ie the PCN-domain is a normal DiffServ domain. > > 2. The draft uses the term 'PCN-flow' several times without defining it. > I imagine that a PCN-flow could be defined as just a subset of > PCN-traffic, but I'm not clear how arbitrary those subsets could be. > (Does a subset have to have a single ingress/egress? Can subsets > nest/overlap? Do all the ingress/egress nodes have to agree on what the > subsets are?) It may be that a PCN-flow is just one of > - whatever a boundary node decides to admit > - whatever a boundary node decides to terminate > and that the granularity of those decisions can be absolutely whatever > one wants (but again it would be nice to say so). Yes, your last sentence is the case, I believe. I've adjusted the definition of PCN-traffic in S2: PCN-traffic: A PCN-domain carries traffic of different DiffServ behaviour aggregates. Those using the PCN mechanisms are called PCN-BAs (collectively called PCN-traffic) and the corresponding packets are PCN-packets. The same network may carry traffic using other DiffServ BAs. A PCN-flow is the unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single microflow (as defined in rfc2475) or some identifiable collection of microflows [the super-observant will notice that I also adjusted 'PCN-classes' to 'PCN-BAs' - steven blake suggested this, for better matching diffserv jargon] > > 3. It's clear that the ingress nodes are responsible for deciding > whether or not an incoming packet is a PCN packet, and that the criteria > for the decision are a header classifier. However, it's rather unclear > what needs to be assumed about how these classifiers get installed. It > may be that for most of the details of PCN operation, how the > classifiers get installed just doesn't matter, but from the point of > view of the external user or peer network it could be critical. (How > does it work if a domain is working without admission control, as in > section 4.3? Will an operator provision the classifiers statically? Or, > if there is rerouting which causes the ingress for a flow to change, > whose job is it to move the classifiers around? And so on.) I adjusted the last para pf S5.2 (PCN-ingress-node functions): The first two are policing functions, needed to make sure that PCN-packets admitted into the PCN-domain belong to a flow that's been admitted and to ensure that the flow keeps to the flowspec agreed (eg doesn't go at a faster rate and is inelastic traffic). Installing the filter spec will typically be done by the signalling protocol, as will re-installing the filter, for example after a re-route that changes the PCN-ingress-node (see for an example using RSVP). PCN-colouring allows the rest of the PCN-domain to recognise PCN-packets. > > 4. There are a few comments in the draft (and elsewhere) about PCN being > intended for inelastic traffic. I think it needs to be really clear what > the significance of this assumption is. If the claim is "we know PCN > will only be used for inelastic traffic therefore we can make a > simplifying assumption about how to implement it" I think that's very > dangerous. If the claim is "we only have to provide a benefit for > inelastic traffic and nothing else sees any difference" that's quite > safe. (To some extent this is tied up with point 3: if you stated > explicitly how the PCN domain decided whether traffic was PCN traffic, > then it would be clear to what extent the (in-)elasticity of the > admitted traffic was known and controlled. Without specifying the answer > to (3), it isn't clear how the PCN domain can enforce the assumption or > monitor whether the assumption is being violated.) I added a sentence in S3.2 (assumptions): In other words we focus on PCN providing a benefit to inelastic traffic (PCN may or may not provide a benefit to other types of traffic). Your last sentence hopefully is covered by answer to point 3 > > 5. It's clear that the assumption in 3.5 is driven by encoding > considerations. However, what is really unclear (to the naive reader > such as myself) is why CE is problematic, but ECT(0/1) are not, since > they all use the same IP header bits. If a packet in a PCN flow arrives > with ECT set, does that pass through the domain transparently? (It would > also be reassuring to state explicitly that ECN is transparent for > non-PCN-flows.) I adjusted S3.5 [hopefully deals with your next point too]: What to do if a packet that is part of a PCN-flow arrives at a PCN-ingress-node with its CE (Congestion experienced) codepoint set (or if it detects that the ECN-nonce in use). There are several possibilities (not discussed further in this document) about what the PCN-ingress-node should do: - drop the packet - downgrade the packet to non PCN-BA, eg best effort - tunnel the packet, so that the ECN-marking is carried transparently across the PCN-domain. > > 6. On the specific point about what to do with PCN flows using ECN, I > can just about follow the logic > - if CE was set, then it is possible that it was set by a router using > the default ECN semantics > - a router using the default ECN semantics should be able to assume that > the receiver would react in a similar way as to a packet drop > - therefore the PCN domain can drop the packet > However, it's quite a long journey from the beginning of the argument to > the end. In particular, for an endpoint, receiving a packet with CE is > quite different from not receiving a packet at all. For one thing, it > means the receiver gets data. It also gets a positive signal of > congestion (rather than, for example, wondering whether it was a > congestive or corruptive packet loss). In general, I think it's really > important not to do things which act as deployment disincentives for > ECN, or any additional barriers to alternative semantics, since e2e > packet marking is so useful for congestion control in some environments > (multi-hop wireless in particular). > > If the desire is to have a simple solution for PCN which uses the ECN > bits for encoding, there might be an alternative: if you detect that a > PCN-flow is using ECN (because ECT is set on any of its packets), simply > reclassify that flow as non-PCN and let it pass transparently through > the domain as non-PCN (e.g. best efforts) traffic. In performance terms > the flow is getting no worse service than in a pre-PCN world. If you > really think that there are no use cases for combined ECN/PCN this > situation will never arise. If applications are developed in the future > which can exploit ECN for semi-elastic flows, then it becomes a question > of writing guidelines for application developers to help them either > interpret signalling protocols (to find out whether their success in > admission control is being harmed by their use of ECN) or split their > flows into elastic and inelastic sub-flows, or indeed work out a PCN > solution which didn't use the ECN bits internally. All of these would > obviously be a later stage of the work. > > cheers & have fun in vancouver, > > robert h. _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 07:22:52 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4AC3A6E79; Wed, 6 Feb 2008 07:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH6GNZg-WxsS; Wed, 6 Feb 2008 07:22:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D10A3A6ECE; Wed, 6 Feb 2008 07:22:49 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1FE3A6D69 for ; Wed, 6 Feb 2008 07:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaq1320K+0p6 for ; Wed, 6 Feb 2008 07:22:47 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B33443A6EED for ; Wed, 6 Feb 2008 07:21:27 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m16FMw5G016116 for ; Wed, 6 Feb 2008 09:22:58 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 09:22:58 -0600 Received: from [147.117.169.111] ([147.117.169.111]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 09:22:57 -0600 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Wed, 06 Feb 2008 10:22:57 -0500 Message-Id: <1202311377.1439.5.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 06 Feb 2008 15:22:58.0199 (UTC) FILETIME=[27505270:01C868D4] Subject: [PCN] Requested review of draft-ietf-tsvwg-admitted-realtime-dscp-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org draft-ietf-tsvwg-admitted-realtime-dscp-03 is about to enter working group last call in tsvwg. As this DSCP might be usable as part of a PCN encoding scheme, PCN members are requested to review it and send comments to the authors, or to the tsvwg list. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 07:24:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B7A3A6E59; Wed, 6 Feb 2008 07:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHNcMVKn5Wv8; Wed, 6 Feb 2008 07:24:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069393A6DE6; Wed, 6 Feb 2008 07:24:15 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCBC3A6BD3 for ; Wed, 6 Feb 2008 07:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM4xwWcTcLtR for ; Wed, 6 Feb 2008 07:24:08 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7D2C83A6DE6 for ; Wed, 6 Feb 2008 07:24:08 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m16FPT2f010110; Wed, 6 Feb 2008 17:25:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 17:25:35 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 17:25:34 +0200 Received: from esdhcp036161.research.nokia.com ([172.21.36.161]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 17:25:35 +0200 Message-Id: From: Lars Eggert To: "ext Steven Blake" In-Reply-To: <1202311377.1439.5.camel@neutrino> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 17:25:32 +0200 References: <1202311377.1439.5.camel@neutrino> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 06 Feb 2008 15:25:35.0109 (UTC) FILETIME=[84D6E350:01C868D4] X-Nokia-AV: Clean Cc: pcn Subject: Re: [PCN] Requested review of draft-ietf-tsvwg-admitted-realtime-dscp-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 2008-2-6, at 17:22, ext Steven Blake wrote: > draft-ietf-tsvwg-admitted-realtime-dscp-03 is about to enter working > group last call in tsvwg. As this DSCP might be usable as part of a > PCN > encoding scheme, PCN members are requested to review it and send > comments to the authors, or to the tsvwg list. To the list, please. Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 07:35:37 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033B93A6F8D; Wed, 6 Feb 2008 07:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7tJpXw4BFbS; Wed, 6 Feb 2008 07:35:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CDD3A6E7F; Wed, 6 Feb 2008 07:35:31 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E513A6DC6 for ; Wed, 6 Feb 2008 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ECdGiyoWzDq for ; Wed, 6 Feb 2008 07:35:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6A5063A6F55 for ; Wed, 6 Feb 2008 07:35:18 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Feb 2008 10:36:51 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m16FanRq018841; Wed, 6 Feb 2008 10:36:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m16FanMR029333; Wed, 6 Feb 2008 15:36:49 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 10:36:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 10:36:48 -0500 Message-ID: In-Reply-To: <002601c868c3$e40603d0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) Thread-Index: Achow93ielZYMXotSD+E8HzFIDL/IQAEFPsw From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , X-OriginalArrivalTime: 06 Feb 2008 15:36:49.0447 (UTC) FILETIME=[16C6B370:01C868D6] Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, Some questions below: 1) Is marking every Nth packet at the interior node any different from Joe's slow-down S factor he uses for termination in 3sm? 2) Suppose configured ( admission) threshold is 0.3 of the link speed, and U is 5/3 (so it effectively brings the implicit termination threshold to 0.5 of the link speed). Suppose the load on the link is exactly equal to link speed, and for the moment assume you mark ever packet (so N=1). Then 0.7 of all traffic will be marked. When you divide it by U at the egress, you will end up deciding that your effective termination threshold is 21/50, wherease you wanted it to be 0.5? Not sure I understand exactly how it all works together? 3) What happens if some of the marked traffic gets dropped? 4) Could you summarize performance or other benefit of the proposed mechanism compared to SM and other proposed mechanisms? 5) will there be an update on the LC-PCN draft? Thank you, Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Wednesday, February 06, 2008 8:26 AM > To: pcn@ietf.org > Subject: [PCN] possibilities of combining LC-PCN and SM (in > at leastPCN-interior nodes) > > Hi all > > After having some discussion off line with Anna, I think that > it would be possible to at least combine the SM and LC-PCN > features in the PCN-interior nodes! > > Please note that the below description does not describe how > the use of the probing functionality during admission control > and the use of affected marking for ECMP solution during flow > termination should be performed. These two features can be > added as optional, later on. > > > > * U is specified as in the SM draft! > * N is specified as in the LC-PCN draft > > * Features in the PCN_interior_node: > ------------------------ > The excess rate measurement is done in a similar way as is > done for SM, but the measurement should be done before drop > but PCN_marking should be done after drop. > This means that marked packets are preferentially not dropped. > > Furthermore the constant N should be used such that the > marked excess rate can represent also high level of excess > rate. The calculated excess rate should be divided by N (when N>=1) > > This can be implemented in SM by marking every N-th packet > (or rather byte) instead of marking each packet (or byte) > > > * Features in the PCN_egress_node > ------------------------ > The admission decision is similar to SM, based on the CLE, by > measuring > the rate of the received PCN_marked packets and by multiplying it by > N. When CLE higher than a predefined/preconfigured threshold, e.g., > 1% then in admission state. > > The PCN_egress_node informs the PCN_ingress node that the > requesting flow is admitted or rejected (if in admission > control state) > The above feature is not an SM feature. > > When CLE is above a predefined/preconfigured percentage, e.g., 10%, > then the PCN_egress_node goes in flow termination state. > > Note that this state does not exist for SM at the egress. > > The calculated excess rate above the flow termination > threshold is used to calculate how many flows should be > terminated. Before > calculating the number of flows to be terminated the calculated > excess rate above the flow termination threshold have to be > divided with the > constant U. > > > For the flows that should be terminated the PCN_egress_node informs > the PCN_ingress_node to terminate them. > > > * Features in the PCN_ingress_node > ------------------------ > In Admission control: > ----------------- > Admits or rejects the flow depending on the sent report by > the egress > This feature is not a SM feature > > In Flow termination: > -------------------- > The flows that are termination notified by the PCN_egress node have > to be terminated by PCN_ingress node. In addition the PCN_ingress > node informs the associated flow sender about the problem. > This feature is not a SM feature > > Best regards, > Georgios > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 07:43:06 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A603A6D11; Wed, 6 Feb 2008 07:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWgQV2fkdaTq; Wed, 6 Feb 2008 07:43:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8487A3A6ECE; Wed, 6 Feb 2008 07:43:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5083A69C8 for ; Wed, 6 Feb 2008 07:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvKDzWwbHRfm for ; Wed, 6 Feb 2008 07:43:01 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E2F783A6EC4 for ; Wed, 6 Feb 2008 07:41:59 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 15:43:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 15:43:29 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34546@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <002601c868c3$e40603d0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) Thread-Index: Achow93ielZYMXotSD+E8HzFIDL/IQAEXopw From: To: , X-OriginalArrivalTime: 06 Feb 2008 15:43:30.0314 (UTC) FILETIME=[05B626A0:01C868D7] Subject: Re: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios Your email looks interesting, but I am struggling. I thought that lc-pcn did admission-marking, termination-marking & affected-marking. However, below it sounds like you're now just doing single-marking & affected-marking??? Are you simply saying that affected marking could be added to SM, just as it could be added to AM/TM?? (if so, my reaction is: sure. The pros and cons of doing this look the same in both cases to me.) I'm trying to understand if you've come up with new behaviour (at ingress/edge) or have just discovered a 1:1 mapping between lc-pcn & single marking. All the things you mention as "not a SM feature" seem not significant to me (eg " PCN_ingress node informs the associated flow sender about the problem" - well, this could be done with any PCN mechanism, but is really in scope of signalling protocol & out of scope of pcn mechanism) Is there a revised lc-pcn description that clears up some of the issues raised with the previous version? Thanks phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: 06 February 2008 13:26 > To: pcn@ietf.org > Subject: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN- > interior nodes) > > Hi all > > After having some discussion off line with Anna, I think that it would be > possible to at least > combine the SM and LC-PCN features in the PCN-interior nodes! > > Please note that the below description does not describe how the use of > the > probing functionality > during admission control and the use of affected marking for ECMP solution > during flow termination > should be performed. These two features can be added as optional, later > on. > > > > * U is specified as in the SM draft! > * N is specified as in the LC-PCN draft > > * Features in the PCN_interior_node: > ------------------------ > The excess rate measurement is done in a similar way as is > done for SM, but the measurement should be done before drop > but PCN_marking should be done after drop. > This means that marked packets are preferentially not dropped. > > Furthermore the constant N should be used such that the > marked excess rate can represent also high level of excess rate. The > calculated excess rate should be divided by N (when N>=1) > > This can be implemented in SM by marking every N-th packet (or rather > byte) > instead > of marking each packet (or byte) > > > * Features in the PCN_egress_node > ------------------------ > The admission decision is similar to SM, based on the CLE, by measuring > the rate of the received PCN_marked packets and by multiplying it by > N. When CLE higher than a predefined/preconfigured threshold, e.g., > 1% then in admission state. > > The PCN_egress_node informs the PCN_ingress node that the > requesting flow is admitted or rejected (if in admission control state) > The above feature is not an SM feature. > > When CLE is above a predefined/preconfigured percentage, e.g., 10%, > then the PCN_egress_node goes in flow termination state. > > Note that this state does not exist for SM at the egress. > > The calculated excess rate above the flow termination > threshold is used to calculate how many flows should be terminated. Before > calculating the number of flows to be terminated the calculated > excess rate above the flow termination threshold have to be divided with > the > constant U. > > > For the flows that should be terminated the PCN_egress_node informs > the PCN_ingress_node to terminate them. > > > * Features in the PCN_ingress_node > ------------------------ > In Admission control: > ----------------- > Admits or rejects the flow depending on the sent report by > the egress > This feature is not a SM feature > > In Flow termination: > -------------------- > The flows that are termination notified by the PCN_egress node have > to be terminated by PCN_ingress node. In addition the PCN_ingress > node informs the associated flow sender about the problem. > This feature is not a SM feature > > Best regards, > Georgios > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 6 08:12:56 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619483A6F21; Wed, 6 Feb 2008 08:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDa+zMjE9eDm; Wed, 6 Feb 2008 08:12:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E373A6EB5; Wed, 6 Feb 2008 08:12:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDFF3A6EA6 for ; Wed, 6 Feb 2008 08:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23Q1+nb+8BNr for ; Wed, 6 Feb 2008 08:12:47 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id BB5A83A6ECD for ; Wed, 6 Feb 2008 08:12:46 -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 m16GE6OB004371; Wed, 6 Feb 2008 17:14:12 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002601c868c3$e40603d0$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34546@E03MVZ1-UKDY.domain1.systemhost.net> Date: Wed, 6 Feb 2008 17:14:02 +0100 Message-ID: <003d01c868db$4d29a300$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34546@E03MVZ1-UKDY.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Achow93ielZYMXotSD+E8HzFIDL/IQAEXopwAAE+plA= 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]); Wed, 06 Feb 2008 17:14:13 +0100 (MET) Subject: Re: [PCN] possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil LC-PCN does AM/TM and affected marking. After I had some discussions I with Anna, I thought that we came up with a 1:1 mapping between SM and LC-PCN. However, from the reply of Anna, I can conclude that this might not be the case! I have to find out if Anna and I (off line) could come to such a 1:1 mapping! Regarding LC-PCN, I think that currently are no any open issues! I thought that all issues were worked out already in version 02! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 6 februari 2008 16:43 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] possibilities of combining LC-PCN and SM > (in at leastPCN-interior nodes) > > Hi Georgios > > Your email looks interesting, but I am struggling. I thought > that lc-pcn did admission-marking, termination-marking & > affected-marking. However, below it sounds like you're now > just doing single-marking & affected-marking??? Are you > simply saying that affected marking could be added to SM, > just as it could be added to AM/TM?? (if so, my reaction > is: sure. The pros and cons of doing this look the same in > both cases to > me.) > > I'm trying to understand if you've come up with new behaviour (at > ingress/edge) or have just discovered a 1:1 mapping between > lc-pcn & single marking. All the things you mention as "not a > SM feature" seem not significant to me (eg " PCN_ingress node > informs the associated flow sender about the problem" - well, > this could be done with any PCN mechanism, but is really in > scope of signalling protocol & out of scope of pcn mechanism) > > Is there a revised lc-pcn description that clears up some of > the issues raised with the previous version? > > Thanks > phil > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: 06 February 2008 13:26 > > To: pcn@ietf.org > > Subject: [PCN] possibilities of combining LC-PCN and SM (in at > leastPCN- > > interior nodes) > > > > Hi all > > > > After having some discussion off line with Anna, I think > that it would > be > > possible to at least > > combine the SM and LC-PCN features in the PCN-interior nodes! > > > > Please note that the below description does not describe how the use > of > > the > > probing functionality > > during admission control and the use of affected marking for ECMP > solution > > during flow termination > > should be performed. These two features can be added as optional, > later > > on. > > > > > > > > * U is specified as in the SM draft! > > * N is specified as in the LC-PCN draft > > > > * Features in the PCN_interior_node: > > ------------------------ > > The excess rate measurement is done in a similar way as is done for > > SM, but the measurement should be done before drop but PCN_marking > > should be done after drop. > > This means that marked packets are preferentially not dropped. > > > > Furthermore the constant N should be used such that the > marked excess > > rate can represent also high level of excess rate. The calculated > > excess rate should be divided by N (when N>=1) > > > > This can be implemented in SM by marking every N-th packet > (or rather > > byte) > > instead > > of marking each packet (or byte) > > > > > > * Features in the PCN_egress_node > > ------------------------ > > The admission decision is similar to SM, based on the CLE, by > measuring > > the rate of the received PCN_marked packets and by > multiplying it by > > N. When CLE higher than a predefined/preconfigured > threshold, e.g., 1% > > then in admission state. > > > > The PCN_egress_node informs the PCN_ingress node that the > requesting > > flow is admitted or rejected (if in admission control > state) > > The above feature is not an SM feature. > > > > When CLE is above a predefined/preconfigured percentage, e.g., 10%, > > then the PCN_egress_node goes in flow termination state. > > > > Note that this state does not exist for SM at the egress. > > > > The calculated excess rate above the flow termination threshold is > > used to calculate how many flows should be terminated. > Before > > calculating the number of flows to be terminated the > calculated excess > > rate above the flow termination threshold have to be divided > with > > the > > constant U. > > > > > > For the flows that should be terminated the PCN_egress_node informs > > the PCN_ingress_node to terminate them. > > > > > > * Features in the PCN_ingress_node > > ------------------------ > > In Admission control: > > ----------------- > > Admits or rejects the flow depending on the sent report by > the egress > > This feature is not a SM feature > > > > In Flow termination: > > -------------------- > > The flows that are termination notified by the PCN_egress > node have to > > be terminated by PCN_ingress node. In addition the PCN_ingress node > > informs the associated flow sender about the problem. > > This feature is not a SM feature > > > > Best regards, > > Georgios > > > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 7 07:02:44 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1D73A789B; Thu, 7 Feb 2008 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPALwajMFvAY; Thu, 7 Feb 2008 07:02:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776EE3A7998; Thu, 7 Feb 2008 07:02:41 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3453A7998 for ; Thu, 7 Feb 2008 07:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b+H0it-V3oA for ; Thu, 7 Feb 2008 07:02:38 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 868F13A78F3 for ; Thu, 7 Feb 2008 07:01:44 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 15:03:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 15:03:13 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3454F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4746AE39.6000409@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-pcn-architecture-02.txt Thread-Index: AcgtvROWA8WscwSrSHOvmk7Bn6LvZg7yNHuA From: To: X-OriginalArrivalTime: 07 Feb 2008 15:03:13.0981 (UTC) FILETIME=[8FE0BED0:01C8699A] Cc: pcn@ietf.org Subject: Re: [PCN] Comments on draft-ietf-pcn-architecture-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael Thanks for the detailed review, I've now worked these into the revised arch draft phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 23 November 2007 10:41 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: Comments on draft-ietf-pcn-architecture-02.txt > > > Introduction > > "PCN-egress-nodes make measurements of the packet markings and > send information as necessary to the nodes that make the decision > about which PCN-flows to accept/reject or terminate, based on this > information." > > [Michael] "PCN-egress nodes monitor the packet markings and ..." > (measurement is not necessarily required, both for admission and > termination.) joe made similar comments & have tried for mods in a few places. I actually left this one as is, as I found it too cumbersome to write "measure and/or monitor" [and I think "measure" is more inclusive of "monitor" than vice-versa] . Anyway, your point should be clear to anyone who gets beyond the intro! > > ===================== > > "The PCN-lower-rates can be chosen small enough that admitted > traffic can still be carried after a rerouting in most failure > cases." > > [Michael] The general concept of resilient admission control has > been proposed in [Menth04g] and applied to PCN in [PCN-Config] > including algorithms how to set PCN rate thresholds appropriately. > > [Menth04g] M. Menth, S. Kopf, and J. Charzinski: "Network > Admission Control for Fault-Tolerant QoS Provisioning" in IEEE > High-Speed Networks for Multimedia Communication (HSNMC), June > 2004 > > [PCN-Config] M. Menth, and M. Hartmann: "PCN-Based Resilient > Network Admission Control: The Impact of a Single Bit", > PCN-Config.pdf>", > 2007. > I added a ref to te 2nd. > ===================== > > Terminology want to avoid discussing /changing terminology, where it's just changing wording rather than changing meaning. > > ===================== > 4.1 > > "However, note that this description reflects the overall intent > of the algorithm rather than its instantaneous behaviour, since > the rate measured at a particular moment depends on the detailed > algorithm, its implementation (eg virtual queue, token bucket...) > and the traffic's variance as well as its rate (eg marking may > well continue after a recent overload even after the instantaneous > rate has dropped)." > > [Michael]: virtual queue and token bucket are absolutely > equivalent paradigms on which metering and marking may be based. > see also: > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt > Just omit the example! Deleted. [by TB you mean upside down VQ; by TB I also imply no memory, cf VQ with marking threshold =0] > > ===================== > > (Hence, by analogy with ECN we call our mechanism Pre-Congestion > Notification.) > > [Michael] This should come earlier in the document. E.g. in the > terminology section. > ok > ===================== > > 5.5 > > o PCN-meter at PCN-egress-node - make "measurements of PCN-traffic" > from a particular PCN-ingress-node. > > [Michael] Could you add "(if required)" to that point? 3sm > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt > does not need metering or measurement of marked packets for flow > termination. > > ===================== > > > o Make decision about flow termination - use the "measurements of > PCN-traffic" to decide which PCN-flow or PCN-flows to terminate. > The decision takes account of policy and application layer > requirements. > > [Michael] Similar issue: could you add "possibly" somewhere? > think I've covered these points when dealing with joe's comments. > ===================== > > 5.7 > > o NB the order of increasing severity is: unmarked; PCN-marking with > first encoding (ie associated with the PCN-lower-rate); PCN- > marking with second encoding (ie associated with the PCN-upper- > rate) > > [Michael] What does "NB" stand for? Changed to 'Note' [nb = nota bene] > > The downsides of probing for this viewpoint are: > > o Probing adds delay to the admission control process. > > o Sufficient probing traffic has to be generated to test the pre- > congestion level of the ECMP path. But there's the risk that the > probing traffic itself may cause pre-congestion, causing other > PCN-flows to be blocked or even terminated. > > [Michael] Could you please add "possibly" to these points? "risk ... may" is equivalent to "possibly" > > ===================== > > Viewpoint 3 or probably extra viewpoint: > > [Michael] Probing might be used because it is easier than > measuring and signalling aggregate packet markings. This is the > case when a signalling protocol already exists, e.g., to find out > the correct ingress-egress-aggregate of a flow. Then, this > signalling protocol might be reused for probing purposes saving > complex operations in the egress node and signalling. An example > is given in 2.4 of > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt added > Also 4.3 of > http://tools.ietf.org/wg/pcn/draft-briscoe-pcn-boundary-behav-00.txt > suggests to use a protocol to find out the right egress node such > that probing would in fact lead to simplifications. > > ===================== > > 8.1.2 Parameters > > [Michael] A citation to our work on parameter settings would be > appropriate. > > [PCN-Config] M. Menth, and M. Hartmann: "PCN-Based Resilient > Network Admission Control: The Impact of a Single Bit", > PCN-Config.pdf>", > 2007. added _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 7 07:11:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845C13A793F; Thu, 7 Feb 2008 07:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw8YaleH7Kwl; Thu, 7 Feb 2008 07:11:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DF23A7974; Thu, 7 Feb 2008 07:11:51 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3E63A768F for ; Thu, 7 Feb 2008 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCi7+1PGv5IX for ; Thu, 7 Feb 2008 07:11:44 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 97C4A3A793F for ; Thu, 7 Feb 2008 07:11:39 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 15:13:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 15:13:08 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34550@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465135B3428@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgW7SC2PEVcOi1+Qg+vZ1UxgSPGoQDfIixAAVzgg4AEZKGNsA4LBo1Q From: To: , X-OriginalArrivalTime: 07 Feb 2008 15:13:08.0645 (UTC) FILETIME=[F2534550:01C8699B] Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [PCN] Architecture draft - probing section & general updates. 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Joe Have added the following text (to Appendix - which is on stuff beyond current charter): not all the nodes run PCN. For example, the PCN-domain is a multi-site enterprise network. The sites are connected by a VPN tunnel; although PCN doesn't operate inside the tunnel, the PCN mechanisms still work properly because the of the good QoS on the virtual link (the tunnel). Another example is that PCN is deployed on the general Internet (ie widely but not universally deployed). Hoping this gets your scenario! phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 28 November 2007 04:29 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@nokia.com > Cc: pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: RE: [PCN] Architecture draft - probing section & general updates. > > Hi Phil, > PCN-domain is enterprise network that is within one building or campus. > Large enterprises have several locations that are distributed throughout > the city, counter or even the world. Between different locations, Layer > 2 or Layer 3 VPNs are used to interconnect usually using multiple VPNs > to each location to provide resilience should one VPN fail for a period > of time. Different approaches (ECMP, policy routing, etc) are used to > distribute traffic on two or more VPNs between each location. Each or > most of the enterprise locations are PCN-capable and the VPNs (tunnels) > are used to interconnect the different locations. The ISPs that provide > the tunnels are not PCN-capable. PCN function needs only to be supported > within the global enterprise network. Edge nodes that provide admission > control and flow termination need to support PCN-edge-node function. > Enterprise core nodes and WAN nodes need to provide PCN-interior-node > function. > > Terminally: > In enterprise networks WAN (Wide Area Network) edge node is the node > that provides connects to a foreign network and where normally Layer 2 > or 3 VPN start and end. There may be other tunnels running inside the > enterprise network but that is outside the scope of this example. > Edge node is a switch or router where end terminals, hosts, servers > connect to. > > Those the above help? > > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: November 5, 2007 1:57 PM > To: Babiarz, Jozef (CAR:0S03); lars.eggert@nokia.com > Cc: pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: RE: [PCN] Architecture draft - probing section & general > updates. > > Joe - trying to clarify... what's the PCN-domain? Does it run from one > *enterprise* LAN edge switch/router to another (there's a tunnelled link > between them), or from the end terminals. Ie what are the > pcn-boundary-nodes {&pcn-interior-nodes)? > > The scenario isnt captured I think in the draft-ietf-pcn-architecture, > so something should probably be added... > > Thanks > Phil. > > > -----Original Message----- > > From: Jozef Babiarz [mailto:babiarz@nortel.com] > > Sent: 29 October 2007 21:06 > > To: Lars Eggert > > Cc: pcn@ietf.org; Geib, Ruediger > > Subject: RE: [PCN] Architecture draft - probing section & general > updates. > > > > Hi Lars, > > I did not explain my scenario that clearly, I confused people the word > > "access node". So here goes a second try. > > > > I'm thinking of a scenario that many enterprises face today. Large > multi > > location enterprises use multiple WAN links or VPS to interconnect > their > > locations (branch offices). PCN is run inside the enterprise network > > including WAN links which may be tunneled across the carrier network. > > Carrier network is not required to support PCN as the enterprise > traffic > > including PCN marking is tunneled, however it could. Network Access > > Control with PCN admission control is done at the *enterprise* LAN > edge > > switch/router. New flows can be routed to any egress LAN edge > > switch/router and some flows will (between different locations) be > > routed over one of the WAN links which are normally bandwidth > > constrained. There is a high probability that many of the edge LAN > > switches/routers will have no flows setup between each other (no > > ingress-egress aggregate) as there are a large number of edge LAN > > switches/routers in the enterprise network and people calling patterns > > change. They normal expect that they should be able to call anyone. > > > > > > Regards, Joe > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: October 25, 2007 5:54 AM > > To: Babiarz, Jozef (CAR:0S03) > > Cc: Geib, Ruediger; pcn@ietf.org > > Subject: Re: [PCN] Architecture draft - probing section & general > > updates. > > > > On 2007-10-24, at 19:14, ext Jozef Babiarz wrote: > > > I'm thinking of a scenario that many enterprises face today. Large > > > multi > > > location enterprises use multiple WAN links or VPS to interconnect > > > their > > > locations. PCN is run inside the enterprise network including WAN > > > links > > > which maybe tunneled across the carrier network. Network Access > > > Control > > > with PCN admission control is done at the enterprise access edge > > > nodes. > > > New flows can be routed to any egress access edge node and some > flows > > > will (between different locations) be routed over one of the WAN > links > > > which are normally bandwidth constrained. > > > > I understand your scenario so far. > > > > > There is a high probability > > > that many access nodes will only have one flow between each other as > > > there are a large number of them. > > > > I don't see how this follows, however. It seems that if the sites > > that are being interconnected aren't tiny, there should very likely > > be multiple flows per ingress/egress pair, no? > > > > Lars > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 7 07:50:36 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329413A7A4C; Thu, 7 Feb 2008 07:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4-DgmWOrnKr; Thu, 7 Feb 2008 07:50:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC403A7A8B; Thu, 7 Feb 2008 07:50:05 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9753A7859 for ; Thu, 7 Feb 2008 07:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvPFPCQqtalw for ; Thu, 7 Feb 2008 07:50:02 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 674E93A7A88 for ; Thu, 7 Feb 2008 07:48:37 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 15:50:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 15:50:06 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34551@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgBC8jjsA= From: To: , , X-OriginalArrivalTime: 07 Feb 2008 15:50:07.0236 (UTC) FILETIME=[1CB56440:01C869A1] Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I've found the simplest way of handling this interfaces vs links question is to add the following para near the start of section 4: Note: Section 4 and Section 5 talk about PCN functionality being configured on outgoing interfaces of PCN-nodes. Alternatively, PCN-functionality could be configured on the ingress interfaces of PCN-nodes, however a consistence choice must be made across the PCN-domain to ensure that the PCN mechanisms protect all links. This document assumes configuration on the egress interfaces, because in DiffServ networks today DiffServ functionality is usually implemented on egress interfaces. Otherwise I've left the text unaltered. As Ruediger pointed out, this means that the doc sometimes talks about links and sometimes interfaces. I don't think this is too unreasonable - in S4 & S5 (high level & detailed architecture) talk about configuring functionality on an interface - since the focus in S4/5 is what would actually be done. whereas in the other sections, we're really introducing the idea of PCn, explaining issues etc - then it seems ok to talk about pre-congestion on links, since that makes phrasing (/thinking) simpler. Hope this is ok & you don't think I cheated too much phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 17 January 2008 10:34 > To: babiarz@nortel.com; pcn@ietf.org > Subject: AW: [PCN] Review of pcn-architecture-02 draft > > Hi Joe, > > some comments on your comments: > > One general remark is whether we should talk of "interfaces" (instead > of links) whenever PCN node-functionalities are addressed. Up to now, > there's a mix in the text. > > You introduce the concept of PCN functionality on either incoming or > outgoing interfaces. PCN doesn't work, if there's a sequence of nodes > > Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, > > there's a link between node 2 and 3 without PCN functionality on > any interface. So a domain shouldn't mix these nodes. I'd prefer > PCN functionality on outgoing IF's, if this is closer to todays > DiffServ implementations. > > More details below. Please note that if I didn't comment a change > you've proposed, this doesn't indicate agreement. Some of your > comments aren't easy to understand for me. > > Regards, > > Ruediger > > > > > Terminology > > [JB]: PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled > nodes that provide the PCN function to at least one traffic class that is > DiffServ scheduling; > > [RG] if this needs to be changed, what about: > ...PCN-enabled nodes perfoming DiffServ scheduling with PCN functionality > to the PCN coloured traffic.. > > ------ > > [JB]: PCN-boundary-node: a PCN-node that connects one PCN-domain to a > node either in another PCN-domain or in a non PCN-domain. > > PCN-edge-node: a node that is at ingress or egress point to the PCN- > enabled > network. Traffic entering or leaving the PCN network passes through it. > Note, > PCN-boundary-node is a special case of PCN-edge-node. > > [RG]: I don't understand why the terminology is changed in the stage we > have > reached. Has this been agreed in Vancouver? I also don't understand the > difference between the definitons. > > ------- > > 3.1. Assumption 1: Trust and support of PCN function - controlled > environment > > [JB]: o Similarly, a PCN-edge-node has to trust that all the PCN-nodes > mark PCN traffic consistently. A link within the PCN-domain wouldn't be > able to alert... > > [RG]: The original sentence "A non-PCN-node within the PCN-domain..." > should > be used. Links aren't able to alert anyway, PCN is a node or interface > function. This comment applies to all insertions of "links" following in > this paragraph. > > ------- > > 3.3. Assumption 3: Many flows and additional load > > [JB]: We do not make explicit assumptions on how many PCN-flows are on > each > bottleneck link. Performance evaluation work may clarify > whether it is necessary to make any additional assumption on > aggregation on the bottleneck link. > > [RG]: This section should stay like it was and discuss the PCN assumptions > on ingress-egress aggregates. Our assumptions on aggregation on links are > discussed in the preceding section and any necessary changes regarding > link > aggregation should be added there. > > --------- > > 4.1. Flow admission > > [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on > a link (on its incoming or outgoing links). The measurement is made > as an aggregate of all PCN-packets on that link, and not per flow. > > [RG]: please change to > .... on each of its incoming or outgoing links... > and leave the orinial text: ...on each one of its links, and not... > If it should be emphasised that this is done per link aggregate: > ...on each single one of its links, and not.. > > ________________________________ > > Von: Jozef Babiarz [mailto:babiarz@nortel.com] > Gesendet: Dienstag, 1. Januar 2008 21:03 > An: PCN IETF > Betreff: [PCN] Review of pcn-architecture-02 draft > > > > Hi Phil, > > The link below provides my detailed comments and suggested new > text for draft-ietf-pcn-architecture-02. > > Currently, my review covers, Section 1 through end of 5. New text to > be added is underlined and text to be deleted is crossed out. > > http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02- > jb.doc jb.doc> > > http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02- > jb.pdf jb.pdf> > > Changes of note: > > - On terminology, changed PCN-boundary-node to PCN-edge-node. > > - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. > > - The changes in Section 5.7 on Tunneling that I made are with the > assumption that PCN marking will be conformant to RFC 4774, Specifying > Alternate Semantics for the Explicit Congestion Notification (ECN) Field. > > - Most of the other changes through out the draft are editorial. > > I will send comments on remaining of the draft, Section 6 to end in > few days. > > Happy New Year! > > Regards, Joe > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 7 08:08:51 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCD33A7A06; Thu, 7 Feb 2008 08:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umLG6y6Cw3qJ; Thu, 7 Feb 2008 08:08:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863193A78DB; Thu, 7 Feb 2008 08:08:50 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32303A771C for ; Thu, 7 Feb 2008 08:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je+UHN1tPtqV for ; Thu, 7 Feb 2008 08:08:48 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 6614C3A78DB for ; Thu, 7 Feb 2008 08:08:47 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 7 Feb 2008 17:10:06 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Feb 2008 17:10:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 17:10:48 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CC5C212@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34551@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgBC8jjsAAANuV8A== References: <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34551@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 07 Feb 2008 16:10:05.0679 (UTC) FILETIME=[E70947F0:01C869A3] Cc: pcn@ietf.org Subject: Re: [PCN] Review of pcn-architecture-02 draft 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, both proposals are allright with me. Regards, Ruediger | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] = | Sent: Thursday, February 07, 2008 4:50 PM | To: Geib, R=FCdiger; babiarz@nortel.com; pcn@ietf.org | Subject: RE: [PCN] Review of pcn-architecture-02 draft | = | I've found the simplest way of handling this interfaces vs = | links question is to add the following para near the start of = | section 4: | = | Note: Section 4 and Section 5 talk about PCN functionality = | being configured on outgoing interfaces of PCN-nodes. = | Alternatively, PCN-functionality could be configured on the = | ingress interfaces of PCN-nodes, however a consistence choice = | must be made across the PCN-domain to ensure that the PCN = | mechanisms protect all links. This document assumes = | configuration on the egress interfaces, because in DiffServ = | networks today DiffServ functionality is usually implemented = | on egress interfaces. | = | Otherwise I've left the text unaltered. = | As Ruediger pointed out, this means that the doc sometimes = | talks about links and sometimes interfaces. I don't think = | this is too unreasonable - in S4 & S5 (high level & detailed = | architecture) talk about configuring functionality on an = | interface - since the focus in S4/5 is what would actually be = | done. whereas in the other sections, we're really introducing = | the idea of PCn, explaining issues etc - then it seems ok to = | talk about pre-congestion on links, since that makes phrasing | (/thinking) simpler. | = | Hope this is ok & you don't think I cheated too much | = | phil | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: 17 January 2008 10:34 | > To: babiarz@nortel.com; pcn@ietf.org | > Subject: AW: [PCN] Review of pcn-architecture-02 draft | > = | > Hi Joe, | > = | > some comments on your comments: | > = | > One general remark is whether we should talk of = | "interfaces" (instead = | > of links) whenever PCN node-functionalities are addressed. = | Up to now, = | > there's a mix in the text. | > = | > You introduce the concept of PCN functionality on either = | incoming or = | > outgoing interfaces. PCN doesn't work, if there's a = | sequence of nodes | > = | > Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, | > = | > there's a link between node 2 and 3 without PCN = | functionality on any = | > interface. So a domain shouldn't mix these nodes. I'd prefer PCN = | > functionality on outgoing IF's, if this is closer to todays = | DiffServ = | > implementations. | > = | > More details below. Please note that if I didn't comment a change = | > you've proposed, this doesn't indicate agreement. Some of your = | > comments aren't easy to understand for me. | > = | > Regards, | > = | > Ruediger | > = | > = | > = | > = | > Terminology | > = | > [JB]: PCN-domain: a PCN-capable domain; a contiguous set of | PCN-enabled | > nodes that provide the PCN function to at least one traffic = | class that | is | > DiffServ scheduling; | > = | > [RG] if this needs to be changed, what about: | > ...PCN-enabled nodes perfoming DiffServ scheduling with PCN | functionality | > to the PCN coloured traffic.. | > = | > ------ | > = | > [JB]: PCN-boundary-node: a PCN-node that connects one = | PCN-domain to a = | > node either in another PCN-domain or in a non PCN-domain. | > = | > PCN-edge-node: a node that is at ingress or egress point to = | the PCN- = | > enabled network. Traffic entering or leaving the PCN network passes = | > through | it. | > Note, | > PCN-boundary-node is a special case of PCN-edge-node. | > = | > [RG]: I don't understand why the terminology is changed in the stage | we | > have | > reached. Has this been agreed in Vancouver? I also don't understand | the | > difference between the definitons. | > = | > ------- | > = | > 3.1. Assumption 1: Trust and support of PCN function - controlled = | > environment | > = | > [JB]: o Similarly, a PCN-edge-node has to trust that all = | the PCN-nodes = | > mark PCN traffic consistently. A link within the PCN-domain wouldn't | be | > able to alert... | > = | > [RG]: The original sentence "A non-PCN-node within the = | PCN-domain..." | > should | > be used. Links aren't able to alert anyway, PCN is a node = | or interface = | > function. This comment applies to all insertions of "links" = | following | in | > this paragraph. | > = | > ------- | > = | > 3.3. Assumption 3: Many flows and additional load | > = | > [JB]: We do not make explicit assumptions on how many = | PCN-flows are on = | > each bottleneck link. Performance evaluation work may = | clarify whether = | > it is necessary to make any additional assumption on aggregation on = | > the bottleneck link. | > = | > [RG]: This section should stay like it was and discuss the PCN | assumptions | > on ingress-egress aggregates. Our assumptions on = | aggregation on links | are | > discussed in the preceding section and any necessary = | changes regarding = | > link aggregation should be added there. | > = | > --------- | > = | > 4.1. Flow admission | > = | > [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on a = | > link (on its incoming or outgoing links). The measurement = | is made as = | > an aggregate of all PCN-packets on that link, and not per flow. | > = | > [RG]: please change to | > .... on each of its incoming or outgoing links... | > and leave the orinial text: ...on each one of its links, and not... | > If it should be emphasised that this is done per link aggregate: | > ...on each single one of its links, and not.. | > = | > ________________________________ | > = | > Von: Jozef Babiarz [mailto:babiarz@nortel.com] | > Gesendet: Dienstag, 1. Januar 2008 21:03 | > An: PCN IETF | > Betreff: [PCN] Review of pcn-architecture-02 draft | > = | > = | > = | > Hi Phil, | > = | > The link below provides my detailed comments and | suggested new | > text for draft-ietf-pcn-architecture-02. | > = | > Currently, my review covers, Section 1 through end of 5. New | text to | > be added is underlined and text to be deleted is crossed out. | > = | > http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02- | > jb.doc | jb.doc> | > = | > http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02- | > jb.pdf | jb.pdf> | > = | > Changes of note: | > = | > - On terminology, changed PCN-boundary-node to PCN-edge-node. | > = | > - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. | > = | > - The changes in Section 5.7 on Tunneling that I made are with | the | > assumption that PCN marking will be conformant to RFC 4774, = | Specifying = | > Alternate Semantics for the Explicit Congestion Notification (ECN) | Field. | > = | > - Most of the other changes through out the draft are editorial. | > = | > I will send comments on remaining of the draft, Section 6 to end | in | > few days. | > = | > Happy New Year! | > = | > Regards, Joe | > = | > email:babiarz@nortel.com | > = | > Telephone:613-763-6098 | > = | > = | > = | > _______________________________________________ | > PCN mailing list | > PCN@ietf.org | > https://www1.ietf.org/mailman/listinfo/pcn | = _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 7 10:30:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2F43A79B2; Thu, 7 Feb 2008 10:30:05 -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=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wu1D07fYLSZ; Thu, 7 Feb 2008 10:30:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6233A795C; Thu, 7 Feb 2008 10:30:03 -0800 (PST) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 18B043A795C; Thu, 7 Feb 2008 10:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080207183002.18B043A795C@core3.amsl.com> Date: Thu, 7 Feb 2008 10:30:02 -0800 (PST) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-03.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: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --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 : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-03.txt Pages : 48 Date : 2008-02-07 The purpose of this document is to describe a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain.Status A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pcn-architecture-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pcn-architecture-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-07102421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pcn-architecture-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-07102421.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Thu Feb 7 21:23:07 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D4B3A7038; Thu, 7 Feb 2008 21:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQQhu02UQg5F; Thu, 7 Feb 2008 21:23:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A573A800A; Thu, 7 Feb 2008 21:23:06 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73CD3A7038 for ; Thu, 7 Feb 2008 21:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvY54U3BjRt6 for ; Thu, 7 Feb 2008 21:23:04 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3B71C3A6A00 for ; Thu, 7 Feb 2008 21:23:04 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m185OVC15429 for ; Fri, 8 Feb 2008 05:24:31 GMT Received: from KCHAN-2K3.nortel.com ([47.130.16.74] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 00:24:30 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Feb 2008 00:24:10 -0500 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 08 Feb 2008 05:24:30.0819 (UTC) FILETIME=[E1AC7330:01C86A12] Subject: [PCN] Fwd: I-D Action:draft-chan-pcn-encoding-comparison-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all: Please notice the posting of the new PCN Encoding Comparison draft. With moving of some of the text into the appendix, there are about 10 pages of main text in this latest version. Please review and provide comments on the list. Thank you and have a Wonderful Chinese New Year! (Thur Feb 7, 2008 first day of the Chinese New Year) -- Kwok -- >X-Virus-Scanned: amavisd-new at amsl.com >X-Original-To: i-d-announce@ietf.org >Delivered-To: i-d-announce@core3.amsl.com >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Subject: I-D Action:draft-chan-pcn-encoding-comparison-02.txt >Date: Thu, 7 Feb 2008 15:45:01 -0800 (PST) >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.9 >Reply-To: internet-drafts@ietf.org >List-Id: >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-Spam-Tests: MIME_BOUND_NEXTPART=0.106,NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1 >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ertph000.nortel.com >X-Spam-Score: 1.3 >X-DNSBL-Score: 0 >X-SMTP-HELO: core3.amsl.com >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org >X-SMTP-RCPT-TO: >ajsmith@nortel.com,johnat@nortel.com,kboyle@nortel.com,khchan@nortel.com,ldiburro@nortel.com,leminovi@nortel.com,mary.barnes@nortel.com,mchen@nortel.com,rninan@nortel.com,schishol@nortel.com >X-SMTP-PEER-INFO: core3.amsl.com [64.170.98.86] >X-SMTP-REASON: PASSED >X-SMTP-ID: 1202428538.03026353 >X-OriginalArrivalTime: 07 Feb 2008 23:55:39.0513 (UTC) >FILETIME=[F0E61690:01C869E4] > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Pre-Congestion Notification Encoding Comparison > Author(s) : K. Chan, et al. > Filename : draft-chan-pcn-encoding-comparison-02.txt > Pages : 28 > Date : 2008-02-07 > >A number of mechanisms have been proposed to support differential >Qualiy of Service for packets in the Internet. DiffServ is an >example of such a mechanism. However, the level of assurance that >can be provided with DiffServ without substantial over-provisioning >is limited. Pre-Congestion Notification (PCN) uses path congestion >information across a PCN region to enable per-flow admission control >to provide the required service guarantees for the admitted traffic. >While admission control will protect the QoS under normal operating >conditions, an additional flow termination mechanism is necessary to >cope with extreme events (e.g. route changes due to link or node >failure). > >In order to allow the PCN mechanisms to work it is necessary for IP >packets to be able to carry the pre-congestion information to the PCN >egress nodes. This document explores different ways in which this >information can be encoded into IP packets. This document does not >choose the encoding but provide guidance and recommendation based on >different criteria. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then > "get draft-chan-pcn-encoding-comparison-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-chan-pcn-encoding-comparison-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2008-02-07153425.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-chan-pcn-encoding-comparison-02.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >http://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 11 05:56:46 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EC73A6BFA; Mon, 11 Feb 2008 05:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 pqQDjexIJ1S3; Mon, 11 Feb 2008 05:56:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3124E3A6BD4; Mon, 11 Feb 2008 05:56:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508AD3A6BD4 for ; Mon, 11 Feb 2008 05:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P528E6EC86eU for ; Mon, 11 Feb 2008 05:56:42 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 860D73A6B4C for ; Mon, 11 Feb 2008 05:56:37 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m1BDrxe01146 for ; Mon, 11 Feb 2008 13:53:59 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.55] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 08:57:54 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Feb 2008 08:57:53 -0500 To: "Kwok-Ho Chan" From: "Kwok-Ho Chan" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 11 Feb 2008 13:57:54.0235 (UTC) FILETIME=[192DF8B0:01C86CB6] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: I-D Action:draft-chan-pcn-encoding-comparison-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all: We are trying to have this draft be a PCN WG draft. Please let us know what improvements are needed: - for this draft to be a PCN WG draft and forward beyond WG draft. And are there additional area this draft should address (or not address). Thanks! -- Kwok -- At 12:24 AM 2/8/2008, Kwok-Ho Chan wrote: >Hi all: >Please notice the posting of the new PCN Encoding Comparison draft. >With moving of some of the text into the appendix, there are about >10 pages of main text in this latest version. >Please review and provide comments on the list. > >Thank you and have a Wonderful Chinese New Year! >(Thur Feb 7, 2008 first day of the Chinese New Year) >-- Kwok -- > > > >X-Virus-Scanned: amavisd-new at amsl.com > >X-Original-To: i-d-announce@ietf.org > >Delivered-To: i-d-announce@core3.amsl.com > >To: i-d-announce@ietf.org > >Cc: > >From: Internet-Drafts@ietf.org > >Subject: I-D Action:draft-chan-pcn-encoding-comparison-02.txt > >Date: Thu, 7 Feb 2008 15:45:01 -0800 (PST) > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.9 > >Reply-To: internet-drafts@ietf.org > >List-Id: > >List-Unsubscribe: , > > > >List-Archive: > >List-Post: > >List-Help: > >List-Subscribe: , > > > >Sender: i-d-announce-bounces@ietf.org > >X-Spam-Tests: > MIME_BOUND_NEXTPART=0.106,NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1 > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > ertph000.nortel.com > >X-Spam-Score: 1.3 > >X-DNSBL-Score: 0 > >X-SMTP-HELO: core3.amsl.com > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > >X-SMTP-RCPT-TO: > >ajsmith@nortel.com,johnat@nortel.com,kboyle@nortel.com,khchan@norte > l.com,ldiburro@nortel.com,leminovi@nortel.com,mary.barnes@nortel.com,mchen@nortel.com,rninan@nortel.com,schishol@nortel.com > >X-SMTP-PEER-INFO: core3.amsl.com [64.170.98.86] > >X-SMTP-REASON: PASSED > >X-SMTP-ID: 1202428538.03026353 > >X-OriginalArrivalTime: 07 Feb 2008 23:55:39.0513 (UTC) > >FILETIME=[F0E61690:01C869E4] > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : Pre-Congestion Notification Encoding Comparison > > Author(s) : K. Chan, et al. > > Filename : draft-chan-pcn-encoding-comparison-02.txt > > Pages : 28 > > Date : 2008-02-07 > > > >A number of mechanisms have been proposed to support differential > >Qualiy of Service for packets in the Internet. DiffServ is an > >example of such a mechanism. However, the level of assurance that > >can be provided with DiffServ without substantial over-provisioning > >is limited. Pre-Congestion Notification (PCN) uses path congestion > >information across a PCN region to enable per-flow admission control > >to provide the required service guarantees for the admitted traffic. > >While admission control will protect the QoS under normal operating > >conditions, an additional flow termination mechanism is necessary to > >cope with extreme events (e.g. route changes due to link or node > >failure). > > > >In order to allow the PCN mechanisms to work it is necessary for IP > >packets to be able to carry the pre-congestion information to the PCN > >egress nodes. This document explores different ways in which this > >information can be encoded into IP packets. This document does not > >choose the encoding but provide guidance and recommendation based on > >different criteria. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-compari > son-02.txt > > > >To remove yourself from the I-D Announcement list, send a message to > >i-d-announce-request@ietf.org with the word unsubscribe in the body of > >the message. > >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > >Internet-Drafts are also available by anonymous FTP. Login with the > >username "anonymous" and a password of your e-mail address. After > >logging in, type "cd internet-drafts" and then > > "get draft-chan-pcn-encoding-comparison-02.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-chan-pcn-encoding-comparison-02.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > > > >Content-Type: text/plain > >Content-ID: <2008-02-07153425.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-chan-pcn-encoding-comparison-02.txt > > > > > > son-02.txt> > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >http://www.ietf.org/mailman/listinfo/i-d-announce > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 12 08:07:31 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBFA28C366; Tue, 12 Feb 2008 08:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Z1gQkDJ1QWWP; Tue, 12 Feb 2008 08:07:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2BD28C142; Tue, 12 Feb 2008 08:07:30 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372E03A6940 for ; Tue, 12 Feb 2008 08:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF4MmGb1azXt for ; Tue, 12 Feb 2008 08:07:23 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 365073A69DC for ; Tue, 12 Feb 2008 08:07:23 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id BE1F9A0655 for ; Tue, 12 Feb 2008 17:08:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B23EBA0650 for ; Tue, 12 Feb 2008 17:08:46 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 87C1EA05D3 for ; Tue, 12 Feb 2008 17:08:46 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1CG8kV13093 for ; Tue, 12 Feb 2008 17:08:46 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 431D3C7F1A for ; Tue, 12 Feb 2008 17:08:46 +0100 (CET) Message-ID: <47B1C448.6020201@informatik.uni-wuerzburg.de> Date: Tue, 12 Feb 2008 17:07:36 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all, I am not so happy yet with the current version of the encoding draft. I am worrying about extensibility of edge-to-edge PCN to end-to-end PCN. I do not want push work towards end-to-end PCN in the near future, but we should be aware that a wrong encoding might close the door for end-to-end PCN. We should only intentionally close the door or keep it open. I discuss two different marking schemes taking this issue into account. 1. Non-extensible solution for edge-to-edge PCN When we do not want to extend PCN towards an end-to-end solution, we can stick with edge-to-edge PCN islands. If we take the decision that these islands do not support ECN, we can simply reuse the ECN-bits for encoding. To take advantage of the marking functionality of legacy ECN equipment, "excess-traffic" (ET) should be mapped to ECN's CE (11) codepoint, and "no-pre-congestion" (NP) as well as "admission-stop" (AS) should be mapped to ECN's ECT(0) and ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left over to indicate non-PCN traffic. This scheme requires that traffic is remarked when entering a PCN domain. All 11-marked packets must be dropped. Afterwards, all non-PCN traffic is remarked to 00 and PCN traffic is remarked to e.g. 01. Upon leaving the PCN domain, all traffic is reset to 00. Bad: This scheme is applicable only in a closed island where ECN semantics are substituted by PCN semantics. It cannot be extended to an end-to-end solution since it is not possible to differentiate PCN from non-PCN traffic. ECN marks are lost for PCN and non-PCN traffic. Good: PCN encoding does not require a new DSCP and PCN can be applied to any DSCP allowing PCN support for various service classes (DSCPs). 2. Solution for end-to-end PCN treating edge-to-edge PCN as a special case This requires the definition of a new "PCN DSCP" indicating that endpoints (either host nodes or proxies) implement the semantics of PCN instead of ECN. PCN treatment is only applied to traffic with the PCN DSCP. However, ECN treatment is possibly applied to PCN traffic by legacy nodes. A core question is: what is the desired behavior in that case? Should CE-marking be different from ET-marking or not? a) ET=CE=11: legacy nodes throttle ECN flows and tear down PCN flows in case of overload; other mappings {NP, AS} -> {ECT(0), ECT(1)} b) CE not used for PCN encoding: CE-marking always results from overloaded ECN nodes. Therefore, endpoints should either drop such packets or hand them to TCP if it is ECN-capable. mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} Edge-to-edge PCN is a special case of this encoding scheme when ingress and egress nodes of a PCN domain act as proxies for endpoints. This implies for PCN ingress nodes: drop all 11-marked PCN packets and then mark the other PCN packets with NP This implies for PCN egress nodes: case a) remark all 01, 10, 11-marked PCN packets to 00 Problem: 1. not-ECT flows with CE-marked packets by pure ECN nodes within the PCN domain do not back off 2. PCN traffic is terminated while non-PCN traffic continues to send in case of congestion when PCN domain contains pure ECN nodes -> PCN traffic is squeezed out case b) remark all 01, 10-marked PCN packets to 00; let 11-marked packets escape if all nodes of the PCN domain are PCN-enabled and drop them if the PCN domain has some nodes that are only ECN-enabled. Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage for non-PCN traffic. Bad: requires definition of new DSCP, cannot be used for different traffic classes; Simultaneous usage of PCN and ECN not possible If you think this kind of reflection is useful, I'd be happy to see it in the encoding draft. I am interested in your opinion about closing the door for end-to-end PCN or keeping it open. 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 00:06:25 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABFA43A6F42; Wed, 13 Feb 2008 00:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 R2vN-O47bYrk; Wed, 13 Feb 2008 00:06:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDF53A6F33; Wed, 13 Feb 2008 00:06:24 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0563A6F33 for ; Wed, 13 Feb 2008 00:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaOfeuhugmK3 for ; Wed, 13 Feb 2008 00:06:22 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 5D1E33A6E9E for ; Wed, 13 Feb 2008 00:06:22 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 13 Feb 2008 09:06:59 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 09:06:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 09:07:49 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CCC7F70@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47B1C448.6020201@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding: keep the door open for end-to-end PCN? Thread-Index: AchtkZseE7unRNWpQoGMatQzEgn4dgAhYdwg References: <47B1C448.6020201@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 13 Feb 2008 08:06:59.0090 (UTC) FILETIME=[68294F20:01C86E17] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hello Michael, a discussion like the one you've proposed should find a place in the encoding draft until there's an agreed solution on how to proceed on the issue. I don't it must be in the core document (an annex may do), but your concerns are valid and shouldn't be ignored. Regards, Ruediger | -----Original Message----- | From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] | Sent: Tuesday, February 12, 2008 5:08 PM | To: pcn | Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? | | Hi all, | | I am not so happy yet with the current version of the | encoding draft. I am worrying about extensibility of | edge-to-edge PCN to end-to-end PCN. I do not want push work | towards end-to-end PCN in the near future, but we should be | aware that a wrong encoding might close the door for | end-to-end PCN. We should only intentionally close the door | or keep it open. | | I discuss two different marking schemes taking this issue | into account. | | 1. Non-extensible solution for edge-to-edge PCN | | When we do not want to extend PCN towards an end-to-end | solution, we can stick with edge-to-edge PCN islands. If we | take the decision that these islands do not support ECN, we | can simply reuse the ECN-bits for encoding. To take advantage | of the marking functionality of legacy ECN equipment, | "excess-traffic" (ET) should be mapped to ECN's CE (11) | codepoint, and "no-pre-congestion" (NP) as well as | "admission-stop" (AS) should be mapped to ECN's ECT(0) and | ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left | over to indicate non-PCN traffic. | This scheme requires that traffic is remarked when entering a | PCN domain. All 11-marked packets must be dropped. | Afterwards, all non-PCN traffic is remarked to 00 and PCN | traffic is remarked to e.g. 01. Upon leaving the PCN domain, | all traffic is reset to 00. | | Bad: This scheme is applicable only in a closed island where ECN | semantics are substituted by PCN semantics. It cannot be | extended to an end-to-end solution since it is not possible | to differentiate PCN from non-PCN traffic. | ECN marks are lost for PCN and non-PCN traffic. | | Good: PCN encoding does not require a new DSCP and PCN can be | applied to any DSCP allowing PCN support for various service | classes (DSCPs). | | | 2. Solution for end-to-end PCN treating edge-to-edge PCN as a | special case | | This requires the definition of a new "PCN DSCP" indicating | that endpoints (either host nodes or proxies) implement the | semantics of PCN instead of ECN. PCN treatment is only | applied to traffic with the PCN DSCP. However, ECN treatment | is possibly applied to PCN traffic by legacy nodes. A core | question is: what is the desired behavior in that case? | Should CE-marking be different from ET-marking or not? | a) ET=CE=11: legacy nodes throttle ECN flows and tear down | PCN flows in case of overload; other mappings {NP, AS} -> | {ECT(0), ECT(1)} | b) CE not used for PCN encoding: CE-marking always results | from overloaded ECN nodes. Therefore, endpoints should | either drop such packets or hand them to TCP if it is ECN-capable. | mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} | | Edge-to-edge PCN is a special case of this encoding scheme | when ingress and egress nodes of a PCN domain act as proxies | for endpoints. | This implies for PCN ingress nodes: drop all 11-marked PCN | packets and then mark the other PCN packets with NP This | implies for PCN egress nodes: | case a) remark all 01, 10, 11-marked PCN packets to 00 | Problem: 1. not-ECT flows with CE-marked packets by pure ECN | nodes within the PCN domain do not back off | 2. PCN traffic is terminated while non-PCN | traffic continues to send in case of congestion | when PCN domain contains pure ECN nodes | -> PCN traffic is squeezed out case b) | remark all 01, 10-marked PCN packets to 00; let 11-marked | packets escape if all nodes of the PCN domain are PCN-enabled | and drop them if the PCN domain has some nodes that are only | ECN-enabled. | | Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage | for non-PCN traffic. | | Bad: requires definition of new DSCP, cannot be used for different | traffic classes; Simultaneous usage of PCN and ECN not possible | | | If you think this kind of reflection is useful, I'd be happy | to see it in the encoding draft. | | I am interested in your opinion about closing the door for | end-to-end PCN or keeping it open. | | 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 | http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 01:18:39 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850CF28C73E; Wed, 13 Feb 2008 01:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 AzM6rScjHDOI; Wed, 13 Feb 2008 01:18:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552ED28C71B; Wed, 13 Feb 2008 01:18:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C3C28C72B for ; Wed, 13 Feb 2008 01:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY3BNCfreWZ6 for ; Wed, 13 Feb 2008 01:18:35 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BF31A28C6E6 for ; Wed, 13 Feb 2008 01:18:33 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 09:19:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 09:19:55 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34576@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47B1C448.6020201@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding: keep the door open for end-to-end PCN? Thread-Index: AchtkZkUi/+fqpuWR5Wnh+PSwD26QwAjZhww From: To: , X-OriginalArrivalTime: 13 Feb 2008 09:19:56.0396 (UTC) FILETIME=[993D32C0:01C86E21] Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael In the detail of what you write, some I agree with and some I don't follow. However, I don't agree with the context you set it of "1. Non-extensible solution for edge-to-edge PCN " & "2. Solution for end-to-end PCN treating edge-to-edge PCN as a special case". For instance, in 1 I think you're assuming that non_PCN traffic is distinguished by setting the codepoint to 00. I think I prefer that a known dscp indicated pcn-traffic in the pcn-domain, ie non-pcn traffic uses other dscp(s). then the non-pcn traffic doesn't need to be touched by the pcn-mechanisms. Where you say > ECN marks are lost for PCN and non-PCN traffic. With a separate dscp, they're not lost for non-pcn traffic - nor for pcn-traffic if tunnel (or downgrade to BE) (assuming that ECN on pcn-traffic is really needed). I found some of 2 a bit confusing, as legacy node could mean a node outside the pcn-domain, or a misconfigured pcn-interior-node or a misconfigured pcn-boundary-node. You seem to introduce the concept of pure ecn nodes within the pcn-domain, which I don't agree with. > let 11-marked packets escape if all nodes of the PCN domain are PCN- > enabled why? On a separate topic, I think the encoding draft should also consider this issue. Re-reading http://www.watersprings.org/pub/id/draft-charny-pcn-comparison-00.txt about the requirement that a router doing admission marking must ensure it doesn't over-write onto a pkt that's already termination marked - this threatens to introduce implementation complexity of having to check the marking state of a pkt before marking. So an encoding scheme which allows a pkts to be both AM & TM would be beneficial. At least this should be on the evaluation criteria. phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 12 February 2008 16:08 > To: pcn > Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? > > Hi all, > > I am not so happy yet with the current version of the encoding > draft. I am worrying about extensibility of edge-to-edge PCN to > end-to-end PCN. I do not want push work towards end-to-end PCN in > the near future, but we should be aware that a wrong encoding > might close the door for end-to-end PCN. We should only > intentionally close the door or keep it open. > > I discuss two different marking schemes taking this issue into > account. > > 1. Non-extensible solution for edge-to-edge PCN > > When we do not want to extend PCN towards an end-to-end solution, > we can stick with edge-to-edge PCN islands. If we take the > decision that these islands do not support ECN, we can simply > reuse the ECN-bits for encoding. To take advantage of the marking > functionality of legacy ECN equipment, "excess-traffic" (ET) > should be mapped to ECN's CE (11) codepoint, and > "no-pre-congestion" (NP) as well as "admission-stop" (AS) should > be mapped to ECN's ECT(0) and ECT(1) (10, 01). Then, ECN's > codepoint not-ECT (00) is left over to indicate non-PCN traffic. > This scheme requires that traffic is remarked when entering a PCN > domain. All 11-marked packets must be dropped. Afterwards, all > non-PCN traffic is remarked to 00 and PCN traffic is remarked to > e.g. 01. Upon leaving the PCN domain, all traffic is reset to 00. > > Bad: This scheme is applicable only in a closed island where ECN > semantics are substituted by PCN semantics. It cannot be > extended to an end-to-end solution since it is not possible > to differentiate PCN from non-PCN traffic. > ECN marks are lost for PCN and non-PCN traffic. > > Good: PCN encoding does not require a new DSCP and PCN can be > applied to any DSCP allowing PCN support for various service > classes (DSCPs). > > > 2. Solution for end-to-end PCN treating edge-to-edge PCN as a > special case > > This requires the definition of a new "PCN DSCP" indicating that > endpoints (either host nodes or proxies) implement the semantics > of PCN instead of ECN. PCN treatment is only applied to traffic > with the PCN DSCP. However, ECN treatment is possibly applied to > PCN traffic by legacy nodes. A core question is: what is the > desired behavior in that case? Should CE-marking be different from > ET-marking or not? > a) ET=CE=11: legacy nodes throttle ECN flows and tear down PCN > flows in case of overload; > other mappings {NP, AS} -> {ECT(0), ECT(1)} > b) CE not used for PCN encoding: CE-marking always results from > overloaded ECN nodes. Therefore, endpoints should either drop > such packets or hand them to TCP if it is ECN-capable. > mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} > > Edge-to-edge PCN is a special case of this encoding scheme when > ingress and egress nodes of a PCN domain act as proxies for > endpoints. > This implies for PCN ingress nodes: drop all 11-marked PCN packets > and then mark the other PCN packets with NP > This implies for PCN egress nodes: > case a) remark all 01, 10, 11-marked PCN packets to 00 > Problem: 1. not-ECT flows with CE-marked packets by pure ECN > nodes within the PCN domain do not back off > 2. PCN traffic is terminated while non-PCN > traffic continues to send in case of congestion > when PCN domain contains pure ECN nodes > -> PCN traffic is squeezed out > case b) remark all 01, 10-marked PCN packets to 00; let 11-marked > packets escape if all nodes of the PCN domain are PCN-enabled > and drop them if the PCN domain has some nodes that are only > ECN-enabled. > > Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage > for non-PCN traffic. > > Bad: requires definition of new DSCP, cannot be used for different > traffic classes; Simultaneous usage of PCN and ECN not possible > > > If you think this kind of reflection is useful, I'd be happy to > see it in the encoding draft. > > I am interested in your opinion about closing the door for > end-to-end PCN or keeping it open. > > 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 > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 01:46:45 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDC228C6F1; Wed, 13 Feb 2008 01:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, 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 K-670wHnRCiH; Wed, 13 Feb 2008 01:46:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116F828C675; Wed, 13 Feb 2008 01:46:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB3928C675 for ; Wed, 13 Feb 2008 01:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9TXmnAkC0-M for ; Wed, 13 Feb 2008 01:46:41 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 605E43A6D7C for ; Wed, 13 Feb 2008 01:46:41 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 68AB8198E13; Wed, 13 Feb 2008 10:48:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5C0C2198DF0; Wed, 13 Feb 2008 10:48:04 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1D04E198DBE; Wed, 13 Feb 2008 10:48:03 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1D9m2V20756; Wed, 13 Feb 2008 10:48:02 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D1676C7F16; Wed, 13 Feb 2008 10:48:02 +0100 (CET) Message-ID: <47B2BC8E.2080107@informatik.uni-wuerzburg.de> Date: Wed, 13 Feb 2008 10:46:54 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34576@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34576@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end PCN? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > Michael > In the detail of what you write, some I agree with and some I don't > follow. However, I don't agree with the context you set it of "1. > Non-extensible solution for edge-to-edge PCN " & "2. Solution for > end-to-end PCN treating edge-to-edge PCN as a special case". For > instance, in 1 I think you're assuming that non_PCN traffic is > distinguished by setting the codepoint to 00. I think I prefer that a > known dscp indicated pcn-traffic in the pcn-domain, ie non-pcn traffic > uses other dscp(s). then the non-pcn traffic doesn't need to be touched > by the pcn-mechanisms. > You are right, but you consider a different scenario. I don't say we should follow 1, I am rather in favor of option 2 (like you). I just want to point out the implications of a pure ECN-bit solution. > Where you say > ECN marks are lost for PCN and non-PCN traffic. > With a separate dscp, they're not lost for non-pcn traffic - nor for > pcn-traffic if tunnel (or downgrade to BE) (assuming that ECN on > pcn-traffic is really needed). > That's another reason why I also find option 2 better than option 1. Regarding tunneling, I think this is a rather high price to save the ECN marks (and to not drop previously 11-marked CE packets). > I found some of 2 a bit confusing, as legacy node could mean a node > outside the pcn-domain, or a misconfigured pcn-interior-node or a > misconfigured pcn-boundary-node. You seem to introduce the concept of > pure ecn nodes within the pcn-domain, which I don't agree with. > Yes, that is what I have considered. Do you disagree with the term legacy node or do you find this scenario unlikely? I mean, do you assume that 100% of all nodes are upgraded when a PCN domain is defined? I can imagine that some older routers are reused for simple forwarding. But I'm the university guy who doesn't know the operations of providers so well. >> let 11-marked packets escape if all nodes of the PCN domain are PCN- >> enabled >> > why? > This applies to 2b where codepoint 11 is not used for PCN marking. If there are no pure ECN nodes in the PCN domain, 11-marked PCN packets do not need to be dropped by the PCN ingress (forgot to say that in the short description). Thus, all 11-marked PCN packets stem from previous ECN-nodes and can be savely conveyed to the endpoints to throttle the TCP senders. > > On a separate topic, I think the encoding draft should also consider > this issue. Re-reading > http://www.watersprings.org/pub/id/draft-charny-pcn-comparison-00.txt > about the requirement that a router doing admission marking must ensure > it doesn't over-write onto a pkt that's already termination marked - > this threatens to introduce implementation complexity of having to check > the marking state of a pkt before marking. So an encoding scheme which > allows a pkts to be both AM & TM would be beneficial. At least this > should be on the evaluation criteria. > I see that it possibly facilitates implementation. However, TM is a "stronger" marking that subsumes AM. Having codpoints indicating "no-pre-congestion" (NP), AM, TM, and AM&TM is a waste of bits. Therefore, I think that this criterion should be ranked rather low. Michael > phil > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Michael Menth >> Sent: 12 February 2008 16:08 >> To: pcn >> Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? >> >> Hi all, >> >> I am not so happy yet with the current version of the encoding >> draft. I am worrying about extensibility of edge-to-edge PCN to >> end-to-end PCN. I do not want push work towards end-to-end PCN in >> the near future, but we should be aware that a wrong encoding >> might close the door for end-to-end PCN. We should only >> intentionally close the door or keep it open. >> >> I discuss two different marking schemes taking this issue into >> account. >> >> 1. Non-extensible solution for edge-to-edge PCN >> >> When we do not want to extend PCN towards an end-to-end solution, >> we can stick with edge-to-edge PCN islands. If we take the >> decision that these islands do not support ECN, we can simply >> reuse the ECN-bits for encoding. To take advantage of the marking >> functionality of legacy ECN equipment, "excess-traffic" (ET) >> should be mapped to ECN's CE (11) codepoint, and >> "no-pre-congestion" (NP) as well as "admission-stop" (AS) should >> be mapped to ECN's ECT(0) and ECT(1) (10, 01). Then, ECN's >> codepoint not-ECT (00) is left over to indicate non-PCN traffic. >> This scheme requires that traffic is remarked when entering a PCN >> domain. All 11-marked packets must be dropped. Afterwards, all >> non-PCN traffic is remarked to 00 and PCN traffic is remarked to >> e.g. 01. Upon leaving the PCN domain, all traffic is reset to 00. >> >> Bad: This scheme is applicable only in a closed island where ECN >> semantics are substituted by PCN semantics. It cannot be >> extended to an end-to-end solution since it is not possible >> to differentiate PCN from non-PCN traffic. >> ECN marks are lost for PCN and non-PCN traffic. >> >> Good: PCN encoding does not require a new DSCP and PCN can be >> applied to any DSCP allowing PCN support for various service >> classes (DSCPs). >> >> >> 2. Solution for end-to-end PCN treating edge-to-edge PCN as a >> special case >> >> This requires the definition of a new "PCN DSCP" indicating that >> endpoints (either host nodes or proxies) implement the semantics >> of PCN instead of ECN. PCN treatment is only applied to traffic >> with the PCN DSCP. However, ECN treatment is possibly applied to >> PCN traffic by legacy nodes. A core question is: what is the >> desired behavior in that case? Should CE-marking be different from >> ET-marking or not? >> a) ET=CE=11: legacy nodes throttle ECN flows and tear down PCN >> flows in case of overload; >> other mappings {NP, AS} -> {ECT(0), ECT(1)} >> b) CE not used for PCN encoding: CE-marking always results from >> overloaded ECN nodes. Therefore, endpoints should either drop >> such packets or hand them to TCP if it is ECN-capable. >> mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} >> >> Edge-to-edge PCN is a special case of this encoding scheme when >> ingress and egress nodes of a PCN domain act as proxies for >> endpoints. >> This implies for PCN ingress nodes: drop all 11-marked PCN packets >> and then mark the other PCN packets with NP >> This implies for PCN egress nodes: >> case a) remark all 01, 10, 11-marked PCN packets to 00 >> Problem: 1. not-ECT flows with CE-marked packets by pure ECN >> nodes within the PCN domain do not back off >> 2. PCN traffic is terminated while non-PCN >> traffic continues to send in case of congestion >> when PCN domain contains pure ECN nodes >> -> PCN traffic is squeezed out >> case b) remark all 01, 10-marked PCN packets to 00; let 11-marked >> packets escape if all nodes of the PCN domain are PCN-enabled >> and drop them if the PCN domain has some nodes that are only >> ECN-enabled. >> >> Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage >> for non-PCN traffic. >> >> Bad: requires definition of new DSCP, cannot be used for different >> traffic classes; Simultaneous usage of PCN and ECN not possible >> >> >> If you think this kind of reflection is useful, I'd be happy to >> see it in the encoding draft. >> >> I am interested in your opinion about closing the door for >> end-to-end PCN or keeping it open. >> >> 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 >> http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 08:06:50 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9035F28C8C7; Wed, 13 Feb 2008 08:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 U6B7vOzKR-Uh; Wed, 13 Feb 2008 08:06:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8999628C8FA; Wed, 13 Feb 2008 08:06:46 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2513A6F99 for ; Wed, 13 Feb 2008 08:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPSrm1m8LHWa for ; Wed, 13 Feb 2008 08:06:37 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 71D8228C910 for ; Wed, 13 Feb 2008 08:05:42 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1DG6tQ18130; Wed, 13 Feb 2008 16:06:55 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.113] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 11:06:18 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Feb 2008 11:06:17 -0500 To: "Geib, Ruediger" From: "Kwok-Ho Chan" In-Reply-To: <1B6169C658325341A3B8066E23919E1CCC7F70@S4DE8PSAANK.mitte.t -com.de> References: <47B1C448.6020201@informatik.uni-wuerzburg.de> <1B6169C658325341A3B8066E23919E1CCC7F70@S4DE8PSAANK.mitte.t-com.de> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 Feb 2008 16:06:18.0553 (UTC) FILETIME=[5E231A90:01C86E5A] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger: The encoding comparison draft currently calls out the different encoding options' satisfying RFC 4774 (Alternate ECN) concerns. With an eye on trying to allow the same encoding be used for edge-to-edge deployment now and end-to-end in the future. This is not clearly state in the draft. Hence the notion of edge-to-edge and end-to-end should be added as one of the criteria at the beginning of the draft and bring this out more clearly in the encoding option discussion sections. Thanks! -- Kwok -- At 03:07 AM 2/13/2008, Geib, Ruediger wrote: >Hello Michael, > >a discussion like the one you've proposed should find a place in the >encoding draft until there's an agreed solution on how to proceed >on the issue. I don't it must be in the core document (an annex may >do), but your concerns are valid and shouldn't be ignored. > >Regards, > >Ruediger > >| -----Original Message----- >| From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >| Sent: Tuesday, February 12, 2008 5:08 PM >| To: pcn >| Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? >| >| Hi all, >| >| I am not so happy yet with the current version of the >| encoding draft. I am worrying about extensibility of >| edge-to-edge PCN to end-to-end PCN. I do not want push work >| towards end-to-end PCN in the near future, but we should be >| aware that a wrong encoding might close the door for >| end-to-end PCN. We should only intentionally close the door >| or keep it open. >| >| I discuss two different marking schemes taking this issue >| into account. >| >| 1. Non-extensible solution for edge-to-edge PCN >| >| When we do not want to extend PCN towards an end-to-end >| solution, we can stick with edge-to-edge PCN islands. If we >| take the decision that these islands do not support ECN, we >| can simply reuse the ECN-bits for encoding. To take advantage >| of the marking functionality of legacy ECN equipment, >| "excess-traffic" (ET) should be mapped to ECN's CE (11) >| codepoint, and "no-pre-congestion" (NP) as well as >| "admission-stop" (AS) should be mapped to ECN's ECT(0) and >| ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left >| over to indicate non-PCN traffic. >| This scheme requires that traffic is remarked when entering a >| PCN domain. All 11-marked packets must be dropped. >| Afterwards, all non-PCN traffic is remarked to 00 and PCN >| traffic is remarked to e.g. 01. Upon leaving the PCN domain, >| all traffic is reset to 00. >| >| Bad: This scheme is applicable only in a closed island where ECN >| semantics are substituted by PCN semantics. It cannot be >| extended to an end-to-end solution since it is not possible >| to differentiate PCN from non-PCN traffic. >| ECN marks are lost for PCN and non-PCN traffic. >| >| Good: PCN encoding does not require a new DSCP and PCN can be >| applied to any DSCP allowing PCN support for various service >| classes (DSCPs). >| >| >| 2. Solution for end-to-end PCN treating edge-to-edge PCN as a >| special case >| >| This requires the definition of a new "PCN DSCP" indicating >| that endpoints (either host nodes or proxies) implement the >| semantics of PCN instead of ECN. PCN treatment is only >| applied to traffic with the PCN DSCP. However, ECN treatment >| is possibly applied to PCN traffic by legacy nodes. A core >| question is: what is the desired behavior in that case? >| Should CE-marking be different from ET-marking or not? >| a) ET=CE=11: legacy nodes throttle ECN flows and tear down >| PCN flows in case of overload; other mappings {NP, AS} -> >| {ECT(0), ECT(1)} >| b) CE not used for PCN encoding: CE-marking always results >| from overloaded ECN nodes. Therefore, endpoints should >| either drop such packets or hand them to TCP if it is ECN-capable. >| mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} >| >| Edge-to-edge PCN is a special case of this encoding scheme >| when ingress and egress nodes of a PCN domain act as proxies >| for endpoints. >| This implies for PCN ingress nodes: drop all 11-marked PCN >| packets and then mark the other PCN packets with NP This >| implies for PCN egress nodes: >| case a) remark all 01, 10, 11-marked PCN packets to 00 >| Problem: 1. not-ECT flows with CE-marked packets by pure ECN >| nodes within the PCN domain do not back off >| 2. PCN traffic is terminated while non-PCN >| traffic continues to send in case of congestion >| when PCN domain contains pure ECN nodes >| -> PCN traffic is squeezed out case b) >| remark all 01, 10-marked PCN packets to 00; let 11-marked >| packets escape if all nodes of the PCN domain are PCN-enabled >| and drop them if the PCN domain has some nodes that are only >| ECN-enabled. >| >| Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage >| for non-PCN traffic. >| >| Bad: requires definition of new DSCP, cannot be used for different >| traffic classes; Simultaneous usage of PCN and ECN not possible >| >| >| If you think this kind of reflection is useful, I'd be happy >| to see it in the encoding draft. >| >| I am interested in your opinion about closing the door for >| end-to-end PCN or keeping it open. >| >| 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 >| http://www.ietf.org/mailman/listinfo/pcn >| >_______________________________________________ >PCN mailing list >PCN@ietf.org >http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 08:48:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1B428C90E; Wed, 13 Feb 2008 08:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 bys7OCUgn1WY; Wed, 13 Feb 2008 08:48:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364FF3A6BE9; Wed, 13 Feb 2008 08:48:04 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF8228C904 for ; Wed, 13 Feb 2008 08:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1UuYwVgc4c5 for ; Wed, 13 Feb 2008 08:47:59 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A277B3A6BE9 for ; Wed, 13 Feb 2008 08:47:57 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 16:49:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 16:49:18 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34586@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding: keep the door open for end-to-end PCN? Thread-Index: AchuWqhqDWhmO5JOSoGEtxu/gDKu4wABO0mA From: To: , X-OriginalArrivalTime: 13 Feb 2008 16:49:19.0911 (UTC) FILETIME=[60BF1370:01C86E60] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Kwok Rather than "satisfying 4774" & "end-to-end" being the criteria, I think it would be better to have criteria that are things like: what assumptions are made? (the real difference between edge-to-edge & end-to-end ecn) What is the impact of a misconfigured egress node? What's the impact on ecn, under particular assumptions? (4774 inspires some of these questions) phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Kwok-Ho Chan > Sent: 13 February 2008 16:06 > To: Geib, Ruediger > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end PCN? > > Hi Ruediger: > The encoding comparison draft currently calls out the different > encoding options' satisfying RFC 4774 (Alternate ECN) concerns. > With an eye on trying to allow the same encoding be used for > edge-to-edge deployment now and end-to-end in the future. > This is not clearly state in the draft. > > Hence the notion of edge-to-edge and end-to-end should be added > as one of the criteria at the beginning of the draft and bring this out > more clearly in the encoding option discussion sections. > > Thanks! > -- Kwok -- > > At 03:07 AM 2/13/2008, Geib, Ruediger wrote: > >Hello Michael, > > > >a discussion like the one you've proposed should find a place in the > >encoding draft until there's an agreed solution on how to proceed > >on the issue. I don't it must be in the core document (an annex may > >do), but your concerns are valid and shouldn't be ignored. > > > >Regards, > > > >Ruediger > > > >| -----Original Message----- > >| From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >| Sent: Tuesday, February 12, 2008 5:08 PM > >| To: pcn > >| Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? > >| > >| Hi all, > >| > >| I am not so happy yet with the current version of the > >| encoding draft. I am worrying about extensibility of > >| edge-to-edge PCN to end-to-end PCN. I do not want push work > >| towards end-to-end PCN in the near future, but we should be > >| aware that a wrong encoding might close the door for > >| end-to-end PCN. We should only intentionally close the door > >| or keep it open. > >| > >| I discuss two different marking schemes taking this issue > >| into account. > >| > >| 1. Non-extensible solution for edge-to-edge PCN > >| > >| When we do not want to extend PCN towards an end-to-end > >| solution, we can stick with edge-to-edge PCN islands. If we > >| take the decision that these islands do not support ECN, we > >| can simply reuse the ECN-bits for encoding. To take advantage > >| of the marking functionality of legacy ECN equipment, > >| "excess-traffic" (ET) should be mapped to ECN's CE (11) > >| codepoint, and "no-pre-congestion" (NP) as well as > >| "admission-stop" (AS) should be mapped to ECN's ECT(0) and > >| ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left > >| over to indicate non-PCN traffic. > >| This scheme requires that traffic is remarked when entering a > >| PCN domain. All 11-marked packets must be dropped. > >| Afterwards, all non-PCN traffic is remarked to 00 and PCN > >| traffic is remarked to e.g. 01. Upon leaving the PCN domain, > >| all traffic is reset to 00. > >| > >| Bad: This scheme is applicable only in a closed island where ECN > >| semantics are substituted by PCN semantics. It cannot be > >| extended to an end-to-end solution since it is not possible > >| to differentiate PCN from non-PCN traffic. > >| ECN marks are lost for PCN and non-PCN traffic. > >| > >| Good: PCN encoding does not require a new DSCP and PCN can be > >| applied to any DSCP allowing PCN support for various service > >| classes (DSCPs). > >| > >| > >| 2. Solution for end-to-end PCN treating edge-to-edge PCN as a > >| special case > >| > >| This requires the definition of a new "PCN DSCP" indicating > >| that endpoints (either host nodes or proxies) implement the > >| semantics of PCN instead of ECN. PCN treatment is only > >| applied to traffic with the PCN DSCP. However, ECN treatment > >| is possibly applied to PCN traffic by legacy nodes. A core > >| question is: what is the desired behavior in that case? > >| Should CE-marking be different from ET-marking or not? > >| a) ET=CE=11: legacy nodes throttle ECN flows and tear down > >| PCN flows in case of overload; other mappings {NP, AS} -> > >| {ECT(0), ECT(1)} > >| b) CE not used for PCN encoding: CE-marking always results > >| from overloaded ECN nodes. Therefore, endpoints should > >| either drop such packets or hand them to TCP if it is ECN-capable. > >| mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} > >| > >| Edge-to-edge PCN is a special case of this encoding scheme > >| when ingress and egress nodes of a PCN domain act as proxies > >| for endpoints. > >| This implies for PCN ingress nodes: drop all 11-marked PCN > >| packets and then mark the other PCN packets with NP This > >| implies for PCN egress nodes: > >| case a) remark all 01, 10, 11-marked PCN packets to 00 > >| Problem: 1. not-ECT flows with CE-marked packets by pure ECN > >| nodes within the PCN domain do not back off > >| 2. PCN traffic is terminated while non-PCN > >| traffic continues to send in case of congestion > >| when PCN domain contains pure ECN nodes > >| -> PCN traffic is squeezed out case b) > >| remark all 01, 10-marked PCN packets to 00; let 11-marked > >| packets escape if all nodes of the PCN domain are PCN-enabled > >| and drop them if the PCN domain has some nodes that are only > >| ECN-enabled. > >| > >| Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage > >| for non-PCN traffic. > >| > >| Bad: requires definition of new DSCP, cannot be used for different > >| traffic classes; Simultaneous usage of PCN and ECN not possible > >| > >| > >| If you think this kind of reflection is useful, I'd be happy > >| to see it in the encoding draft. > >| > >| I am interested in your opinion about closing the door for > >| end-to-end PCN or keeping it open. > >| > >| 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 > >| http://www.ietf.org/mailman/listinfo/pcn > >| > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >http://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 13 09:23:16 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8585928C916; Wed, 13 Feb 2008 09:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 sLoqjkFObKUe; Wed, 13 Feb 2008 09:23:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F9828C8EE; Wed, 13 Feb 2008 09:23:15 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB85828C8ED for ; Wed, 13 Feb 2008 09:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+vqy6q++zhx for ; Wed, 13 Feb 2008 09:23:08 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A391228C873 for ; Wed, 13 Feb 2008 09:23:08 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1DHOMe01259; Wed, 13 Feb 2008 17:24:22 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.113] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 12:24:17 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Feb 2008 12:24:15 -0500 To: From: "Kwok-Ho Chan" In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34586@E03MVZ1-UKDY.doma in1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34586@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 Feb 2008 17:24:17.0133 (UTC) FILETIME=[42C9C1D0:01C86E65] Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil: Thanks! Please see inline below. -- Kwok -- At 11:49 AM 2/13/2008, philip.eardley@bt.com wrote: >Kwok > >Rather than "satisfying 4774" & "end-to-end" being the criteria, I think >it would be better to have criteria that are things like: what >assumptions are made? (the real difference between edge-to-edge & >end-to-end ecn) More of a top down approach, the draft currently is more bottom up (with 4774, etc). >What is the impact of a misconfigured egress node? I believe there are discussion of this in the draft currently, we have also touched on misconfigured ingress node (leaking of ECN packets into PCN domain). Need to bring them out more clearly and then tie this back into how they may affect the edge-to-edge and end-to-end issues (the encoding part only). >What's the impact on ecn, under particular assumptions? (4774 inspires >some of these questions) > >phil > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Kwok-Ho Chan > > Sent: 13 February 2008 16:06 > > To: Geib, Ruediger > > Cc: pcn@ietf.org > > Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end >PCN? > > > > Hi Ruediger: > > The encoding comparison draft currently calls out the different > > encoding options' satisfying RFC 4774 (Alternate ECN) concerns. > > With an eye on trying to allow the same encoding be used for > > edge-to-edge deployment now and end-to-end in the future. > > This is not clearly state in the draft. > > > > Hence the notion of edge-to-edge and end-to-end should be added > > as one of the criteria at the beginning of the draft and bring this >out > > more clearly in the encoding option discussion sections. > > > > Thanks! > > -- Kwok -- > > > > At 03:07 AM 2/13/2008, Geib, Ruediger wrote: > > >Hello Michael, > > > > > >a discussion like the one you've proposed should find a place in the > > >encoding draft until there's an agreed solution on how to proceed > > >on the issue. I don't it must be in the core document (an annex may > > >do), but your concerns are valid and shouldn't be ignored. > > > > > >Regards, > > > > > >Ruediger > > > > > >| -----Original Message----- > > >| From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > >| Sent: Tuesday, February 12, 2008 5:08 PM > > >| To: pcn > > >| Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN? > > >| > > >| Hi all, > > >| > > >| I am not so happy yet with the current version of the > > >| encoding draft. I am worrying about extensibility of > > >| edge-to-edge PCN to end-to-end PCN. I do not want push work > > >| towards end-to-end PCN in the near future, but we should be > > >| aware that a wrong encoding might close the door for > > >| end-to-end PCN. We should only intentionally close the door > > >| or keep it open. > > >| > > >| I discuss two different marking schemes taking this issue > > >| into account. > > >| > > >| 1. Non-extensible solution for edge-to-edge PCN > > >| > > >| When we do not want to extend PCN towards an end-to-end > > >| solution, we can stick with edge-to-edge PCN islands. If we > > >| take the decision that these islands do not support ECN, we > > >| can simply reuse the ECN-bits for encoding. To take advantage > > >| of the marking functionality of legacy ECN equipment, > > >| "excess-traffic" (ET) should be mapped to ECN's CE (11) > > >| codepoint, and "no-pre-congestion" (NP) as well as > > >| "admission-stop" (AS) should be mapped to ECN's ECT(0) and > > >| ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left > > >| over to indicate non-PCN traffic. > > >| This scheme requires that traffic is remarked when entering a > > >| PCN domain. All 11-marked packets must be dropped. > > >| Afterwards, all non-PCN traffic is remarked to 00 and PCN > > >| traffic is remarked to e.g. 01. Upon leaving the PCN domain, > > >| all traffic is reset to 00. > > >| > > >| Bad: This scheme is applicable only in a closed island where ECN > > >| semantics are substituted by PCN semantics. It cannot be > > >| extended to an end-to-end solution since it is not possible > > >| to differentiate PCN from non-PCN traffic. > > >| ECN marks are lost for PCN and non-PCN traffic. > > >| > > >| Good: PCN encoding does not require a new DSCP and PCN can be > > >| applied to any DSCP allowing PCN support for various service > > >| classes (DSCPs). > > >| > > >| > > >| 2. Solution for end-to-end PCN treating edge-to-edge PCN as a > > >| special case > > >| > > >| This requires the definition of a new "PCN DSCP" indicating > > >| that endpoints (either host nodes or proxies) implement the > > >| semantics of PCN instead of ECN. PCN treatment is only > > >| applied to traffic with the PCN DSCP. However, ECN treatment > > >| is possibly applied to PCN traffic by legacy nodes. A core > > >| question is: what is the desired behavior in that case? > > >| Should CE-marking be different from ET-marking or not? > > >| a) ET=CE=11: legacy nodes throttle ECN flows and tear down > > >| PCN flows in case of overload; other mappings {NP, AS} -> > > >| {ECT(0), ECT(1)} > > >| b) CE not used for PCN encoding: CE-marking always results > > >| from overloaded ECN nodes. Therefore, endpoints should > > >| either drop such packets or hand them to TCP if it is ECN-capable. > > >| mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} > > >| > > >| Edge-to-edge PCN is a special case of this encoding scheme > > >| when ingress and egress nodes of a PCN domain act as proxies > > >| for endpoints. > > >| This implies for PCN ingress nodes: drop all 11-marked PCN > > >| packets and then mark the other PCN packets with NP This > > >| implies for PCN egress nodes: > > >| case a) remark all 01, 10, 11-marked PCN packets to 00 > > >| Problem: 1. not-ECT flows with CE-marked packets by pure >ECN > > >| nodes within the PCN domain do not back off > > >| 2. PCN traffic is terminated while non-PCN > > >| traffic continues to send in case of congestion > > >| when PCN domain contains pure ECN nodes > > >| -> PCN traffic is squeezed out case b) > > >| remark all 01, 10-marked PCN packets to 00; let 11-marked > > >| packets escape if all nodes of the PCN domain are >PCN-enabled > > >| and drop them if the PCN domain has some nodes that are >only > > >| ECN-enabled. > > >| > > >| Good: Scheme keeps the door open for end-to-end PCN; Allows >ECN-usage > > >| for non-PCN traffic. > > >| > > >| Bad: requires definition of new DSCP, cannot be used for different > > >| traffic classes; Simultaneous usage of PCN and ECN not >possible > > >| > > >| > > >| If you think this kind of reflection is useful, I'd be happy > > >| to see it in the encoding draft. > > >| > > >| I am interested in your opinion about closing the door for > > >| end-to-end PCN or keeping it open. > > >| > > >| 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 > > >| http://www.ietf.org/mailman/listinfo/pcn > > >| > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >http://www.ietf.org/mailman/listinfo/pcn > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 15 02:50:20 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EA73A6A6D; Fri, 15 Feb 2008 02:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 mIRp4Q7D+iLS; Fri, 15 Feb 2008 02:50:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0913A69CC; Fri, 15 Feb 2008 02:50:19 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8864D3A69CC for ; Fri, 15 Feb 2008 02:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP-wGLYlVuth for ; Fri, 15 Feb 2008 02:50:17 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 425373A6973 for ; Fri, 15 Feb 2008 02:50:17 -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 m1FApYgo017675 for ; Fri, 15 Feb 2008 11:51:37 +0100 (MET) From: "Georgios Karagiannis" To: Date: Fri, 15 Feb 2008 11:51:28 +0100 Message-ID: <002301c86fc0$ba979780$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchvwLeHQ3+zab15SuCf+Xgy8T47Gg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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]); Fri, 15 Feb 2008 11:51:37 +0100 (MET) Subject: [PCN] (new) possibilities of combining LC-PCN and SM (in at least PCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Dear all I have tried here, to write an updated version of the LC-PCN algorithm, which can bring the SM (Single marking) and LC-PCN (Load Control -PCN) solutions closer to each other! Please note that the LC-PCN authors are willing to update the current version of the LC-PCN draft according to the below updated algorithm and to submit it to the IETF before the deadline of 25 February! New description ------------- Please note that the below description does not describe how the use of the probing functionality during admission control and the use of affected marking for ECMP solution during flow termination should be performed. These two features can be added as optional, later on. * U is specified as in the SM draft! * N is specified as in the LC-PCN draft * Features in the PCN_interior_node: ------------------------ The excess rate measurement is done in a similar way as is done for SM, but the measurement should be done before drop but PCN_marking should be done after drop. This means that marked packets are preferentially not dropped. Furthermore the constant N should be used such that the marked excess rate can represent also high level of excess rate. The calculated excess rate should be divided by N (when N>=1) This can be implemented in SM by marking every N-th packet (or rather byte) instead of marking each packet (or byte) * Features in the PCN_egress_node ------------------------ **** Admission control: -------------------- The admission decision is similar to SM, based on the CLE, by measuring the rate of the received PCN_marked packets and by multiplying it by N. When CLE higher than a predefined/preconfigured threshold, e.g., 1% then in admission state. See Section 2.4.1 in: http://www.ietf.org/internet-drafts/draft-charny-pcn-single-marking-03.txt Note that the CLE is calculated as given in Section 11.3. Appendix, in: http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture-04.tx t The PCN_egress_node informs the PCN_ingress node that the requesting flow is admitted or rejected (if in admission control state). Note that the above feature is not an SM feature. ***** Flow Termination: ------------- In order to detect the trigger for flow termination, we use the solution proposed in Section 2.4.2 in the SM draft: http://www.ietf.org/internet-drafts/draft-charny-pcn-single-marking-03.txt The PCN_egress guard/activates the flow termination control with a trigger computed from the ratio of measured marked and unmarked traffic rates. Note that before using the above ratio to calculate the trigger, the rate of the marked traffic, is multiplied by N. Note that: If (U * admission control threshold) at the PCN_interior nodes is configured to be lower than the packet dropping threshold at the PCN_interior node, then the PCN_egress_node can e.g., calculate the flow termination trigger in the following way: If (marked_rate/unmarked_rate) >= (U - 1) THEN the flow termination trigger should be activated. If (U * admission control threshold) at the PCN_interior nodes is configured to be equal or higher than the packet dropping threshold at the PCN_interior node, then the PCN_egress_node can e.g., calculate the flow termination trigger in the following way: If (marked_rate/(unmarked_rate + marked_rate)) >= (U - 1) THEN the flow termination trigger should be activated. When this trigger is detected then the egress has to store the value of the absolute rate of the marked_rate traffic, say: PCN_upper_rate_egress The excess rate that is above this threshold, say incoming_PCN_marking_rate is used to calculate the number of flows to be terminated, say: terminated_bandwidth. The calculation of terminated_bandwidth is done in a similar way as described in Section 4.2.3 in current version of the LC-PCN draft. For the flows that should be terminated the PCN_egress_node informs the PCN_ingress_node to terminate them. * Features in the PCN_ingress_node ------------------------------------ ****** Admission control: ----------------- Admits or rejects the flow depending on the sent report by the egress. This feature is not a SM feature ****** Flow termination: -------------------- The flows that are termination notified by the PCN_egress node have to be terminated by PCN_ingress node. In addition the PCN_ingress node informs the associated flow sender about the problem. This feature is not a SM feature. ------------------------------------------------------------ Important: Note that if probing and affected marking options are used then: * Probing should be accomplished in the same way as described currently in the LC-PCN draft. * Affected Marking is used at the PCN_interior nodes in the same way as is currently described in LC-PCN. At the egress, Affected Marked packets are used to select the flows that have to be terminated, and to calculate the flow termination trigger, instead of using the PCN unmarked packets. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 15 06:18:28 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE3528D1B1; Fri, 15 Feb 2008 06:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-2.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 8JaMM4UqQ32M; Fri, 15 Feb 2008 06:18:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D0A3A6ACE; Fri, 15 Feb 2008 06:18:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8681628D162 for ; Fri, 15 Feb 2008 06:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idV141vJ3+lx for ; Fri, 15 Feb 2008 06:18:24 -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 D68843A6ACE for ; Fri, 15 Feb 2008 06:18:23 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2008 09:19:44 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1FEJifp015476; Fri, 15 Feb 2008 09:19:44 -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.12.10/8.12.6) with ESMTP id m1FEJZSG023961; Fri, 15 Feb 2008 14:19:44 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); Fri, 15 Feb 2008 09:19:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 09:19:31 -0500 Message-ID: In-Reply-To: <002301c86fc0$ba979780$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] (new) possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) Thread-Index: AchvwLeHQ3+zab15SuCf+Xgy8T47GgAGzj/w From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , X-OriginalArrivalTime: 15 Feb 2008 14:19:33.0192 (UTC) FILETIME=[C9121480:01C86FDD] Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [PCN] (new) possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, This seems to be a blend of SM and 3 SM functionality - right? Would it be correct to summarize this proposal as follows: 1) excess rate marking with a slowdown (as in 3sm) 2) single marking thresholds and single marking codepoint as in SM 3) preference to drop unmarked rather than marked packets (SM prefers preferential drop of marked packets) 4) use of marked traffic rate (times the slowdown factor) vs unmarked traffic rate at the egress to compute the amount of traffic to be dropped (equivalent to what SM does when no loss, not equivalent in the presence of loss); the trigger is as in SM. 5) termintation and admission decisions done at the egress, and signaling tells the ingress specific fows to terminate (or to stop/start admitting). This seems to be as in 3SM. Did I miss any other differences? What do you see as the benefits of this proposal compared to CL, SM and 3SM? Have any performance studies been done? Thank you, Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Friday, February 15, 2008 5:51 AM > To: pcn@ietf.org > Subject: [PCN] (new) possibilities of combining LC-PCN and SM > (in at leastPCN-interior nodes) > > Dear all > > I have tried here, to write an updated version of the LC-PCN > algorithm, which can bring the SM (Single marking) and LC-PCN > (Load Control -PCN) solutions closer to each other! > > Please note that the LC-PCN authors are willing to update the > current version of the LC-PCN draft according to the below > updated algorithm and to submit it to the IETF before the deadline of > 25 February! > > > New description > ------------- > > Please note that the below description does not describe how > the use of the > probing functionality > during admission control and the use of affected marking for > ECMP solution > during flow > termination should be performed. These two features can be added as > optional, later on. > > > * U is specified as in the SM draft! > * N is specified as in the LC-PCN draft > > * Features in the PCN_interior_node: > ------------------------ > The excess rate measurement is done in a similar way as is > done for SM, but > the measurement should > be done before drop but PCN_marking should be done after drop. > This means that marked packets are preferentially not dropped. > > Furthermore the constant N should be used such that the > marked excess rate > can represent also > high level of excess rate. The calculated excess rate should > be divided by N > (when N>=1) > > This can be implemented in SM by marking every N-th packet > (or rather byte) > instead > of marking each packet (or byte) > > > * Features in the PCN_egress_node > ------------------------ > > **** Admission control: > -------------------- > > The admission decision is similar to SM, based on the CLE, by > measuring the > rate of > the received PCN_marked packets and by multiplying it by N. > When CLE higher > than a > predefined/preconfigured threshold, e.g., 1% then in admission state. > See Section 2.4.1 in: > http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma rking-03.txt > > Note that the CLE is calculated as given in Section 11.3. > Appendix, in: > http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-arch itecture-04.tx > t > > > > The PCN_egress_node informs the PCN_ingress node that the > requesting flow is > admitted or > rejected (if in admission control state). > Note that the above feature is not an SM feature. > > ***** Flow Termination: > ------------- > > In order to detect the trigger for flow termination, we use > the solution > proposed in Section 2.4.2 in the SM draft: > http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma rking-03.txt > > The PCN_egress guard/activates the flow termination control > with a trigger > computed from the ratio of measured marked and unmarked > traffic rates. Note > that > before using the above ratio to calculate the trigger, the > rate of the > marked traffic, is multiplied by N. > > Note that: > > If (U * admission control threshold) at the PCN_interior > nodes is configured > to be lower > than the packet dropping threshold at the PCN_interior node, then the > PCN_egress_node > can e.g., calculate the flow termination trigger in the following way: > > If (marked_rate/unmarked_rate) >= (U - 1) > THEN the flow termination trigger should be activated. > > > If (U * admission control threshold) at the PCN_interior > nodes is configured > to be equal or higher > than the packet dropping threshold at the PCN_interior node, then the > PCN_egress_node > can e.g., calculate the flow termination trigger in the following way: > > If (marked_rate/(unmarked_rate + marked_rate)) >= (U - 1) > THEN the flow termination trigger should be activated. > > When this trigger is detected then the egress has to store > the value of the > absolute rate of the marked_rate traffic, say: > PCN_upper_rate_egress > > The excess rate that is above this threshold, say > incoming_PCN_marking_rate > is used to calculate the number of flows to be terminated, say: > terminated_bandwidth. > The calculation of terminated_bandwidth is done in a similar way as > described in Section 4.2.3 in current version of > the LC-PCN draft. > > > For the flows that should be terminated the PCN_egress_node informs > the PCN_ingress_node to terminate them. > > * Features in the PCN_ingress_node > ------------------------------------ > > ****** Admission control: > ----------------- > Admits or rejects the flow depending on the sent report by the egress. > This feature is not a SM feature > > > ****** Flow termination: > -------------------- > The flows that are termination notified by the PCN_egress > node have to be > terminated by PCN_ingress node. In addition the PCN_ingress > node informs > the associated flow sender about the problem. > This feature is not a SM feature. > > > ------------------------------------------------------------ > > Important: Note that if probing and affected marking options > are used then: > > * Probing should be accomplished in the same way as described > currently in > the LC-PCN draft. > > * Affected Marking is used at the PCN_interior nodes in the > same way as is > currently described in LC-PCN. > At the egress, Affected Marked packets are used to select the > flows that have to be terminated, and to calculate the flow > termination > trigger, instead of using the PCN unmarked packets. > > > > > Best regards, > Georgios > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 15 06:46:44 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB4E28D1F2; Fri, 15 Feb 2008 06:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.036 X-Spam-Level: X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 PZyfQbUe0hup; Fri, 15 Feb 2008 06:46:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5BD28D17D; Fri, 15 Feb 2008 06:46:43 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34DE3A67DB for ; Fri, 15 Feb 2008 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xGAeoNMSXVk for ; Fri, 15 Feb 2008 06:46:40 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 296F03A6A8C for ; Fri, 15 Feb 2008 06:46:39 -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 m1FElspk006250; Fri, 15 Feb 2008 15:47:57 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" References: <002301c86fc0$ba979780$810c5982@dynamic.ewi.utwente.nl> Date: Fri, 15 Feb 2008 15:47:51 +0100 Message-ID: <003f01c86fe1$c065c940$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchvwLeHQ3+zab15SuCf+Xgy8T47GgAGzj/wAACK3/A= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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]); Fri, 15 Feb 2008 15:47:58 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] (new) possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna I have not studied points 1) to 5) in detail, so I may be wrong in my following answers. I think that I can agree with points 1) to 4). Regarding point 5) I do think that the admission and termination decissions and calculations of the excess rate is different than the ones specified in 3SM. The main differeces between LC-PCN and CL/SM are: * LC_PCN measures the excess rate that is used to provide admission control and flow termination decissions. CL and SM measure the troughput to calculate the number of flows that can be terminated. * In LC_PCN the admission control and flow termination decissions are done by the PCN_egress! In CL and SM the admission control and flow termination decissions are done by the PCN_egress and PCN_ingress! The benefit of taking the decissions by the PCN_egress instead of the PCN_ingress is that measurements and decissions can be done in one place/location. Thus one entity, that in this case is the PCN_egress can take all the required decissions. In the situations of CL and SM both the PCN_egress and PCN_ingress are needed to provide the same decissions. * LC-PCN describes in detail how probing and Affected marking features can be used. Regarding, the main differences between LC_PCN and 3SM, in order to be able to do that I will have to study the last version of 3SM in more detail. However, the differences are related to the way of how the excess rate is used to provide admission control and to selectthe number of flows that can be terminated. Regarding simulations, we have some old simulations that do not take into account all PCN related requirements and asuumptions. We need tyo redo these simulations! It will be great if we could discuss all the simulation related issues in Philadelphia! Please note that I will be able to come to the 71st IETF in Philadelphia! We will try to update the draft in time and submit it before the 25th of February! Bst regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: vrijdag 15 februari 2008 15:20 > To: Georgios Karagiannis; pcn@ietf.org > Subject: RE: [PCN] (new) possibilities of combining LC-PCN > and SM (in at leastPCN-interior nodes) > > Georgios, > > This seems to be a blend of SM and 3 SM functionality - > right? Would it be correct to summarize this proposal as follows: > > 1) excess rate marking with a slowdown (as in 3sm) > 2) single marking thresholds and single marking codepoint as in SM > 3) preference to drop unmarked rather than marked packets (SM > prefers preferential drop of marked packets) > 4) use of marked traffic rate (times the slowdown factor) vs > unmarked traffic rate at the egress to compute the amount of > traffic to be dropped (equivalent to what SM does when no > loss, not equivalent in the presence of loss); the trigger > is as in SM. > 5) termintation and admission decisions done at the egress, > and signaling tells the ingress specific fows to terminate > (or to stop/start admitting). This seems to be as in 3SM. > > Did I miss any other differences? > > What do you see as the benefits of this proposal compared to > CL, SM and 3SM? > > Have any performance studies been done? > > Thank you, > Anna > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: Friday, February 15, 2008 5:51 AM > > To: pcn@ietf.org > > Subject: [PCN] (new) possibilities of combining LC-PCN and > SM (in at > > leastPCN-interior nodes) > > > > Dear all > > > > I have tried here, to write an updated version of the LC-PCN > > algorithm, which can bring the SM (Single marking) and LC-PCN (Load > > Control -PCN) solutions closer to each other! > > > > Please note that the LC-PCN authors are willing to update > the current > > version of the LC-PCN draft according to the below updated > algorithm > > and to submit it to the IETF before the deadline of > > 25 February! > > > > > > New description > > ------------- > > > > Please note that the below description does not describe > how the use > > of the probing functionality during admission control and > the use of > > affected marking for ECMP solution during flow termination > should be > > performed. These two features can be added as optional, later on. > > > > > > * U is specified as in the SM draft! > > * N is specified as in the LC-PCN draft > > > > * Features in the PCN_interior_node: > > ------------------------ > > The excess rate measurement is done in a similar way as is done for > > SM, but the measurement should be done before drop but PCN_marking > > should be done after drop. > > This means that marked packets are preferentially not dropped. > > > > Furthermore the constant N should be used such that the > marked excess > > rate can represent also high level of excess rate. The calculated > > excess rate should be divided by N (when N>=1) > > > > This can be implemented in SM by marking every N-th packet > (or rather > > byte) instead of marking each packet (or byte) > > > > > > * Features in the PCN_egress_node > > ------------------------ > > > > **** Admission control: > > -------------------- > > > > The admission decision is similar to SM, based on the CLE, by > > measuring the rate of the received PCN_marked packets and by > > multiplying it by N. > > When CLE higher > > than a > > predefined/preconfigured threshold, e.g., 1% then in > admission state. > > See Section 2.4.1 in: > > http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma > rking-03.txt > > > > Note that the CLE is calculated as given in Section 11.3. > > Appendix, in: > > http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-arch > itecture-04.tx > > t > > > > > > > > The PCN_egress_node informs the PCN_ingress node that the > requesting > > flow is admitted or rejected (if in admission control state). > > Note that the above feature is not an SM feature. > > > > ***** Flow Termination: > > ------------- > > > > In order to detect the trigger for flow termination, we use the > > solution proposed in Section 2.4.2 in the SM draft: > > http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma > rking-03.txt > > > > The PCN_egress guard/activates the flow termination control > > with a trigger > > computed from the ratio of measured marked and unmarked > > traffic rates. Note > > that > > before using the above ratio to calculate the trigger, the > > rate of the > > marked traffic, is multiplied by N. > > > > Note that: > > > > If (U * admission control threshold) at the PCN_interior > > nodes is configured > > to be lower > > than the packet dropping threshold at the PCN_interior > node, then the > > PCN_egress_node > > can e.g., calculate the flow termination trigger in the > following way: > > > > If (marked_rate/unmarked_rate) >= (U - 1) > > THEN the flow termination trigger should be activated. > > > > > > If (U * admission control threshold) at the PCN_interior > > nodes is configured > > to be equal or higher > > than the packet dropping threshold at the PCN_interior > node, then the > > PCN_egress_node > > can e.g., calculate the flow termination trigger in the > following way: > > > > If (marked_rate/(unmarked_rate + marked_rate)) >= (U - 1) > > THEN the flow termination trigger should be activated. > > > > When this trigger is detected then the egress has to store > > the value of the > > absolute rate of the marked_rate traffic, say: > > PCN_upper_rate_egress > > > > The excess rate that is above this threshold, say > > incoming_PCN_marking_rate > > is used to calculate the number of flows to be terminated, say: > > terminated_bandwidth. > > The calculation of terminated_bandwidth is done in a similar way as > > described in Section 4.2.3 in current version of > > the LC-PCN draft. > > > > > > For the flows that should be terminated the PCN_egress_node informs > > the PCN_ingress_node to terminate them. > > > > * Features in the PCN_ingress_node > > ------------------------------------ > > > > ****** Admission control: > > ----------------- > > Admits or rejects the flow depending on the sent report by > the egress. > > This feature is not a SM feature > > > > > > ****** Flow termination: > > -------------------- > > The flows that are termination notified by the PCN_egress > > node have to be > > terminated by PCN_ingress node. In addition the PCN_ingress > > node informs > > the associated flow sender about the problem. > > This feature is not a SM feature. > > > > > > ------------------------------------------------------------ > > > > Important: Note that if probing and affected marking options > > are used then: > > > > * Probing should be accomplished in the same way as described > > currently in > > the LC-PCN draft. > > > > * Affected Marking is used at the PCN_interior nodes in the > > same way as is > > currently described in LC-PCN. > > At the egress, Affected Marked packets are used to select the > > flows that have to be terminated, and to calculate the flow > > termination > > trigger, instead of using the PCN unmarked packets. > > > > > > > > > > Best regards, > > Georgios > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 15 09:39:52 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B69F3A6B28; Fri, 15 Feb 2008 09:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-1.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 xeUezZoh31KL; Fri, 15 Feb 2008 09:39:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33193A6874; Fri, 15 Feb 2008 09:39:50 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BAE3A67F3 for ; Fri, 15 Feb 2008 09:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNQmmuUYmq5o for ; Fri, 15 Feb 2008 09:39:48 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id BFF3628D30A for ; Fri, 15 Feb 2008 09:39:03 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 17:40:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 17:40:22 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34596@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Creating 3SM system behaviour with CL marking behaviour Thread-Index: Acg7PNAIuRw7pMFuSwGA6R7UgpFcVgHFq/AAC2PMlpA= From: To: X-OriginalArrivalTime: 15 Feb 2008 17:40:22.0803 (UTC) FILETIME=[D732CE30:01C86FF9] Subject: [PCN] Creating 3SM system behaviour with CL marking behaviour 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org At Vancouver, some of us agreed to make the working assumption of "CL marking behaviour" & see if we could create (approximate) "3SM system behaviour" by doing something different at the PCN-boundary-nodes. In particular this concerns flow termination (for admission, the 3SM & CL marking algorithms are essentially the same). The good news is that I think this is very possible. Hoping so & I haven't mucked up! See http://www.watersprings.org/pub/id/draft-charny-pcn-comparison-00.txt for a description of CL & 3SM The problem: In 3SM, receipt of a termination marked pkt by a PCN-egress-node means "terminate this flow". With the CL marking algo, PCN-interior-nodes termination mark all pkts in excess of the PCN-upper-rate. So combining CL marking with 3SM boundary node behaviour would lead to too many flows being terminated - because there's a time delay between a pre-congested router termination marking and the flow actually being terminated. 3SM solves this problem by the PCN-interior-nodes "slowing down" their marking. The idea: When the boundary node sees a termination marked pkt, then it terminates the flow with some probability. So this is doing "slow down" at the edge (instead of at the interior router). I studied the following scenario: (intended to be identical to that http://www.watersprings.org/pub/id/draft-babiarz-pcn-3sm-01.txt) PCN-upper-rate = 800kb/s Initial excess rate = 800kb/s 1 flow = 80kb/s = pkt every 20msec RTT = 50ms = delay between marking & flow termination As an approximate model of what would really happen, I divide time into 50ms granularity (ie I assume the rate of marked pkts is constant for 50ms, then changes according to the number of terminated flows, then is constant for another 50ms, then changes etc. So the rate of termination slows down, in steps) So in a 50ms period, we have a binomial distribution (n, p) = (number of experiments, probability of success): n = number of pkts marked by pre-congested node in 50ms period p = probability of terminating a marked flow. A smaller p means that it takes longer to get rid of all the excess flows, but a lower risk of significant over-termination. p = 0.19 (I think this is equivalent to draft-babiarz-pcn-3sm, which uses a "slowdown" parameter of 1064/200 (= 1/0.19)) The mean number of terminated flows is np, in a 50ms period. We also get a probability for marking too few or far too many flows. We have to decide what is "far too many"; eg in the example above with 10flows in excess, we might decide that terminated 14flows is unacceptable. So we can look in the CDF of the binomial to find out what the chance is of terminating 14 or more flows in this period. For the next 50ms period, then re-do the binomial distribution, with a mean of np less than before - and repeat. Result: Running this model (in Excel) gives: After 5 iterations (=300msec, 50ms added because of RTT), there'll be fewer than 1 flow in excess. Prob (terminating 14flows) = 0 Even Prob (terminating 12flows) is only about 1% With p = 0.097, termination completes in about 550ms (cf draft-babiarz slowdown of 2064/200) With Prob (terminating 12flows) 0.001% These results are the same as in the 3SM draft /slides of those simulations. Of course p can be set too big, eg doubling p to 0.38 gives Prob (terminating 12flows) 10% (Incidentally, a few goes suggests the over-termination mainly occurs near the end, ie in the last one or two 50ms periods that any termination is done) Approximations: When deciding what n to use for the 2nd period of 50ms (n= number of marked pkts), it's an approximation to subtract the mean (np) for the previous period. Really should use a distribution for how much was terminated in the previous 50ms. But it's intuitively a reasonable thing to do - if fewer flows get terminated than expected in the first period, then chances are more will get terminated in the 2nd period, so the inaccuracy will tend to disappear. We (Ben) have built a little matlab program, which doesn't do this approx, because it uses fluid model equations. It (limited test) gives similar answers - out of time today to type more. The sources are basically CBR. I don't think this makes much odds - think a fluid approx is quite good. eg if the VBR sources in one 50ms period are quieter, there'll be fewer marked pkts, hence less termination, but they'll probably be more active in the next 50ms period. You'd expect a greater chance of over-termination (imagine you've really terminated enough, but the VBR source happen to transmit more than usual, then you'll still get excess traffic & the chance of some termination). However, I don't think the issues are any different for 3SM edge behaviour & the edge behaviour described here. I've ignored 'double termination'. Ie you could get a marked pkt & probabilistically decide the flow should be terminated (as per above), but actually you've already terminated this flow. I'm not sure what you'd do in reality, but effectively I've assumed you terminate another flow. Could model this by reducing the granularity period from 50ms (say to 10ms) but still keeping the RTT to 50ms (time to terminate after router marks). More work: So basically I think this idea looks good. It would be nice to check it in the 3SM simulations - Michael, I remember you said in Vancouver that you'd be trying to simulate it, did you get a chance? Eg test with different traffic sources. Why might you want 3SM behaviour: CL edge behaviour measures the rate of marked pkts in the ingress-egress-aggregate (so as to help decide how much to terminate). If the topology is such that the pkts through the pre-congested node belong to many ingress-egress-aggregates, then it may take a long time to measure the rate with any accuracy; and even then, if there are only a few flows (eg 1) on the aggregate, then a probabilistic decision still has to be made whether to terminate the flow. On the other hand, if the pre-congested node is traversed by not so many ingress-egress-aggregates, then there are enough pkts for the egress to measure rate in a short time period. Alternatively, the edge could run the probabilistic behaviour above. Or just count until it has seen x marked pkts. Note that the above behaviour is very dependent on the RTT (time to terminate after router marks). Eg with RTT = 500ms, you have to make p much smaller. making p factor of 10 less again gives all termination in about 5 RTTs. The probability of termination too many flows is also similar (eg Prob (terminating 12flows) = 1% or so) phil > -----Original Message----- > From: Eardley,PL,Philip,CXR9 R > Sent: 19 December 2007 15:33 > To: pcn@ietf.org > Cc: Eardley,PL,Philip,CXR9 R; 'Jozef Babiarz'; 'Anna Charny (acharny)'; > 'Kwok-Ho Chan'; 'Michael Menth'; Briscoe,RJ,Bob,CXR9 R; > Moncaster,T,Toby,CXR9 R; 'Tom Taylor'; 'Tina TSOU' > Subject: RE: PCN dinner consensus > > PCN-ers, > Several of us [cc'd] met over a couple of "corridor" meetings. We've > agreed a way forward until Philadelphia in terms of where we're going to > concentrate our particular efforts, in order to increase the chances of > success on the Milestone '(Pre-)Congestion Detection within a DiffServ > Domain' due March 2008. > > Over the next few months, we will make the working assumption of the "CL > marking behaviour" and explain/test this assumption (eg with further > simulations): > * "CL marking" means threshold-marking (step) for admission control & > excess-rate-marking for flow termination. > * Single Marking - this is potentially a migration step to CL. Explain why > SM is not enough (when is it enough?) > * 3SM - we believe that the overall behaviour in the 3SM draft can be > approximated with the CL marking + different edge behaviour. Explain how > (and what is lost). We had a good session to understand the pros/cons of > 3SM in more detail, and what simuls might help on this. > * LC-PCN - we believe that Affected Marking could in principle be added to > CL (or indeed to SM). Assess whether the benefit is worth the cost (are > any simulations possible?) > > Results etc of course on list and perhaps as a Part B to > http://tools.ietf.org/wg/pcn/draft-charny-pcn-comparison-00.txt - in order > to help the decision what marking approach to standardise. > > Note, this is just an unofficial understanding between some of us, in an > effort to increase the chances of the WG making a decision around the next > IETF (when the Milestone is due), and of course doesn't stop other > proposals and work. Hopefully the above captures what we agree (cc'd > people, please correct mistakes!). > > Best wishes & have a nice Chistmas, > Phil > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Feb 16 05:45:54 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4741E28C1A1; Sat, 16 Feb 2008 05:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 UglKdPxChPTL; Sat, 16 Feb 2008 05:45:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897C73A6A2B; Sat, 16 Feb 2008 05:45:53 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4453B3A6A2B for ; Sat, 16 Feb 2008 05:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVHzt+lyYcih for ; Sat, 16 Feb 2008 05:45:51 -0800 (PST) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by core3.amsl.com (Postfix) with SMTP id 482103A6A26 for ; Sat, 16 Feb 2008 05:45:51 -0800 (PST) Received: (qmail 50856 invoked from network); 16 Feb 2008 13:45:49 -0000 Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 16 Feb 2008 13:45:49 -0000 X-YMail-OSG: fsupaz8VM1lCCT0649aAwfdXhuFy_gWJw_8__OVAZE9Q7C5BRWMWeup20nP4wmoHSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47B6E90B.9040001@rogers.com> Date: Sat, 16 Feb 2008 08:45:47 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn , "Sun, Dong (Dong)" , Schwarz Albrecht , Osamu Kamatani Subject: [PCN] [Fwd: New Version Notification for draft-tsou-pcn-racf-applic-00] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org FYI -------- Original Message -------- Subject: New Version Notification for draft-tsou-pcn-racf-applic-00 Date: Fri, 15 Feb 2008 19:34:44 -0800 (PST) From: IETF I-D Submission Tool To: tom.taylor@rogers.com CC: tena@huawei.com A new version of I-D, draft-tsou-pcn-racf-applic-00.txt has been successfuly submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-pcn-racf-applic Revision: 00 Title: Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network Creation_date: 2008-02-15 WG ID: Independent Submission Number_of_pages: 18 Abstract: This document is written to help coordinate work on pre-congestion notification (PCN) between the IETF PCN Working Group and the ITU-T. It maps the use of PCN into the ITU-T transport control architecture. It examines three scenarios, showing in each, where new requirements are placed on the ITU-T architecture. In each case, the ITU-T functional entity known as the Transport Resource Control Functional Entity (TRC-FE) is seen as the logical destination for PCN congestion reports and PCN flow termination reports, which it uses to keep track of network status. As logical entities, instances of the TRC-FE can be present in the ingress nodes, in one or more centralized devices, or in both. These alternatives define the scenarios examined. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 18 07:37:55 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98FB28C331; Mon, 18 Feb 2008 07:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.866 X-Spam-Level: X-Spam-Status: No, score=0.866 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 LyBDT4y4HJfF; Mon, 18 Feb 2008 07:37:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AE63A6D63; Mon, 18 Feb 2008 07:37:40 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C489F3A6BBD for ; Mon, 18 Feb 2008 07:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aadea5nhG6h4 for ; Mon, 18 Feb 2008 07:37:36 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 5815628C447 for ; Mon, 18 Feb 2008 07:34:39 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E33B6A0651; Mon, 18 Feb 2008 16:34:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D59EEA064A; Mon, 18 Feb 2008 16:34:36 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 6ED6BA0630; Mon, 18 Feb 2008 16:34:34 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1IFYYV03517; Mon, 18 Feb 2008 16:34:34 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 4642BC7F16; Mon, 18 Feb 2008 16:34:34 +0100 (CET) Message-ID: <47B9A54A.9030101@informatik.uni-wuerzburg.de> Date: Mon, 18 Feb 2008 16:33:30 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Georgios Karagiannis References: <002301c86fc0$ba979780$810c5982@dynamic.ewi.utwente.nl> <003f01c86fe1$c065c940$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <003f01c86fe1$c065c940$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] (new) possibilities of combining LC-PCN and SM (in at leastPCN-interior nodes) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: > Hi Anna > > I have not studied points 1) to 5) in detail, so I may be wrong > in my following answers. > > I think that I can agree with points 1) to 4). Regarding point 5) I do think > that > the admission and termination decissions and calculations of the excess rate > > is different than the ones specified in 3SM. > > The main differeces between LC-PCN and CL/SM are: > > * LC_PCN measures the excess rate that is used to provide admission control > and flow termination decissions. > CL and SM measure the troughput to calculate the number of flows that can be > terminated. > > * In LC_PCN the admission control and flow termination decissions are done > by the PCN_egress! > In CL and SM the admission control and flow termination decissions are > done by the > PCN_egress and PCN_ingress! > > The benefit of taking the decissions by the PCN_egress instead of the > PCN_ingress is that > measurements and decissions can be done in one place/location. Thus one > entity, that in this case is the PCN_egress > can take all the required decissions. In the situations of CL and SM both > the PCN_egress and PCN_ingress are needed > to provide the same decissions. > > Is that what we called direct and indirect measured rate termination in Section 5 of our performance draft? http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-01.txt Further details see Section 4 of http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth07-PCN-Eval.pdf Regards, Michael > * LC-PCN describes in detail how probing and Affected marking features can > be used. > > Regarding, the main differences between LC_PCN and 3SM, in order to be able > to do that > I will have to study the last version of 3SM in more detail. > However, the differences are related to the way of how the excess rate is > used to provide admission control > and to selectthe number of flows that can be terminated. > > Regarding simulations, we have some old simulations that do not take into > account all > PCN related requirements and asuumptions. > We need tyo redo these simulations! > It will be great if we could discuss all the simulation related issues in > Philadelphia! > > Please note that I will be able to come to the 71st IETF in Philadelphia! > > > We will try to update the draft in time and submit it before the 25th of > February! > > Bst regards, > Georgios > > > > > > > > > >> -----Original Message----- >> From: Anna Charny (acharny) [mailto:acharny@cisco.com] >> Sent: vrijdag 15 februari 2008 15:20 >> To: Georgios Karagiannis; pcn@ietf.org >> Subject: RE: [PCN] (new) possibilities of combining LC-PCN >> and SM (in at leastPCN-interior nodes) >> >> Georgios, >> >> This seems to be a blend of SM and 3 SM functionality - >> right? Would it be correct to summarize this proposal as follows: >> >> 1) excess rate marking with a slowdown (as in 3sm) >> 2) single marking thresholds and single marking codepoint as in SM >> 3) preference to drop unmarked rather than marked packets (SM >> prefers preferential drop of marked packets) >> 4) use of marked traffic rate (times the slowdown factor) vs >> unmarked traffic rate at the egress to compute the amount of >> traffic to be dropped (equivalent to what SM does when no >> loss, not equivalent in the presence of loss); the trigger >> is as in SM. >> 5) termintation and admission decisions done at the egress, >> and signaling tells the ingress specific fows to terminate >> (or to stop/start admitting). This seems to be as in 3SM. >> >> Did I miss any other differences? >> >> What do you see as the benefits of this proposal compared to >> CL, SM and 3SM? >> >> Have any performance studies been done? >> >> Thank you, >> Anna >> >> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>> >> Behalf Of >> >>> Georgios Karagiannis >>> Sent: Friday, February 15, 2008 5:51 AM >>> To: pcn@ietf.org >>> Subject: [PCN] (new) possibilities of combining LC-PCN and >>> >> SM (in at >> >>> leastPCN-interior nodes) >>> >>> Dear all >>> >>> I have tried here, to write an updated version of the LC-PCN >>> algorithm, which can bring the SM (Single marking) and LC-PCN (Load >>> Control -PCN) solutions closer to each other! >>> >>> Please note that the LC-PCN authors are willing to update >>> >> the current >> >>> version of the LC-PCN draft according to the below updated >>> >> algorithm >> >>> and to submit it to the IETF before the deadline of >>> 25 February! >>> >>> >>> New description >>> ------------- >>> >>> Please note that the below description does not describe >>> >> how the use >> >>> of the probing functionality during admission control and >>> >> the use of >> >>> affected marking for ECMP solution during flow termination >>> >> should be >> >>> performed. These two features can be added as optional, later on. >>> >>> >>> * U is specified as in the SM draft! >>> * N is specified as in the LC-PCN draft >>> >>> * Features in the PCN_interior_node: >>> ------------------------ >>> The excess rate measurement is done in a similar way as is done for >>> SM, but the measurement should be done before drop but PCN_marking >>> should be done after drop. >>> This means that marked packets are preferentially not dropped. >>> >>> Furthermore the constant N should be used such that the >>> >> marked excess >> >>> rate can represent also high level of excess rate. The calculated >>> excess rate should be divided by N (when N>=1) >>> >>> This can be implemented in SM by marking every N-th packet >>> >> (or rather >> >>> byte) instead of marking each packet (or byte) >>> >>> >>> * Features in the PCN_egress_node >>> ------------------------ >>> >>> **** Admission control: >>> -------------------- >>> >>> The admission decision is similar to SM, based on the CLE, by >>> measuring the rate of the received PCN_marked packets and by >>> multiplying it by N. >>> When CLE higher >>> than a >>> predefined/preconfigured threshold, e.g., 1% then in >>> >> admission state. >> >>> See Section 2.4.1 in: >>> http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma >>> >> rking-03.txt >> >>> Note that the CLE is calculated as given in Section 11.3. >>> Appendix, in: >>> http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-arch >>> >> itecture-04.tx >> >>> t >>> >>> >>> >>> The PCN_egress_node informs the PCN_ingress node that the >>> >> requesting >> >>> flow is admitted or rejected (if in admission control state). >>> Note that the above feature is not an SM feature. >>> >>> ***** Flow Termination: >>> ------------- >>> >>> In order to detect the trigger for flow termination, we use the >>> solution proposed in Section 2.4.2 in the SM draft: >>> http://www.ietf.org/internet-drafts/draft-charny-pcn-single-ma >>> >> rking-03.txt >> >>> The PCN_egress guard/activates the flow termination control >>> with a trigger >>> computed from the ratio of measured marked and unmarked >>> traffic rates. Note >>> that >>> before using the above ratio to calculate the trigger, the >>> rate of the >>> marked traffic, is multiplied by N. >>> >>> Note that: >>> >>> If (U * admission control threshold) at the PCN_interior >>> nodes is configured >>> to be lower >>> than the packet dropping threshold at the PCN_interior >>> >> node, then the >> >>> PCN_egress_node >>> can e.g., calculate the flow termination trigger in the >>> >> following way: >> >>> If (marked_rate/unmarked_rate) >= (U - 1) >>> THEN the flow termination trigger should be activated. >>> >>> >>> If (U * admission control threshold) at the PCN_interior >>> nodes is configured >>> to be equal or higher >>> than the packet dropping threshold at the PCN_interior >>> >> node, then the >> >>> PCN_egress_node >>> can e.g., calculate the flow termination trigger in the >>> >> following way: >> >>> If (marked_rate/(unmarked_rate + marked_rate)) >= (U - 1) >>> THEN the flow termination trigger should be activated. >>> >>> When this trigger is detected then the egress has to store >>> the value of the >>> absolute rate of the marked_rate traffic, say: >>> PCN_upper_rate_egress >>> >>> The excess rate that is above this threshold, say >>> incoming_PCN_marking_rate >>> is used to calculate the number of flows to be terminated, say: >>> terminated_bandwidth. >>> The calculation of terminated_bandwidth is done in a similar way as >>> described in Section 4.2.3 in current version of >>> the LC-PCN draft. >>> >>> >>> For the flows that should be terminated the PCN_egress_node informs >>> the PCN_ingress_node to terminate them. >>> >>> * Features in the PCN_ingress_node >>> ------------------------------------ >>> >>> ****** Admission control: >>> ----------------- >>> Admits or rejects the flow depending on the sent report by >>> >> the egress. >> >>> This feature is not a SM feature >>> >>> >>> ****** Flow termination: >>> -------------------- >>> The flows that are termination notified by the PCN_egress >>> node have to be >>> terminated by PCN_ingress node. In addition the PCN_ingress >>> node informs >>> the associated flow sender about the problem. >>> This feature is not a SM feature. >>> >>> >>> ------------------------------------------------------------ >>> >>> Important: Note that if probing and affected marking options >>> are used then: >>> >>> * Probing should be accomplished in the same way as described >>> currently in >>> the LC-PCN draft. >>> >>> * Affected Marking is used at the PCN_interior nodes in the >>> same way as is >>> currently described in LC-PCN. >>> At the egress, Affected Marked packets are used to select the >>> flows that have to be terminated, and to calculate the flow >>> termination >>> trigger, instead of using the PCN unmarked packets. >>> >>> >>> >>> >>> Best regards, >>> Georgios >>> >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> http://www.ietf.org/mailman/listinfo/pcn >>> >>> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 18 16:12:00 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDE53A6938; Mon, 18 Feb 2008 16:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=-3.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 lduEpGdN6vlh; Mon, 18 Feb 2008 16:11:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8953A697F; Mon, 18 Feb 2008 16:11:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A813A6966 for ; Mon, 18 Feb 2008 16:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICg-4ETQSGRf for ; Mon, 18 Feb 2008 16:11:57 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BD5A23A6883 for ; Mon, 18 Feb 2008 16:11:56 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m1J07iH05205; Tue, 19 Feb 2008 00:07:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 19:11:48 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465148B198B@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34550@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgW7SC2PEVcOi1+Qg+vZ1UxgSPGoQDfIixAAVzgg4AEZKGNsA4LBo1QAjv+4YA= References: <9671A92C3C8B5744BC97F855F7CB6465135B3428@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34550@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [PCN] Architecture draft - probing section & general updates. 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Thanks Phil, I will be review 03 version. Would like get it to WG last call soon. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: February 7, 2008 10:13 AM To: Babiarz, Jozef (CAR:0S03); lars.eggert@nokia.com Cc: pcn@ietf.org; Ruediger.Geib@t-systems.com Subject: RE: [PCN] Architecture draft - probing section & general updates. Joe Have added the following text (to Appendix - which is on stuff beyond current charter): not all the nodes run PCN. For example, the PCN-domain is a multi-site enterprise network. The sites are connected by a VPN tunnel; although PCN doesn't operate inside the tunnel, the PCN mechanisms still work properly because the of the good QoS on the virtual link (the tunnel). Another example is that PCN is deployed on the general Internet (ie widely but not universally deployed). Hoping this gets your scenario! phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 28 November 2007 04:29 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@nokia.com > Cc: pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: RE: [PCN] Architecture draft - probing section & general updates. > > Hi Phil, > PCN-domain is enterprise network that is within one building or campus. > Large enterprises have several locations that are distributed throughout > the city, counter or even the world. Between different locations, Layer > 2 or Layer 3 VPNs are used to interconnect usually using multiple VPNs > to each location to provide resilience should one VPN fail for a period > of time. Different approaches (ECMP, policy routing, etc) are used to > distribute traffic on two or more VPNs between each location. Each or > most of the enterprise locations are PCN-capable and the VPNs (tunnels) > are used to interconnect the different locations. The ISPs that provide > the tunnels are not PCN-capable. PCN function needs only to be supported > within the global enterprise network. Edge nodes that provide admission > control and flow termination need to support PCN-edge-node function. > Enterprise core nodes and WAN nodes need to provide PCN-interior-node > function. > > Terminally: > In enterprise networks WAN (Wide Area Network) edge node is the node > that provides connects to a foreign network and where normally Layer 2 > or 3 VPN start and end. There may be other tunnels running inside the > enterprise network but that is outside the scope of this example. > Edge node is a switch or router where end terminals, hosts, servers > connect to. > > Those the above help? > > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: November 5, 2007 1:57 PM > To: Babiarz, Jozef (CAR:0S03); lars.eggert@nokia.com > Cc: pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: RE: [PCN] Architecture draft - probing section & general > updates. > > Joe - trying to clarify... what's the PCN-domain? Does it run from one > *enterprise* LAN edge switch/router to another (there's a tunnelled link > between them), or from the end terminals. Ie what are the > pcn-boundary-nodes {&pcn-interior-nodes)? > > The scenario isnt captured I think in the draft-ietf-pcn-architecture, > so something should probably be added... > > Thanks > Phil. > > > -----Original Message----- > > From: Jozef Babiarz [mailto:babiarz@nortel.com] > > Sent: 29 October 2007 21:06 > > To: Lars Eggert > > Cc: pcn@ietf.org; Geib, Ruediger > > Subject: RE: [PCN] Architecture draft - probing section & general > updates. > > > > Hi Lars, > > I did not explain my scenario that clearly, I confused people the word > > "access node". So here goes a second try. > > > > I'm thinking of a scenario that many enterprises face today. Large > multi > > location enterprises use multiple WAN links or VPS to interconnect > their > > locations (branch offices). PCN is run inside the enterprise network > > including WAN links which may be tunneled across the carrier network. > > Carrier network is not required to support PCN as the enterprise > traffic > > including PCN marking is tunneled, however it could. Network Access > > Control with PCN admission control is done at the *enterprise* LAN > edge > > switch/router. New flows can be routed to any egress LAN edge > > switch/router and some flows will (between different locations) be > > routed over one of the WAN links which are normally bandwidth > > constrained. There is a high probability that many of the edge LAN > > switches/routers will have no flows setup between each other (no > > ingress-egress aggregate) as there are a large number of edge LAN > > switches/routers in the enterprise network and people calling patterns > > change. They normal expect that they should be able to call anyone. > > > > > > Regards, Joe > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: October 25, 2007 5:54 AM > > To: Babiarz, Jozef (CAR:0S03) > > Cc: Geib, Ruediger; pcn@ietf.org > > Subject: Re: [PCN] Architecture draft - probing section & general > > updates. > > > > On 2007-10-24, at 19:14, ext Jozef Babiarz wrote: > > > I'm thinking of a scenario that many enterprises face today. Large > > > multi > > > location enterprises use multiple WAN links or VPS to interconnect > > > their > > > locations. PCN is run inside the enterprise network including WAN > > > links > > > which maybe tunneled across the carrier network. Network Access > > > Control > > > with PCN admission control is done at the enterprise access edge > > > nodes. > > > New flows can be routed to any egress access edge node and some > flows > > > will (between different locations) be routed over one of the WAN > links > > > which are normally bandwidth constrained. > > > > I understand your scenario so far. > > > > > There is a high probability > > > that many access nodes will only have one flow between each other as > > > there are a large number of them. > > > > I don't see how this follows, however. It seems that if the sites > > that are being interconnected aren't tiny, there should very likely > > be multiple flows per ingress/egress pair, no? > > > > Lars > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 19 01:01:28 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D22F28C44E; Tue, 19 Feb 2008 01:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, 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 F6sbd1m1nYN3; Tue, 19 Feb 2008 01:01:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE6428C45C; Tue, 19 Feb 2008 01:01:25 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6815528C45C for ; Tue, 19 Feb 2008 01:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDBZb2s4ke1a for ; Tue, 19 Feb 2008 01:01:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 43C5C28C3E1 for ; Tue, 19 Feb 2008 01:01:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26FE0215FE for ; Tue, 19 Feb 2008 09:59:47 +0100 (CET) X-AuditID: c1b4fb3e-a81fabb000000b15-4a-47ba9a831970 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D95C2160B for ; Tue, 19 Feb 2008 09:59:47 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 09:58:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 09:58:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Usecases and Benefits of end to end ECN support in PCN Domains thread-index: Achy1Yy3aJ58RP0KRvS0XD9H7Te35Q== From: "Sarker Zaheduzzaman" To: X-OriginalArrivalTime: 19 Feb 2008 08:58:09.0490 (UTC) FILETIME=[8CBDAB20:01C872D5] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains 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: , Content-Type: multipart/mixed; boundary="===============0188789860==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0188789860== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C872D5.8CB58354" This is a multi-part message in MIME format. ------_=_NextPart_001_01C872D5.8CB58354 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, A new draft has been submitted to the PCN WG, comments are very welcome. = Originally this was supposed to be a teamwork with Bob Briscoe but due = to an unfortunate event he could not be a part of this draft this time. = we welcome his contribution as well as the contributions from other = interested people in future versions of this draft. Title: Usecases and Benefits of end to end ECN support in PCN Domains=20 Abstract : This document provides an informative overview of possible use cases = where ECN marking can be used for inelastic traffic. It outlines = benefits of preserving the ECN support in a PCN domain. As ECN provides = with a simple mechanism for network nodes to inform the end points about = possible upcoming congestion and resulting packet losses and delay = increase, the scheme can be useful for adaptive real-time media = applications, thus enabling them to adjust the transmission rate to = avoid quality degradation due to congestion. By showing the benefits of = ECN this memo asks the working group to consider end to end ECN support = in PCN domain.=20 Link: http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt Regards Zaheduzzaman Sarker -------------------------------------------------------------------------= ---------------- ANM Zaheduzzaman Sarker Research Engineer EAB/TVP -Multimedia Technologies Ericsson Research Ericsson AB S-971 28 Lule=E5, Sweden Tel: +46 (0)8 7573743 ECN: 850-73743 Mobile: +46 (0)76 1153743=20 www.ericsson.com ------_=_NextPart_001_01C872D5.8CB58354 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Usecases and Benefits of end to end ECN support in PCN = Domains

Hi,

A new draft has been submitted to = the PCN WG, comments are very welcome. Originally this was supposed to = be a teamwork with Bob Briscoe but due to an unfortunate event he could = not be a part of this draft this time. we welcome his contribution as = well as the contributions from other interested people in future = versions of this draft.

Title:
 Usecases and Benefits of = end to end ECN support in PCN Domains

Abstract :
 This document provides an = informative overview of possible use cases where ECN marking can be used = for inelastic traffic. It outlines benefits of preserving the ECN = support in a PCN domain. As ECN provides with a simple mechanism for = network nodes to inform the end points about possible upcoming = congestion and resulting packet losses and delay increase, the scheme = can be useful for adaptive real-time media applications, thus enabling = them to adjust the transmission rate to avoid quality degradation due to = congestion. By showing the benefits of ECN this memo asks the working = group to consider end to end ECN support in PCN domain.

Link:
 http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.tx= t

Regards
Zaheduzzaman Sarker

----------------------------------------------------------= -------------------------------
ANM Zaheduzzaman Sarker
Research Engineer
EAB/TVP -Multimedia Technologies
Ericsson Research
Ericsson AB
S-971 28 Lule=E5, Sweden
Tel: +46 (0)8 7573743
ECN: 850-73743
Mobile: +46 (0)76 1153743
www.ericsson.com


------_=_NextPart_001_01C872D5.8CB58354-- --===============0188789860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --===============0188789860==-- From pcn-bounces@ietf.org Wed Feb 20 01:56:20 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD0828C0FC; Wed, 20 Feb 2008 01:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 8UOWlm1Eeqwr; Wed, 20 Feb 2008 01:56:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFC128C0FF; Wed, 20 Feb 2008 01:56:19 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CFB28C0FC for ; Wed, 20 Feb 2008 01:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMaJfao1MMgO for ; Wed, 20 Feb 2008 01:56:15 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CF34328C0FF for ; Wed, 20 Feb 2008 01:56:13 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 09:56:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 09:56:21 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: PCN encoding option thread-index: AchzC61qfqGF9P19QiedvNvN2RlCdQABSCswACVwfrA= From: To: X-OriginalArrivalTime: 20 Feb 2008 09:56:08.0979 (UTC) FILETIME=[D1174E30:01C873A6] Cc: bob.briscoe@bt.com Subject: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org All, Phil and I have just been discussing the encoding draft and feel we may have lit upon a neat solution that seems to have lots of pros and few cons... In order to get a better feeling for this proposal I will go through the simplified version without Affected marking first: PCN Meaning ECN DSCP PCN capable 00 PCN 1 Admission Mark 11 PCN 1 Termination Mark 11/00 PCN 2 PCN 1 and PCN 2 are 2 different codepoints with the same PCN behaviour aggregate. Pros: o Termination marking and admission marking are independent, eg termination marking can be done after a packet has been admission marked. Therefore a router can write AM or TM without having to read the packet's PCN marking first, which is easier to implement. (Note: Over-writing a TM with AM is not allowed for 3SM & CL, see draft-charny-pcn-comparison.) o This scheme avoids giving semantics to ECT(0) and ECT(1). This is safest option if packets leak outside the PCN region, due to some fort of misconfiguration of the PCN-boundary-nodes (relevant for a single domain deployment of PCN). o It leaves open the possibility of using ECT(0) and ECT(1) in some mysterious way in a future end-to-end PCN deployment o For a router to classify a packet as PCN, it simply reads its DSCP. This is probably easier than checking both its DSCP & ECN fields. o Incremental deployment steps are possible [1] could deploy SM initially and later AM/TM. Just add the second DSCP. If a router isn't upgraded at the same time nothing too horrific happens. [2] could just deploy admission control & add termination later, just by adding a new DSCP; there is no need to change the encoding and check for backwards compatibility? Vice-versa is also ok? Cons: o It needs an extra DSCP, per PCN behaviour aggregate. (Although possibly it's OK to use the same DSCP for TM for all PCN BAs?) o If a packet (in a PCN flow) arrives at the egress with its ECN = 11 and it really is required to preserve this info across the PCN-domain, then some complexity is needed at the PCN-boundary-nodes (tunnelling) o If the PCN-domain is operating multipath routing (ECMP) that uses the DSCP to select routes, then there may be mis-ordering of packets within a flow. This may be OK as (1) no-one has yet said they know of an ECMP algorithm that in practie uses the DSCP; (2) a risk of mis-ordering when there is termination marking may be acceptable If Affected marking is needed then the scheme can be modified as follows: PCN Meaning ECN DSCP PCN capable 00 PCN 1 Admission Mark 11 PCN 1 Termination Mark 11 PCN 2 Affected Mark 00 PCN 2 The pros for this scheme are broadly similar to the above. However there is a new con which may or may not matter: If a packet is affected marked and a later node is doing admission marking then it will reset the affected mark to a termination mark. Work would be needed to see if this skews the results and causes significant over-termination or not. Please could people look through this scheme and highlight any additional concerns that they may have (and extra benefits too). I would like to get as many opinions as possible. What I want to avoid is people just emailing back with "why not try this scheme instead". Currently we seem to have a plethora of possible schemes on the table and people need to start putting down much clearer pros and cons for the schemes they support... So it could be good to have a similar "one page" email about a specific scheme that only uses one DSCP for PCN, but uses the 01/10 codepoints instead. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 02:51:21 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5071D28C20A; Wed, 20 Feb 2008 02:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 S-bwJDHR+j49; Wed, 20 Feb 2008 02:51:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFB63A6CCD; Wed, 20 Feb 2008 02:51:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7FE3A6CCD for ; Wed, 20 Feb 2008 02:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFo3zPGwYFLK for ; Wed, 20 Feb 2008 02:51:18 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id DAFFE3A6965 for ; Wed, 20 Feb 2008 02:51:17 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DDEA1A067E; Wed, 20 Feb 2008 11:51:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CEC09A067B; Wed, 20 Feb 2008 11:51:11 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0254CA0680; Wed, 20 Feb 2008 11:51:02 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1KAp2V23295; Wed, 20 Feb 2008 11:51:02 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 87F0BC81C4; Wed, 20 Feb 2008 11:51:02 +0100 (CET) Message-ID: <47BC05DA.7090701@informatik.uni-wuerzburg.de> Date: Wed, 20 Feb 2008 11:50:02 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, as I understand the proposal, the motivation is to avoid 01/10 codepoints as it is not good if they leak out of the network since 01/10 is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, there is the same problem with 11 marking, i.e. 11-packets may not be dropped by ECN nodes outside the PCN domain although endpoints are not ECN capable. Even if 11-packets trigger flow termination, it is not guaranteed that exactly the marked flow going over an overloaded ECN node is terminated. Just want to say that this solution wants to solve a problem that exists only in case of misconfiguration (leaking packets), but does not fully achieve that objective. Therefore, I feel that spending two DSCP values is quite expensive. Regards, Michael toby.moncaster@bt.com wrote: > > All, > > Phil and I have just been discussing the encoding draft and feel we may > have lit upon a neat solution that seems to have lots of pros and few > cons... In order to get a better feeling for this proposal I will go > through the simplified version without Affected marking first: > > PCN Meaning ECN DSCP > > PCN capable 00 PCN 1 > Admission Mark 11 PCN 1 > Termination Mark 11/00 PCN 2 > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN behaviour > aggregate. > > Pros: > o Termination marking and admission marking are independent, eg > termination marking can be done after a packet has been admission > marked. Therefore a router can write AM or TM without having to read the > packet's PCN marking first, which is easier to implement. (Note: > Over-writing a TM with AM is not allowed for 3SM & CL, see > draft-charny-pcn-comparison.) > > o This scheme avoids giving semantics to ECT(0) and ECT(1). This is > safest option if packets leak outside the PCN region, due to some fort > of misconfiguration of the PCN-boundary-nodes (relevant for a single > domain deployment of PCN). > > o It leaves open the possibility of using ECT(0) and ECT(1) in some > mysterious way in a future end-to-end PCN deployment > > o For a router to classify a packet as PCN, it simply reads its DSCP. > This is probably easier than checking both its DSCP & ECN fields. > > o Incremental deployment steps are possible > [1] could deploy SM initially and later AM/TM. Just add the second DSCP. > If a router isn't upgraded at the same time nothing too horrific > happens. > [2] could just deploy admission control & add termination later, just by > adding a new DSCP; there is no need to change the encoding and check for > backwards compatibility? Vice-versa is also ok? > > Cons: > o It needs an extra DSCP, per PCN behaviour aggregate. (Although > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > o If a packet (in a PCN flow) arrives at the egress with its ECN = 11 > and it really is required to preserve this info across the PCN-domain, > then some complexity is needed at the PCN-boundary-nodes (tunnelling) > > o If the PCN-domain is operating multipath routing (ECMP) that uses the > DSCP to select routes, then there may be mis-ordering of packets within > a flow. This may be OK as (1) no-one has yet said they know of an ECMP > algorithm that in practie uses the DSCP; (2) a risk of mis-ordering when > there is termination marking may be acceptable > > If Affected marking is needed then the scheme can be modified as > follows: > > PCN Meaning ECN DSCP > > PCN capable 00 PCN 1 > Admission Mark 11 PCN 1 > Termination Mark 11 PCN 2 > Affected Mark 00 PCN 2 > > The pros for this scheme are broadly similar to the above. However there > is a new con which may or may not matter: If a packet is affected marked > and a later node is doing admission marking then it will reset the > affected mark to a termination mark. Work would be needed to see if this > skews the results and causes significant over-termination or not. > > Please could people look through this scheme and highlight any > additional concerns that they may have (and extra benefits too). I would > like to get as many opinions as possible. > > What I want to avoid is people just emailing back with "why not try this > scheme instead". Currently we seem to have a plethora of possible > schemes on the table and people need to start putting down much clearer > pros and cons for the schemes they support... So it could be good to > have a similar "one page" email about a specific scheme that only uses > one DSCP for PCN, but uses the 01/10 codepoints instead. > > Toby > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 03:06:27 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C335B28C3A4; Wed, 20 Feb 2008 03:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 GHoNYfeJSEBu; Wed, 20 Feb 2008 03:06:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F6228C1E5; Wed, 20 Feb 2008 03:06:26 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D9A28C117 for ; Wed, 20 Feb 2008 03:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4M7ANduGMb8 for ; Wed, 20 Feb 2008 03:06:24 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id E579228C1E5 for ; Wed, 20 Feb 2008 03:06:23 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id AC13CA0671; Wed, 20 Feb 2008 12:06:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9EA25A066C; Wed, 20 Feb 2008 12:06:20 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 376C7A0661; Wed, 20 Feb 2008 12:02:40 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1KB2eV23408; Wed, 20 Feb 2008 12:02:40 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 4DF86C83C6; Wed, 20 Feb 2008 12:02:39 +0100 (CET) Message-ID: <47BC0893.8080109@informatik.uni-wuerzburg.de> Date: Wed, 20 Feb 2008 12:01:39 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tom Taylor References: <47B6E90B.9040001@rogers.com> In-Reply-To: <47B6E90B.9040001@rogers.com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn , Osamu Kamatani , Schwarz Albrecht , "Sun, Dong \(Dong\)" Subject: Re: [PCN] [Fwd: New Version Notification for draft-tsou-pcn-racf-applic-00] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Tom, thanks for this input. I read this draft and find it interesting to see how PCN can be used in in other architectures. However, I had problems to fully follow the document as it contains many abbreviations that are not spelled out even a single time. A small glossary would be helpful and more introductory comprehensive text about the considered architecture. Regards, Michael Tom Taylor wrote: > FYI > > -------- Original Message -------- > Subject: New Version Notification for draft-tsou-pcn-racf-applic-00 > Date: Fri, 15 Feb 2008 19:34:44 -0800 (PST) > From: IETF I-D Submission Tool > To: tom.taylor@rogers.com > CC: tena@huawei.com > > > A new version of I-D, draft-tsou-pcn-racf-applic-00.txt has been successfuly > submitted by Tom Taylor and posted to the IETF repository. > > Filename: draft-tsou-pcn-racf-applic > Revision: 00 > Title: Applicability Statement for the Use of Pre-Congestion Notification in a > Resource-Controlled Network > Creation_date: 2008-02-15 > WG ID: Independent Submission > Number_of_pages: 18 > > Abstract: > This document is written to help coordinate work on pre-congestion > notification (PCN) between the IETF PCN Working Group and the ITU-T. > It maps the use of PCN into the ITU-T transport control architecture. > It examines three scenarios, showing in each, where new requirements > are placed on the ITU-T architecture. In each case, the ITU-T > functional entity known as the Transport Resource Control Functional > Entity (TRC-FE) is seen as the logical destination for PCN congestion > reports and PCN flow termination reports, which it uses to keep track > of network status. As logical entities, instances of the TRC-FE can > be present in the ingress nodes, in one or more centralized devices, > or in both. These alternatives define the scenarios examined. > > > > The IETF Secretariat. > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 05:57:40 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461B128C7EB; Wed, 20 Feb 2008 05:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 uFqE-mwutehZ; Wed, 20 Feb 2008 05:57:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFA23A6965; Wed, 20 Feb 2008 05:57:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537D328C807 for ; Wed, 20 Feb 2008 05:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ncjY5343Jzd for ; Wed, 20 Feb 2008 05:57:24 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 5D3B43A6A21 for ; Wed, 20 Feb 2008 05:56:41 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 28A9CA0662; Wed, 20 Feb 2008 14:56:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1BD9CA0608; Wed, 20 Feb 2008 14:56:38 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CFCAFA0604; Wed, 20 Feb 2008 14:56:36 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1KDuaV24932; Wed, 20 Feb 2008 14:56:36 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 61A98C81C4; Wed, 20 Feb 2008 14:56:36 +0100 (CET) Message-ID: <47BC3157.4070806@informatik.uni-wuerzburg.de> Date: Wed, 20 Feb 2008 14:55:35 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sarker Zaheduzzaman References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080405000402090809020808" X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains 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: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --------------080405000402090809020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Sarker, your ID is a pleading to keep ECN within a PCN domain. There are various options: 1. All traffic crossing a PCN domain keeps ECN capability (inlcuding PCN traffic). 2. Only non-PCN traffic keeps ECN marking. 3. No traffic keeps ECN marking (e.g. all packets have ECN bits set to 00 at the egress). Option 3 is possible if we use only ECN bits for PCN encoding without using DSCP (see my attached email I sent to this list a week ago). It's nice as it does not require DSCPs such that PCN can basically be applied to any DSCP, but the loss of ECN capability for all(!) traffic crossing the PCN domain would be the price we have to pay. Your draft says this price is high. Regards, Michael Sarker Zaheduzzaman wrote: > > Hi, > > A new draft has been submitted to the PCN WG, comments are very > welcome. Originally this was supposed to be a teamwork with Bob > Briscoe but due to an unfortunate event he could not be a part of this > draft this time. we welcome his contribution as well as the > contributions from other interested people in future versions of this > draft. > > Title: > Usecases and Benefits of end to end ECN support in PCN Domains > > Abstract : > This document provides an informative overview of possible use cases > where ECN marking can be used for inelastic traffic. It outlines > benefits of preserving the ECN support in a PCN domain. As ECN > provides with a simple mechanism for network nodes to inform the end > points about possible upcoming congestion and resulting packet losses > and delay increase, the scheme can be useful for adaptive real-time > media applications, thus enabling them to adjust the transmission rate > to avoid quality degradation due to congestion. By showing the > benefits of ECN this memo asks the working group to consider end to > end ECN support in PCN domain. > > Link: > _http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt_ > > Regards > Zaheduzzaman Sarker > > ----------------------------------------------------------------------------------------- > > ANM Zaheduzzaman Sarker > Research Engineer > EAB/TVP -Multimedia Technologies > Ericsson Research > Ericsson AB > S-971 28 Luleå, Sweden > Tel: +46 (0)8 7573743 > ECN: 850-73743 > Mobile: +46 (0)76 1153743 > _www.ericsson.com_ > > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://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 --------------080405000402090809020808 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Message-ID: <47B1C448.6020201@informatik.uni-wuerzburg.de> Date: Tue, 12 Feb 2008 17:07:36 +0100 From: Michael Menth Reply-To: menth@informatik.uni-wuerzburg.de Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn Subject: PCN encoding: keep the door open for end-to-end PCN? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I am not so happy yet with the current version of the encoding draft. I am worrying about extensibility of edge-to-edge PCN to end-to-end PCN. I do not want push work towards end-to-end PCN in the near future, but we should be aware that a wrong encoding might close the door for end-to-end PCN. We should only intentionally close the door or keep it open. I discuss two different marking schemes taking this issue into account. 1. Non-extensible solution for edge-to-edge PCN When we do not want to extend PCN towards an end-to-end solution, we can stick with edge-to-edge PCN islands. If we take the decision that these islands do not support ECN, we can simply reuse the ECN-bits for encoding. To take advantage of the marking functionality of legacy ECN equipment, "excess-traffic" (ET) should be mapped to ECN's CE (11) codepoint, and "no-pre-congestion" (NP) as well as "admission-stop" (AS) should be mapped to ECN's ECT(0) and ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left over to indicate non-PCN traffic. This scheme requires that traffic is remarked when entering a PCN domain. All 11-marked packets must be dropped. Afterwards, all non-PCN traffic is remarked to 00 and PCN traffic is remarked to e.g. 01. Upon leaving the PCN domain, all traffic is reset to 00. Bad: This scheme is applicable only in a closed island where ECN semantics are substituted by PCN semantics. It cannot be extended to an end-to-end solution since it is not possible to differentiate PCN from non-PCN traffic. ECN marks are lost for PCN and non-PCN traffic. Good: PCN encoding does not require a new DSCP and PCN can be applied to any DSCP allowing PCN support for various service classes (DSCPs). 2. Solution for end-to-end PCN treating edge-to-edge PCN as a special case This requires the definition of a new "PCN DSCP" indicating that endpoints (either host nodes or proxies) implement the semantics of PCN instead of ECN. PCN treatment is only applied to traffic with the PCN DSCP. However, ECN treatment is possibly applied to PCN traffic by legacy nodes. A core question is: what is the desired behavior in that case? Should CE-marking be different from ET-marking or not? a) ET=CE=11: legacy nodes throttle ECN flows and tear down PCN flows in case of overload; other mappings {NP, AS} -> {ECT(0), ECT(1)} b) CE not used for PCN encoding: CE-marking always results from overloaded ECN nodes. Therefore, endpoints should either drop such packets or hand them to TCP if it is ECN-capable. mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)} Edge-to-edge PCN is a special case of this encoding scheme when ingress and egress nodes of a PCN domain act as proxies for endpoints. This implies for PCN ingress nodes: drop all 11-marked PCN packets and then mark the other PCN packets with NP This implies for PCN egress nodes: case a) remark all 01, 10, 11-marked PCN packets to 00 Problem: 1. not-ECT flows with CE-marked packets by pure ECN nodes within the PCN domain do not back off 2. PCN traffic is terminated while non-PCN traffic continues to send in case of congestion when PCN domain contains pure ECN nodes -> PCN traffic is squeezed out case b) remark all 01, 10-marked PCN packets to 00; let 11-marked packets escape if all nodes of the PCN domain are PCN-enabled and drop them if the PCN domain has some nodes that are only ECN-enabled. Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage for non-PCN traffic. Bad: requires definition of new DSCP, cannot be used for different traffic classes; Simultaneous usage of PCN and ECN not possible If you think this kind of reflection is useful, I'd be happy to see it in the encoding draft. I am interested in your opinion about closing the door for end-to-end PCN or keeping it open. 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 --------------080405000402090809020808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --------------080405000402090809020808-- From pcn-bounces@ietf.org Wed Feb 20 08:44:30 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6347A28C7F1; Wed, 20 Feb 2008 08:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 jos4XONU-pNF; Wed, 20 Feb 2008 08:44:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2916328C1CD; Wed, 20 Feb 2008 08:44:29 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B4128C1CD for ; Wed, 20 Feb 2008 08:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMEL546843I8 for ; Wed, 20 Feb 2008 08:44:26 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 3CE6928C1BE for ; Wed, 20 Feb 2008 08:44:26 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:44:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 16:44:20 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47BC05DA.7090701@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCg From: To: , X-OriginalArrivalTime: 20 Feb 2008 16:44:22.0485 (UTC) FILETIME=[D85BB850:01C873DF] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Thanks Michael I agree with you that spending one DSCP value is quite expensive (not two, as one is spent anyway). I think the only way of really assessing this properly is for an alternative proposal (with pros and cons) that requires only one DSCP. Then we can see where the consensus for the best (/least bad) encoding lies. Personally I have no axe to grind for or against either - I'm not yet convinced that the proposal below is definitely the way to go, until compared it in detail with other proposals. So I think it would be really useful to have a "1 pager" for alternative proposal(s) before the ietf, as I think this would make Philadelphia discussions more productive. You're correct about one of the motivations (advantages) for this proposal (although I don't think the issues are exactly the same for 11 leakage as 01/10 leakage). Consider the case where 11 leaks out of the PCN domain. If the endpoints are ECN capable, then the ECN source slows down (seems reasonable). If they're not capable, then the impact outside the domain isn't any different to what would happen without PCN-domain. Consider the case where ECN-11 leaks into the PCN domain. Then this will lead to either flow admission or termination in the PCN-domain. These are both safe, in that the reaction is (I believe) at least as severe as would happen in an all ECN world. You mention that this might not terminate the ECN-11 flow specifically (some other flow might get terminated instead). I think this is true, though it also implies that [1] end-to-end ECN & PCN on the same flow really is useful, [2] the mechanism (eg tunnelling) to carry ECN-marking transparently across the PCN-domain has also failed, [3] the flows which are terminated aren't other ECN-11 flows that are also getting in due to the same misconfiguration. Best wishes Phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 20 February 2008 10:50 > To: Moncaster,T,Toby,CXR9 R > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > Subject: Re: FW: RE: PCN encoding option > > Hi Toby, > > as I understand the proposal, the motivation is to avoid 01/10 > codepoints as it is not good if they leak out of the network since 01/10 > is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, there is > the same problem with 11 marking, i.e. 11-packets may not be dropped by > ECN nodes outside the PCN domain although endpoints are not ECN capable. > Even if 11-packets trigger flow termination, it is not guaranteed that > exactly the marked flow going over an overloaded ECN node is terminated. > Just want to say that this solution wants to solve a problem that exists > only in case of misconfiguration (leaking packets), but does not fully > achieve that objective. Therefore, I feel that spending two DSCP values > is quite expensive. > > Regards, > > Michael > > toby.moncaster@bt.com wrote: > > > > All, > > > > Phil and I have just been discussing the encoding draft and feel we may > > have lit upon a neat solution that seems to have lots of pros and few > > cons... In order to get a better feeling for this proposal I will go > > through the simplified version without Affected marking first: > > > > PCN Meaning ECN DSCP > > > > PCN capable 00 PCN 1 > > Admission Mark 11 PCN 1 > > Termination Mark 11/00 PCN 2 > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN behaviour > > aggregate. > > > > Pros: > > o Termination marking and admission marking are independent, eg > > termination marking can be done after a packet has been admission > > marked. Therefore a router can write AM or TM without having to read the > > packet's PCN marking first, which is easier to implement. (Note: > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > draft-charny-pcn-comparison.) > > > > o This scheme avoids giving semantics to ECT(0) and ECT(1). This is > > safest option if packets leak outside the PCN region, due to some fort > > of misconfiguration of the PCN-boundary-nodes (relevant for a single > > domain deployment of PCN). > > > > o It leaves open the possibility of using ECT(0) and ECT(1) in some > > mysterious way in a future end-to-end PCN deployment > > > > o For a router to classify a packet as PCN, it simply reads its DSCP. > > This is probably easier than checking both its DSCP & ECN fields. > > > > o Incremental deployment steps are possible > > [1] could deploy SM initially and later AM/TM. Just add the second DSCP. > > If a router isn't upgraded at the same time nothing too horrific > > happens. > > [2] could just deploy admission control & add termination later, just by > > adding a new DSCP; there is no need to change the encoding and check for > > backwards compatibility? Vice-versa is also ok? > > > > Cons: > > o It needs an extra DSCP, per PCN behaviour aggregate. (Although > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > o If a packet (in a PCN flow) arrives at the egress with its ECN = 11 > > and it really is required to preserve this info across the PCN-domain, > > then some complexity is needed at the PCN-boundary-nodes (tunnelling) > > > > o If the PCN-domain is operating multipath routing (ECMP) that uses the > > DSCP to select routes, then there may be mis-ordering of packets within > > a flow. This may be OK as (1) no-one has yet said they know of an ECMP > > algorithm that in practie uses the DSCP; (2) a risk of mis-ordering when > > there is termination marking may be acceptable > > > > If Affected marking is needed then the scheme can be modified as > > follows: > > > > PCN Meaning ECN DSCP > > > > PCN capable 00 PCN 1 > > Admission Mark 11 PCN 1 > > Termination Mark 11 PCN 2 > > Affected Mark 00 PCN 2 > > > > The pros for this scheme are broadly similar to the above. However there > > is a new con which may or may not matter: If a packet is affected marked > > and a later node is doing admission marking then it will reset the > > affected mark to a termination mark. Work would be needed to see if this > > skews the results and causes significant over-termination or not. > > > > Please could people look through this scheme and highlight any > > additional concerns that they may have (and extra benefits too). I would > > like to get as many opinions as possible. > > > > What I want to avoid is people just emailing back with "why not try this > > scheme instead". Currently we seem to have a plethora of possible > > schemes on the table and people need to start putting down much clearer > > pros and cons for the schemes they support... So it could be good to > > have a similar "one page" email about a specific scheme that only uses > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > Toby > > ____________________________________________________________________ > > Toby Moncaster, Networks Research Centre, BT > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > -- > 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 08:48:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F2728C857; Wed, 20 Feb 2008 08:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 rIppHuVwyWI9; Wed, 20 Feb 2008 08:48:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8130D28C1B4; Wed, 20 Feb 2008 08:48:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4AD73A6BAF for ; Wed, 20 Feb 2008 08:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-XugrYJgdCs for ; Wed, 20 Feb 2008 08:48:11 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id EBA923A68CA for ; Wed, 20 Feb 2008 08:48:10 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:48:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 16:48:05 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B5@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAADh6jA= From: To: , X-OriginalArrivalTime: 20 Feb 2008 16:48:07.0066 (UTC) FILETIME=[5E380FA0:01C873E0] Cc: pcn@ietf.org Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael > -----Original Message----- > > I agree with you that spending one DSCP value is quite expensive (not > two, as one is spent anyway). Now remember your email where you proposed to do without any new DSCPs. _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 09:25:13 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F70728C24E; Wed, 20 Feb 2008 09:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 aRANr7kIAQ5K; Wed, 20 Feb 2008 09:25:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6652E28C281; Wed, 20 Feb 2008 09:25:11 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DBD28C24E for ; Wed, 20 Feb 2008 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hXujvbSuDyh for ; Wed, 20 Feb 2008 09:25:09 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3E20F28C281 for ; Wed, 20 Feb 2008 09:25:09 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:23:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 17:23:59 -0000 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: RE: PCN encoding option thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAAIEPcA= From: To: , X-OriginalArrivalTime: 20 Feb 2008 17:23:46.0825 (UTC) FILETIME=[599D5F90:01C873E5] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org You are correct that ECN nodes outside the PCN domain can not drop 11 marked packets (unless their buffer is full). However I think they will simply mark the next available packet OR drop the next packet if it is not ECN capable. Whilst this is slightly unsafe in that it may temporarily delay the reporting of congestion and may mean a different node is notified of the congestion, this seems a much more minor issue than letting 10 or 01 leak. Recall that ECN implicitly builds in a safety margin for reporting of congestion before it actually occurs. Toby > -----Original Message----- > From: Eardley,PL,Philip,CXR9 R > Sent: 20 February 2008 16:44 > To: 'menth@informatik.uni-wuerzburg.de'; Moncaster,T,Toby,CXR9 R > Cc: pcn@ietf.org; khchan@nortel.com; babiarz@nortel.com; > sob@harvard.edu; steven.blake@ericsson.com; > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > Subject: RE: FW: RE: PCN encoding option > > Thanks Michael > > I agree with you that spending one DSCP value is quite > expensive (not two, as one is spent anyway). I think the only > way of really assessing this properly is for an alternative > proposal (with pros and cons) that requires only one DSCP. > Then we can see where the consensus for the best (/least bad) > encoding lies. Personally I have no axe to grind for or > against either - I'm not yet convinced that the proposal > below is definitely the way to go, until compared it in > detail with other proposals. > > So I think it would be really useful to have a "1 pager" for > alternative proposal(s) before the ietf, as I think this > would make Philadelphia discussions more productive. > > > You're correct about one of the motivations (advantages) for > this proposal (although I don't think the issues are exactly > the same for 11 leakage as 01/10 leakage). > > Consider the case where 11 leaks out of the PCN domain. If > the endpoints are ECN capable, then the ECN source slows down > (seems reasonable). If they're not capable, then the impact > outside the domain isn't any different to what would happen > without PCN-domain. > > Consider the case where ECN-11 leaks into the PCN domain. > Then this will lead to either flow admission or termination > in the PCN-domain. These are both safe, in that the reaction > is (I believe) at least as severe as would happen in an all > ECN world. > You mention that this might not terminate the ECN-11 flow > specifically (some other flow might get terminated instead). > I think this is true, though it also implies that [1] > end-to-end ECN & PCN on the same flow really is useful, [2] > the mechanism (eg tunnelling) to carry ECN-marking > transparently across the PCN-domain has also failed, [3] the > flows which are terminated aren't other ECN-11 flows that are > also getting in due to the same misconfiguration. > > Best wishes > Phil > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: 20 February 2008 10:50 > > To: Moncaster,T,Toby,CXR9 R > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > Subject: Re: FW: RE: PCN encoding option > > > > Hi Toby, > > > > as I understand the proposal, the motivation is to avoid 01/10 > > codepoints as it is not good if they leak out of the > network since 01/10 > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > However, there is > > the same problem with 11 marking, i.e. 11-packets may not > be dropped by > > ECN nodes outside the PCN domain although endpoints are not > ECN capable. > > Even if 11-packets trigger flow termination, it is not > guaranteed that > > exactly the marked flow going over an overloaded ECN node > is terminated. > > Just want to say that this solution wants to solve a > problem that exists > > only in case of misconfiguration (leaking packets), but > does not fully > > achieve that objective. Therefore, I feel that spending two > DSCP values > > is quite expensive. > > > > Regards, > > > > Michael > > > > toby.moncaster@bt.com wrote: > > > > > > All, > > > > > > Phil and I have just been discussing the encoding draft > and feel we may > > > have lit upon a neat solution that seems to have lots of > pros and few > > > cons... In order to get a better feeling for this > proposal I will go > > > through the simplified version without Affected marking first: > > > > > > PCN Meaning ECN DSCP > > > > > > PCN capable 00 PCN 1 > > > Admission Mark 11 PCN 1 > > > Termination Mark 11/00 PCN 2 > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same > PCN behaviour > > > aggregate. > > > > > > Pros: > > > o Termination marking and admission marking are independent, eg > > > termination marking can be done after a packet has been admission > > > marked. Therefore a router can write AM or TM without > having to read the > > > packet's PCN marking first, which is easier to implement. (Note: > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > draft-charny-pcn-comparison.) > > > > > > o This scheme avoids giving semantics to ECT(0) and > ECT(1). This is > > > safest option if packets leak outside the PCN region, due > to some fort > > > of misconfiguration of the PCN-boundary-nodes (relevant > for a single > > > domain deployment of PCN). > > > > > > o It leaves open the possibility of using ECT(0) and > ECT(1) in some > > > mysterious way in a future end-to-end PCN deployment > > > > > > o For a router to classify a packet as PCN, it simply > reads its DSCP. > > > This is probably easier than checking both its DSCP & ECN fields. > > > > > > o Incremental deployment steps are possible > > > [1] could deploy SM initially and later AM/TM. Just add > the second DSCP. > > > If a router isn't upgraded at the same time nothing too horrific > > > happens. > > > [2] could just deploy admission control & add termination > later, just by > > > adding a new DSCP; there is no need to change the > encoding and check for > > > backwards compatibility? Vice-versa is also ok? > > > > > > Cons: > > > o It needs an extra DSCP, per PCN behaviour aggregate. (Although > > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > > > o If a packet (in a PCN flow) arrives at the egress with > its ECN = 11 > > > and it really is required to preserve this info across > the PCN-domain, > > > then some complexity is needed at the PCN-boundary-nodes > (tunnelling) > > > > > > o If the PCN-domain is operating multipath routing > (ECMP) that uses the > > > DSCP to select routes, then there may be mis-ordering of > packets within > > > a flow. This may be OK as (1) no-one has yet said they > know of an ECMP > > > algorithm that in practie uses the DSCP; (2) a risk of > mis-ordering when > > > there is termination marking may be acceptable > > > > > > If Affected marking is needed then the scheme can be modified as > > > follows: > > > > > > PCN Meaning ECN DSCP > > > > > > PCN capable 00 PCN 1 > > > Admission Mark 11 PCN 1 > > > Termination Mark 11 PCN 2 > > > Affected Mark 00 PCN 2 > > > > > > The pros for this scheme are broadly similar to the > above. However there > > > is a new con which may or may not matter: If a packet is > affected marked > > > and a later node is doing admission marking then it will reset the > > > affected mark to a termination mark. Work would be needed > to see if this > > > skews the results and causes significant over-termination or not. > > > > > > Please could people look through this scheme and highlight any > > > additional concerns that they may have (and extra > benefits too). I would > > > like to get as many opinions as possible. > > > > > > What I want to avoid is people just emailing back with > "why not try this > > > scheme instead". Currently we seem to have a plethora of possible > > > schemes on the table and people need to start putting > down much clearer > > > pros and cons for the schemes they support... So it could > be good to > > > have a similar "one page" email about a specific scheme > that only uses > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > Toby > > > > ____________________________________________________________________ > > > Toby Moncaster, Networks Research > Centre, BT > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > -- > > 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 09:48:32 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3535428C807; Wed, 20 Feb 2008 09:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 N7i8eE9bXC8v; Wed, 20 Feb 2008 09:48:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E360828C26A; Wed, 20 Feb 2008 09:48:30 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F107028C222 for ; Wed, 20 Feb 2008 09:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB-l5RqclHRZ for ; Wed, 20 Feb 2008 09:48:28 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 2FACA28C24E for ; Wed, 20 Feb 2008 09:48:27 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 108C3A068F; Wed, 20 Feb 2008 18:48:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 018B6A068D; Wed, 20 Feb 2008 18:48:24 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2CA5FA067D; Wed, 20 Feb 2008 18:48:15 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1KHmFV27405; Wed, 20 Feb 2008 18:48:15 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 897ACC813B; Wed, 20 Feb 2008 18:48:10 +0100 (CET) Message-ID: <47BC679D.7090504@informatik.uni-wuerzburg.de> Date: Wed, 20 Feb 2008 18:47:09 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > Thanks Michael > > I agree with you that spending one DSCP value is quite expensive (not > two, as one is spent anyway). I think the only way of really assessing > this properly is for an alternative proposal (with pros and cons) that > requires only one DSCP. Then we can see where the consensus for the best > (/least bad) encoding lies. Personally I have no axe to grind for or > against either - I'm not yet convinced that the proposal below is > definitely the way to go, until compared it in detail with other > proposals. > > So I think it would be really useful to have a "1 pager" for alternative > proposal(s) before the ietf, as I think this would make Philadelphia > discussions more productive. > > > You're correct about one of the motivations (advantages) for this > proposal (although I don't think the issues are exactly the same for 11 > leakage as 01/10 leakage). > > Consider the case where 11 leaks out of the PCN domain. If the endpoints > are ECN capable, then the ECN source slows down (seems reasonable). If > they're not capable, then the impact outside the domain isn't any > different to what would happen without PCN-domain. > No, there is a difference. 11-marked packets are not dropped when congestion occurs and if the endpoints are not ECN-capable, they don't backoff. That's the problem. That's why I say the solution is not fully sound. Regards, Michael > Consider the case where ECN-11 leaks into the PCN domain. Then this will > lead to either flow admission or termination in the PCN-domain. These > are both safe, in that the reaction is (I believe) at least as severe as > would happen in an all ECN world. > You mention that this might not terminate the ECN-11 flow specifically > (some other flow might get terminated instead). I think this is true, > though it also implies that [1] end-to-end ECN & PCN on the same flow > really is useful, [2] the mechanism (eg tunnelling) to carry ECN-marking > transparently across the PCN-domain has also failed, [3] the flows which > are terminated aren't other ECN-11 flows that are also getting in due to > the same misconfiguration. > > Best wishes > Phil > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 20 February 2008 10:50 >> To: Moncaster,T,Toby,CXR9 R >> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; >> babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; >> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >> Subject: Re: FW: RE: PCN encoding option >> >> Hi Toby, >> >> as I understand the proposal, the motivation is to avoid 01/10 >> codepoints as it is not good if they leak out of the network since >> > 01/10 > >> is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, there is >> the same problem with 11 marking, i.e. 11-packets may not be dropped >> > by > >> ECN nodes outside the PCN domain although endpoints are not ECN >> > capable. > >> Even if 11-packets trigger flow termination, it is not guaranteed that >> exactly the marked flow going over an overloaded ECN node is >> > terminated. > >> Just want to say that this solution wants to solve a problem that >> > exists > >> only in case of misconfiguration (leaking packets), but does not fully >> achieve that objective. Therefore, I feel that spending two DSCP >> > values > >> is quite expensive. >> >> Regards, >> >> Michael >> >> toby.moncaster@bt.com wrote: >> >>> All, >>> >>> Phil and I have just been discussing the encoding draft and feel we >>> > may > >>> have lit upon a neat solution that seems to have lots of pros and >>> > few > >>> cons... In order to get a better feeling for this proposal I will go >>> through the simplified version without Affected marking first: >>> >>> PCN Meaning ECN DSCP >>> >>> PCN capable 00 PCN 1 >>> Admission Mark 11 PCN 1 >>> Termination Mark 11/00 PCN 2 >>> >>> PCN 1 and PCN 2 are 2 different codepoints with the same PCN >>> > behaviour > >>> aggregate. >>> >>> Pros: >>> o Termination marking and admission marking are independent, eg >>> termination marking can be done after a packet has been admission >>> marked. Therefore a router can write AM or TM without having to read >>> > the > >>> packet's PCN marking first, which is easier to implement. (Note: >>> Over-writing a TM with AM is not allowed for 3SM & CL, see >>> draft-charny-pcn-comparison.) >>> >>> o This scheme avoids giving semantics to ECT(0) and ECT(1). This is >>> safest option if packets leak outside the PCN region, due to some >>> > fort > >>> of misconfiguration of the PCN-boundary-nodes (relevant for a single >>> domain deployment of PCN). >>> >>> o It leaves open the possibility of using ECT(0) and ECT(1) in some >>> mysterious way in a future end-to-end PCN deployment >>> >>> o For a router to classify a packet as PCN, it simply reads its >>> > DSCP. > >>> This is probably easier than checking both its DSCP & ECN fields. >>> >>> o Incremental deployment steps are possible >>> [1] could deploy SM initially and later AM/TM. Just add the second >>> > DSCP. > >>> If a router isn't upgraded at the same time nothing too horrific >>> happens. >>> [2] could just deploy admission control & add termination later, >>> > just by > >>> adding a new DSCP; there is no need to change the encoding and check >>> > for > >>> backwards compatibility? Vice-versa is also ok? >>> >>> Cons: >>> o It needs an extra DSCP, per PCN behaviour aggregate. (Although >>> possibly it's OK to use the same DSCP for TM for all PCN BAs?) >>> >>> o If a packet (in a PCN flow) arrives at the egress with its ECN = >>> > 11 > >>> and it really is required to preserve this info across the >>> > PCN-domain, > >>> then some complexity is needed at the PCN-boundary-nodes >>> > (tunnelling) > >>> o If the PCN-domain is operating multipath routing (ECMP) that uses >>> > the > >>> DSCP to select routes, then there may be mis-ordering of packets >>> > within > >>> a flow. This may be OK as (1) no-one has yet said they know of an >>> > ECMP > >>> algorithm that in practie uses the DSCP; (2) a risk of mis-ordering >>> > when > >>> there is termination marking may be acceptable >>> >>> If Affected marking is needed then the scheme can be modified as >>> follows: >>> >>> PCN Meaning ECN DSCP >>> >>> PCN capable 00 PCN 1 >>> Admission Mark 11 PCN 1 >>> Termination Mark 11 PCN 2 >>> Affected Mark 00 PCN 2 >>> >>> The pros for this scheme are broadly similar to the above. However >>> > there > >>> is a new con which may or may not matter: If a packet is affected >>> > marked > >>> and a later node is doing admission marking then it will reset the >>> affected mark to a termination mark. Work would be needed to see if >>> > this > >>> skews the results and causes significant over-termination or not. >>> >>> Please could people look through this scheme and highlight any >>> additional concerns that they may have (and extra benefits too). I >>> > would > >>> like to get as many opinions as possible. >>> >>> What I want to avoid is people just emailing back with "why not try >>> > this > >>> scheme instead". Currently we seem to have a plethora of possible >>> schemes on the table and people need to start putting down much >>> > clearer > >>> pros and cons for the schemes they support... So it could be good to >>> have a similar "one page" email about a specific scheme that only >>> > uses > >>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>> >>> Toby >>> ____________________________________________________________________ >>> Toby Moncaster, Networks Research Centre, BT >>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 >>> >>> >> -- >> 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 >> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 09:48:43 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C7628C0F8; Wed, 20 Feb 2008 09:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 farCIsZd3PHZ; Wed, 20 Feb 2008 09:48:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2449328C20A; Wed, 20 Feb 2008 09:48:42 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29A628C0F8 for ; Wed, 20 Feb 2008 09:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osH5AT4wDvjX for ; Wed, 20 Feb 2008 09:48:39 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 1E34228C1A8 for ; Wed, 20 Feb 2008 09:48:39 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id ACEB6198DBE; Wed, 20 Feb 2008 18:48:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9EE1B198DAF; Wed, 20 Feb 2008 18:48:35 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id BF3C8198DA9; Wed, 20 Feb 2008 18:48:26 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1KHmQV27412; Wed, 20 Feb 2008 18:48:26 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id BDB30C81C9; Wed, 20 Feb 2008 18:48:23 +0100 (CET) Message-ID: <47BC67AA.2030009@informatik.uni-wuerzburg.de> Date: Wed, 20 Feb 2008 18:47:23 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, toby.moncaster@bt.com wrote: > You are correct that ECN nodes outside the PCN domain can not drop 11 > marked packets (unless their buffer is full). However I think they will > simply mark the next available packet OR drop the next packet if it is > not ECN capable. Well, I'm not sure about that. It would be interesting to hear from vendors or other people knowing how ECN marking works in details how this is solved. > Whilst this is slightly unsafe in that it may > temporarily delay the reporting of congestion and may mean a different > node is notified of the congestion, this seems a much more minor issue > than letting 10 or 01 leak. Recall that ECN implicitly builds in a > safety margin for reporting of congestion before it actually occurs. > I don't know how save this marging really is since if queues build up at high speed, they also quickly overflow. Incipient congestion is already the start of congestion which is unlike PCN thresholds. Regards, Michael > Toby > > >> -----Original Message----- >> From: Eardley,PL,Philip,CXR9 R >> Sent: 20 February 2008 16:44 >> To: 'menth@informatik.uni-wuerzburg.de'; Moncaster,T,Toby,CXR9 R >> Cc: pcn@ietf.org; khchan@nortel.com; babiarz@nortel.com; >> sob@harvard.edu; steven.blake@ericsson.com; >> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >> Subject: RE: FW: RE: PCN encoding option >> >> Thanks Michael >> >> I agree with you that spending one DSCP value is quite >> expensive (not two, as one is spent anyway). I think the only >> way of really assessing this properly is for an alternative >> proposal (with pros and cons) that requires only one DSCP. >> Then we can see where the consensus for the best (/least bad) >> encoding lies. Personally I have no axe to grind for or >> against either - I'm not yet convinced that the proposal >> below is definitely the way to go, until compared it in >> detail with other proposals. >> >> So I think it would be really useful to have a "1 pager" for >> alternative proposal(s) before the ietf, as I think this >> would make Philadelphia discussions more productive. >> >> >> You're correct about one of the motivations (advantages) for >> this proposal (although I don't think the issues are exactly >> the same for 11 leakage as 01/10 leakage). >> >> Consider the case where 11 leaks out of the PCN domain. If >> the endpoints are ECN capable, then the ECN source slows down >> (seems reasonable). If they're not capable, then the impact >> outside the domain isn't any different to what would happen >> without PCN-domain. >> >> Consider the case where ECN-11 leaks into the PCN domain. >> Then this will lead to either flow admission or termination >> in the PCN-domain. These are both safe, in that the reaction >> is (I believe) at least as severe as would happen in an all >> ECN world. >> You mention that this might not terminate the ECN-11 flow >> specifically (some other flow might get terminated instead). >> I think this is true, though it also implies that [1] >> end-to-end ECN & PCN on the same flow really is useful, [2] >> the mechanism (eg tunnelling) to carry ECN-marking >> transparently across the PCN-domain has also failed, [3] the >> flows which are terminated aren't other ECN-11 flows that are >> also getting in due to the same misconfiguration. >> >> Best wishes >> Phil >> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>> Sent: 20 February 2008 10:50 >>> To: Moncaster,T,Toby,CXR9 R >>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; >>> babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; >>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>> Subject: Re: FW: RE: PCN encoding option >>> >>> Hi Toby, >>> >>> as I understand the proposal, the motivation is to avoid 01/10 >>> codepoints as it is not good if they leak out of the >>> >> network since 01/10 >> >>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>> >> However, there is >> >>> the same problem with 11 marking, i.e. 11-packets may not >>> >> be dropped by >> >>> ECN nodes outside the PCN domain although endpoints are not >>> >> ECN capable. >> >>> Even if 11-packets trigger flow termination, it is not >>> >> guaranteed that >> >>> exactly the marked flow going over an overloaded ECN node >>> >> is terminated. >> >>> Just want to say that this solution wants to solve a >>> >> problem that exists >> >>> only in case of misconfiguration (leaking packets), but >>> >> does not fully >> >>> achieve that objective. Therefore, I feel that spending two >>> >> DSCP values >> >>> is quite expensive. >>> >>> Regards, >>> >>> Michael >>> >>> toby.moncaster@bt.com wrote: >>> >>>> All, >>>> >>>> Phil and I have just been discussing the encoding draft >>>> >> and feel we may >> >>>> have lit upon a neat solution that seems to have lots of >>>> >> pros and few >> >>>> cons... In order to get a better feeling for this >>>> >> proposal I will go >> >>>> through the simplified version without Affected marking first: >>>> >>>> PCN Meaning ECN DSCP >>>> >>>> PCN capable 00 PCN 1 >>>> Admission Mark 11 PCN 1 >>>> Termination Mark 11/00 PCN 2 >>>> >>>> PCN 1 and PCN 2 are 2 different codepoints with the same >>>> >> PCN behaviour >> >>>> aggregate. >>>> >>>> Pros: >>>> o Termination marking and admission marking are independent, eg >>>> termination marking can be done after a packet has been admission >>>> marked. Therefore a router can write AM or TM without >>>> >> having to read the >> >>>> packet's PCN marking first, which is easier to implement. (Note: >>>> Over-writing a TM with AM is not allowed for 3SM & CL, see >>>> draft-charny-pcn-comparison.) >>>> >>>> o This scheme avoids giving semantics to ECT(0) and >>>> >> ECT(1). This is >> >>>> safest option if packets leak outside the PCN region, due >>>> >> to some fort >> >>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>> >> for a single >> >>>> domain deployment of PCN). >>>> >>>> o It leaves open the possibility of using ECT(0) and >>>> >> ECT(1) in some >> >>>> mysterious way in a future end-to-end PCN deployment >>>> >>>> o For a router to classify a packet as PCN, it simply >>>> >> reads its DSCP. >> >>>> This is probably easier than checking both its DSCP & ECN fields. >>>> >>>> o Incremental deployment steps are possible >>>> [1] could deploy SM initially and later AM/TM. Just add >>>> >> the second DSCP. >> >>>> If a router isn't upgraded at the same time nothing too horrific >>>> happens. >>>> [2] could just deploy admission control & add termination >>>> >> later, just by >> >>>> adding a new DSCP; there is no need to change the >>>> >> encoding and check for >> >>>> backwards compatibility? Vice-versa is also ok? >>>> >>>> Cons: >>>> o It needs an extra DSCP, per PCN behaviour aggregate. (Although >>>> possibly it's OK to use the same DSCP for TM for all PCN BAs?) >>>> >>>> o If a packet (in a PCN flow) arrives at the egress with >>>> >> its ECN = 11 >> >>>> and it really is required to preserve this info across >>>> >> the PCN-domain, >> >>>> then some complexity is needed at the PCN-boundary-nodes >>>> >> (tunnelling) >> >>>> o If the PCN-domain is operating multipath routing >>>> >> (ECMP) that uses the >> >>>> DSCP to select routes, then there may be mis-ordering of >>>> >> packets within >> >>>> a flow. This may be OK as (1) no-one has yet said they >>>> >> know of an ECMP >> >>>> algorithm that in practie uses the DSCP; (2) a risk of >>>> >> mis-ordering when >> >>>> there is termination marking may be acceptable >>>> >>>> If Affected marking is needed then the scheme can be modified as >>>> follows: >>>> >>>> PCN Meaning ECN DSCP >>>> >>>> PCN capable 00 PCN 1 >>>> Admission Mark 11 PCN 1 >>>> Termination Mark 11 PCN 2 >>>> Affected Mark 00 PCN 2 >>>> >>>> The pros for this scheme are broadly similar to the >>>> >> above. However there >> >>>> is a new con which may or may not matter: If a packet is >>>> >> affected marked >> >>>> and a later node is doing admission marking then it will reset the >>>> affected mark to a termination mark. Work would be needed >>>> >> to see if this >> >>>> skews the results and causes significant over-termination or not. >>>> >>>> Please could people look through this scheme and highlight any >>>> additional concerns that they may have (and extra >>>> >> benefits too). I would >> >>>> like to get as many opinions as possible. >>>> >>>> What I want to avoid is people just emailing back with >>>> >> "why not try this >> >>>> scheme instead". Currently we seem to have a plethora of possible >>>> schemes on the table and people need to start putting >>>> >> down much clearer >> >>>> pros and cons for the schemes they support... So it could >>>> >> be good to >> >>>> have a similar "one page" email about a specific scheme >>>> >> that only uses >> >>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>> >>>> Toby >>>> >>>> >> ____________________________________________________________________ >> >>>> Toby Moncaster, Networks Research >>>> >> Centre, BT >> >>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 >>>> >>>> >>> -- >>> 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 >>> >> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 20 19:34:09 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4CD28C5F1; Wed, 20 Feb 2008 19:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, 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 r9ijIgWw7uM8; Wed, 20 Feb 2008 19:34:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2C028C22D; Wed, 20 Feb 2008 19:34:08 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15BE28C22D for ; Wed, 20 Feb 2008 19:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h+uZ-EYHRM7 for ; Wed, 20 Feb 2008 19:34:05 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id 03E0228C1F1 for ; Wed, 20 Feb 2008 19:34:05 -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 <0JWK00DMWKKE4F@szxga03-in.huawei.com> for pcn@ietf.org; Thu, 21 Feb 2008 11:33:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWK008LGKKEXT@szxga03-in.huawei.com> for pcn@ietf.org; Thu, 21 Feb 2008 11:33:50 +0800 (CST) Received: from z24109b ([10.70.76.86]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWK0005DKKEEL@szxml03-in.huawei.com> for pcn@ietf.org; Thu, 21 Feb 2008 11:33:50 +0800 (CST) Date: Thu, 21 Feb 2008 11:33:50 +0800 From: Tina TSOU To: Tom Taylor , menth@informatik.uni-wuerzburg.de Message-id: <009a01c8743a$93067be0$564c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <47B6E90B.9040001@rogers.com> <47BC0893.8080109@informatik.uni-wuerzburg.de> Cc: pcn , Osamu Kamatani , Huanghexian , Schwarz Albrecht , "Sun, Dong \(Dong\)" Subject: Re: [PCN] [Fwd: New Version Notification fordraft-tsou-pcn-racf-applic-00] 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: , Content-Type: multipart/mixed; boundary="===============0598607416==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0598607416== Content-type: multipart/alternative; boundary="Boundary_(ID_zY6rlJ0UaZLhMi8K91SWSA)" This is a multi-part message in MIME format. --Boundary_(ID_zY6rlJ0UaZLhMi8K91SWSA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Michael, Thanks:) Will fix it. B. R. Tina ----- Original Message ----- From: Michael Menth To: Tom Taylor Cc: pcn ; Osamu Kamatani ; Schwarz Albrecht ; Sun, Dong (Dong) Sent: Wednesday, February 20, 2008 7:01 PM Subject: Re: [PCN] [Fwd: New Version Notification fordraft-tsou-pcn-racf-applic-00] Hi Tom, thanks for this input. I read this draft and find it interesting to see how PCN can be used in in other architectures. However, I had problems to fully follow the document as it contains many abbreviations that are not spelled out even a single time. A small glossary would be helpful and more introductory comprehensive text about the considered architecture. Regards, Michael Tom Taylor wrote: > FYI > > -------- Original Message -------- > Subject: New Version Notification for draft-tsou-pcn-racf-applic-00 > Date: Fri, 15 Feb 2008 19:34:44 -0800 (PST) > From: IETF I-D Submission Tool > To: tom.taylor@rogers.com > CC: tena@huawei.com > > > A new version of I-D, draft-tsou-pcn-racf-applic-00.txt has been successfuly > submitted by Tom Taylor and posted to the IETF repository. > > Filename: draft-tsou-pcn-racf-applic > Revision: 00 > Title: Applicability Statement for the Use of Pre-Congestion Notification in a > Resource-Controlled Network > Creation_date: 2008-02-15 > WG ID: Independent Submission > Number_of_pages: 18 > > Abstract: > This document is written to help coordinate work on pre-congestion > notification (PCN) between the IETF PCN Working Group and the ITU-T. > It maps the use of PCN into the ITU-T transport control architecture. > It examines three scenarios, showing in each, where new requirements > are placed on the ITU-T architecture. In each case, the ITU-T > functional entity known as the Transport Resource Control Functional > Entity (TRC-FE) is seen as the logical destination for PCN congestion > reports and PCN flow termination reports, which it uses to keep track > of network status. As logical entities, instances of the TRC-FE can > be present in the ingress nodes, in one or more centralized devices, > or in both. These alternatives define the scenarios examined. > > > > The IETF Secretariat. > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --Boundary_(ID_zY6rlJ0UaZLhMi8K91SWSA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Michael,
Thanks:)
Will fix it.
 
B. R.
Tina
----- Original Message -----
Sent: Wednesday, February 20, 2008 7:01 PM
Subject: Re: [PCN] [Fwd: New Version Notification fordraft-tsou-pcn-racf-applic-00]

Hi Tom,

thanks for this input. I read this draft and find it interesting to see
how PCN can be used in in other architectures. However, I had problems
to fully follow the document as it contains many abbreviations that are
not spelled out even a single time. A small glossary would be helpful
and more introductory comprehensive text about the considered architecture.

Regards,

    Michael

Tom Taylor wrote:
> FYI
>
> -------- Original Message --------
> Subject: New Version Notification for draft-tsou-pcn-racf-applic-00
> Date: Fri, 15 Feb 2008 19:34:44 -0800 (PST)
> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> To: tom.taylor@rogers.com
> CC: tena@huawei.com
>
>
> A new version of I-D, draft-tsou-pcn-racf-applic-00.txt has been successfuly
> submitted by Tom Taylor and posted to the IETF repository.
>
> Filename: draft-tsou-pcn-racf-applic
> Revision: 00
> Title: Applicability Statement for the Use of Pre-Congestion Notification in a
> Resource-Controlled Network
> Creation_date: 2008-02-15
> WG ID: Independent Submission
> Number_of_pages: 18
>
> Abstract:
> This document is written to help coordinate work on pre-congestion
> notification (PCN) between the IETF PCN Working Group and the ITU-T.
> It maps the use of PCN into the ITU-T transport control architecture.
> It examines three scenarios, showing in each, where new requirements
> are placed on the ITU-T architecture.  In each case, the ITU-T
> functional entity known as the Transport Resource Control Functional
> Entity (TRC-FE) is seen as the logical destination for PCN congestion
> reports and PCN flow termination reports, which it uses to keep track
> of network status.  As logical entities, instances of the TRC-FE can
> be present in the ingress nodes, in one or more centralized devices,
> or in both.  These alternatives define the scenarios examined.
>
>
>
> The IETF Secretariat.
>
>
>
>
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> http://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

_______________________________________________
PCN mailing list
PCN@ietf.org
http://www.ietf.org/mailman/listinfo/pcn
--Boundary_(ID_zY6rlJ0UaZLhMi8K91SWSA)-- --===============0598607416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn --===============0598607416==-- From pcn-bounces@ietf.org Wed Feb 20 22:43:27 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7569528C8AE; Wed, 20 Feb 2008 22:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 j6r3xW9jUl4q; Wed, 20 Feb 2008 22:43:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4AD3A6B07; Wed, 20 Feb 2008 22:43:26 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CC13A6ACB for ; Wed, 20 Feb 2008 22:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No2Y7hqVuec5 for ; Wed, 20 Feb 2008 22:43:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1D4143A6ABD for ; Wed, 20 Feb 2008 22:43:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 52EEF2005D; Thu, 21 Feb 2008 07:43:18 +0100 (CET) X-AuditID: c1b4fb3e-a79f9bb000000b15-4b-47bd1d865f0e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 39C9D20499; Thu, 21 Feb 2008 07:43:18 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 07:43:18 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 07:43:17 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmA= References: <47BC05DA.7090701@informatik.uni-wuerzburg.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Ingemar Johansson S" To: , , X-OriginalArrivalTime: 21 Feb 2008 06:43:18.0056 (UTC) FILETIME=[0AB25280:01C87455] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi In this discussion it may be well worth the effort to consider the end to end ECN usecases that we foresee when considering various PCN encoding options. Please have a look at http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt for a discussion of the use cases and a motivation to why end to end ECN should be maintained even across PCN nodes even for non DF traffic. That said I realize that there is some cost associated to the use of DSCP codepoints, this cost must however be weighted against the risk that other functionality like end to end ECN semantics is probably broken if a PCN encoding option "fiddles" with the ECN bits. It is easy to see that if one wish to maintain support for end to end ECN (not only in DF class) it simply costs more DSCP codepoints. I am not explicitly saying don't do this or that but I wish to avoid a situation where one technique has to be avoided in favor of the other as it may in the end prevent deployment of both. If one can yank the two together so much the better even though the cost e.g in DSCP code points is regarded as higher. Regards Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: den 20 februari 2008 17:44 > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > Cc: pcn@ietf.org; bob.briscoe@bt.com > Subject: Re: [PCN] FW: RE: PCN encoding option > > Thanks Michael > > I agree with you that spending one DSCP value is quite > expensive (not two, as one is spent anyway). I think the only > way of really assessing this properly is for an alternative > proposal (with pros and cons) that requires only one DSCP. > Then we can see where the consensus for the best (/least bad) > encoding lies. Personally I have no axe to grind for or > against either - I'm not yet convinced that the proposal > below is definitely the way to go, until compared it in > detail with other proposals. > > So I think it would be really useful to have a "1 pager" for > alternative > proposal(s) before the ietf, as I think this would make > Philadelphia discussions more productive. > > > You're correct about one of the motivations (advantages) for > this proposal (although I don't think the issues are exactly > the same for 11 leakage as 01/10 leakage). > > Consider the case where 11 leaks out of the PCN domain. If > the endpoints are ECN capable, then the ECN source slows down > (seems reasonable). If they're not capable, then the impact > outside the domain isn't any different to what would happen > without PCN-domain. > > Consider the case where ECN-11 leaks into the PCN domain. > Then this will lead to either flow admission or termination > in the PCN-domain. These are both safe, in that the reaction > is (I believe) at least as severe as would happen in an all > ECN world. > You mention that this might not terminate the ECN-11 flow > specifically (some other flow might get terminated instead). > I think this is true, though it also implies that [1] > end-to-end ECN & PCN on the same flow really is useful, [2] > the mechanism (eg tunnelling) to carry ECN-marking > transparently across the PCN-domain has also failed, [3] the > flows which are terminated aren't other ECN-11 flows that are > also getting in due to the same misconfiguration. > > Best wishes > Phil > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: 20 February 2008 10:50 > > To: Moncaster,T,Toby,CXR9 R > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > Subject: Re: FW: RE: PCN encoding option > > > > Hi Toby, > > > > as I understand the proposal, the motivation is to avoid 01/10 > > codepoints as it is not good if they leak out of the network since > 01/10 > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > However, there is > > the same problem with 11 marking, i.e. 11-packets may not be dropped > by > > ECN nodes outside the PCN domain although endpoints are not ECN > capable. > > Even if 11-packets trigger flow termination, it is not > guaranteed that > > exactly the marked flow going over an overloaded ECN node is > terminated. > > Just want to say that this solution wants to solve a problem that > exists > > only in case of misconfiguration (leaking packets), but > does not fully > > achieve that objective. Therefore, I feel that spending two DSCP > values > > is quite expensive. > > > > Regards, > > > > Michael > > > > toby.moncaster@bt.com wrote: > > > > > > All, > > > > > > Phil and I have just been discussing the encoding draft > and feel we > may > > > have lit upon a neat solution that seems to have lots of pros and > few > > > cons... In order to get a better feeling for this > proposal I will go > > > through the simplified version without Affected marking first: > > > > > > PCN Meaning ECN DSCP > > > > > > PCN capable 00 PCN 1 > > > Admission Mark 11 PCN 1 > > > Termination Mark 11/00 PCN 2 > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > behaviour > > > aggregate. > > > > > > Pros: > > > o Termination marking and admission marking are independent, eg > > > termination marking can be done after a packet has been admission > > > marked. Therefore a router can write AM or TM without > having to read > the > > > packet's PCN marking first, which is easier to implement. (Note: > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > draft-charny-pcn-comparison.) > > > > > > o This scheme avoids giving semantics to ECT(0) and > ECT(1). This is > > > safest option if packets leak outside the PCN region, due to some > fort > > > of misconfiguration of the PCN-boundary-nodes (relevant > for a single > > > domain deployment of PCN). > > > > > > o It leaves open the possibility of using ECT(0) and > ECT(1) in some > > > mysterious way in a future end-to-end PCN deployment > > > > > > o For a router to classify a packet as PCN, it simply reads its > DSCP. > > > This is probably easier than checking both its DSCP & ECN fields. > > > > > > o Incremental deployment steps are possible [1] could deploy SM > > > initially and later AM/TM. Just add the second > DSCP. > > > If a router isn't upgraded at the same time nothing too horrific > > > happens. > > > [2] could just deploy admission control & add termination later, > just by > > > adding a new DSCP; there is no need to change the > encoding and check > for > > > backwards compatibility? Vice-versa is also ok? > > > > > > Cons: > > > o It needs an extra DSCP, per PCN behaviour aggregate. (Although > > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > > > o If a packet (in a PCN flow) arrives at the egress with > its ECN = > 11 > > > and it really is required to preserve this info across the > PCN-domain, > > > then some complexity is needed at the PCN-boundary-nodes > (tunnelling) > > > > > > o If the PCN-domain is operating multipath routing > (ECMP) that uses > the > > > DSCP to select routes, then there may be mis-ordering of packets > within > > > a flow. This may be OK as (1) no-one has yet said they know of an > ECMP > > > algorithm that in practie uses the DSCP; (2) a risk of > mis-ordering > when > > > there is termination marking may be acceptable > > > > > > If Affected marking is needed then the scheme can be modified as > > > follows: > > > > > > PCN Meaning ECN DSCP > > > > > > PCN capable 00 PCN 1 > > > Admission Mark 11 PCN 1 > > > Termination Mark 11 PCN 2 > > > Affected Mark 00 PCN 2 > > > > > > The pros for this scheme are broadly similar to the above. However > there > > > is a new con which may or may not matter: If a packet is affected > marked > > > and a later node is doing admission marking then it will > reset the > > > affected mark to a termination mark. Work would be needed > to see if > this > > > skews the results and causes significant over-termination or not. > > > > > > Please could people look through this scheme and highlight any > > > additional concerns that they may have (and extra benefits too). I > would > > > like to get as many opinions as possible. > > > > > > What I want to avoid is people just emailing back with > "why not try > this > > > scheme instead". Currently we seem to have a plethora of possible > > > schemes on the table and people need to start putting down much > clearer > > > pros and cons for the schemes they support... So it could > be good to > > > have a similar "one page" email about a specific scheme that only > uses > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > Toby > > > > ____________________________________________________________________ > > > Toby Moncaster, Networks Research > Centre, BT > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > -- > > 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 > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 01:24:33 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F7328C9AE; Thu, 21 Feb 2008 01:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 0j8PNjnanbfX; Thu, 21 Feb 2008 01:24:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA1E28CA01; Thu, 21 Feb 2008 01:24:31 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4845628CA09 for ; Thu, 21 Feb 2008 01:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw1tFrxBJZ-P for ; Thu, 21 Feb 2008 01:24:24 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CE40628C9B9 for ; Thu, 21 Feb 2008 01:24:23 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 09:24:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 09:24:18 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B6@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIA== From: To: , , X-OriginalArrivalTime: 21 Feb 2008 09:24:19.0882 (UTC) FILETIME=[8997F8A0:01C8746B] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ingemar Re > consider the end to end ECN usecases I believe that the emails below about Toby's encoding proposal do indeed already consider ECN. Would appreciate it if you could add further text to it to better capture the (pros and) cons. > more DSCP codepoints I think you may be proposing an encoding that uses all dscp codepoints (as has Georgios). That's fine - but a "1 pager" setting out this option with its pros and cons (ie similar to what toby has done below) is needed I think! At the moment we have lots of options on the table - in order to reach a decision, I think we really need very few options but with their pros and cons better laid out. I haven't managed to get to your draft yet, sorry (next week hopefully) - Thanks Phil > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 21 February 2008 06:43 > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > Moncaster,T,Toby,CXR9 R > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi > > In this discussion it may be well worth the effort to consider the end > to end ECN usecases that we foresee when considering various PCN > encoding options. > Please have a look at > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > for a discussion of the use cases and a motivation to why end to end ECN > should be maintained even across PCN nodes even for non DF traffic. > That said I realize that there is some cost associated to the use of > DSCP codepoints, this cost must however be weighted against the risk > that other functionality like end to end ECN semantics is probably > broken if a PCN encoding option "fiddles" with the ECN bits. It is easy > to see that if one wish to maintain support for end to end ECN (not only > in DF class) it simply costs more DSCP codepoints. > I am not explicitly saying don't do this or that but I wish to avoid a > situation where one technique has to be avoided in favor of the other as > it may in the end prevent deployment of both. If one can yank the two > together so much the better even though the cost e.g in DSCP code points > is regarded as higher. > > Regards > Ingemar > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of philip.eardley@bt.com > > Sent: den 20 februari 2008 17:44 > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > Thanks Michael > > > > I agree with you that spending one DSCP value is quite > > expensive (not two, as one is spent anyway). I think the only > > way of really assessing this properly is for an alternative > > proposal (with pros and cons) that requires only one DSCP. > > Then we can see where the consensus for the best (/least bad) > > encoding lies. Personally I have no axe to grind for or > > against either - I'm not yet convinced that the proposal > > below is definitely the way to go, until compared it in > > detail with other proposals. > > > > So I think it would be really useful to have a "1 pager" for > > alternative > > proposal(s) before the ietf, as I think this would make > > Philadelphia discussions more productive. > > > > > > You're correct about one of the motivations (advantages) for > > this proposal (although I don't think the issues are exactly > > the same for 11 leakage as 01/10 leakage). > > > > Consider the case where 11 leaks out of the PCN domain. If > > the endpoints are ECN capable, then the ECN source slows down > > (seems reasonable). If they're not capable, then the impact > > outside the domain isn't any different to what would happen > > without PCN-domain. > > > > Consider the case where ECN-11 leaks into the PCN domain. > > Then this will lead to either flow admission or termination > > in the PCN-domain. These are both safe, in that the reaction > > is (I believe) at least as severe as would happen in an all > > ECN world. > > You mention that this might not terminate the ECN-11 flow > > specifically (some other flow might get terminated instead). > > I think this is true, though it also implies that [1] > > end-to-end ECN & PCN on the same flow really is useful, [2] > > the mechanism (eg tunnelling) to carry ECN-marking > > transparently across the PCN-domain has also failed, [3] the > > flows which are terminated aren't other ECN-11 flows that are > > also getting in due to the same misconfiguration. > > > > Best wishes > > Phil > > > -----Original Message----- > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > Sent: 20 February 2008 10:50 > > > To: Moncaster,T,Toby,CXR9 R > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > > > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > Subject: Re: FW: RE: PCN encoding option > > > > > > Hi Toby, > > > > > > as I understand the proposal, the motivation is to avoid 01/10 > > > codepoints as it is not good if they leak out of the network since > > 01/10 > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > However, there is > > > the same problem with 11 marking, i.e. 11-packets may not be dropped > > by > > > ECN nodes outside the PCN domain although endpoints are not ECN > > capable. > > > Even if 11-packets trigger flow termination, it is not > > guaranteed that > > > exactly the marked flow going over an overloaded ECN node is > > terminated. > > > Just want to say that this solution wants to solve a problem that > > exists > > > only in case of misconfiguration (leaking packets), but > > does not fully > > > achieve that objective. Therefore, I feel that spending two DSCP > > values > > > is quite expensive. > > > > > > Regards, > > > > > > Michael > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > All, > > > > > > > > Phil and I have just been discussing the encoding draft > > and feel we > > may > > > > have lit upon a neat solution that seems to have lots of pros and > > few > > > > cons... In order to get a better feeling for this > > proposal I will go > > > > through the simplified version without Affected marking first: > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > PCN capable 00 PCN 1 > > > > Admission Mark 11 PCN 1 > > > > Termination Mark 11/00 PCN 2 > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > > behaviour > > > > aggregate. > > > > > > > > Pros: > > > > o Termination marking and admission marking are independent, eg > > > > termination marking can be done after a packet has been admission > > > > marked. Therefore a router can write AM or TM without > > having to read > > the > > > > packet's PCN marking first, which is easier to implement. (Note: > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > draft-charny-pcn-comparison.) > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > ECT(1). This is > > > > safest option if packets leak outside the PCN region, due to some > > fort > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > for a single > > > > domain deployment of PCN). > > > > > > > > o It leaves open the possibility of using ECT(0) and > > ECT(1) in some > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > o For a router to classify a packet as PCN, it simply reads its > > DSCP. > > > > This is probably easier than checking both its DSCP & ECN fields. > > > > > > > > o Incremental deployment steps are possible [1] could deploy SM > > > > initially and later AM/TM. Just add the second > > DSCP. > > > > If a router isn't upgraded at the same time nothing too horrific > > > > happens. > > > > [2] could just deploy admission control & add termination later, > > just by > > > > adding a new DSCP; there is no need to change the > > encoding and check > > for > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > Cons: > > > > o It needs an extra DSCP, per PCN behaviour aggregate. (Although > > > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > its ECN = > > 11 > > > > and it really is required to preserve this info across the > > PCN-domain, > > > > then some complexity is needed at the PCN-boundary-nodes > > (tunnelling) > > > > > > > > o If the PCN-domain is operating multipath routing > > (ECMP) that uses > > the > > > > DSCP to select routes, then there may be mis-ordering of packets > > within > > > > a flow. This may be OK as (1) no-one has yet said they know of an > > ECMP > > > > algorithm that in practie uses the DSCP; (2) a risk of > > mis-ordering > > when > > > > there is termination marking may be acceptable > > > > > > > > If Affected marking is needed then the scheme can be modified as > > > > follows: > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > PCN capable 00 PCN 1 > > > > Admission Mark 11 PCN 1 > > > > Termination Mark 11 PCN 2 > > > > Affected Mark 00 PCN 2 > > > > > > > > The pros for this scheme are broadly similar to the above. However > > there > > > > is a new con which may or may not matter: If a packet is affected > > marked > > > > and a later node is doing admission marking then it will > > reset the > > > > affected mark to a termination mark. Work would be needed > > to see if > > this > > > > skews the results and causes significant over-termination or not. > > > > > > > > Please could people look through this scheme and highlight any > > > > additional concerns that they may have (and extra benefits too). I > > would > > > > like to get as many opinions as possible. > > > > > > > > What I want to avoid is people just emailing back with > > "why not try > > this > > > > scheme instead". Currently we seem to have a plethora of possible > > > > schemes on the table and people need to start putting down much > > clearer > > > > pros and cons for the schemes they support... So it could > > be good to > > > > have a similar "one page" email about a specific scheme that only > > uses > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > Toby > > > > > > ____________________________________________________________________ > > > > Toby Moncaster, Networks Research > > Centre, BT > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > -- > > > 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 > > http://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 01:24:51 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BBA28CA81; Thu, 21 Feb 2008 01:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 ljbyhuUNqusF; Thu, 21 Feb 2008 01:24:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7052B28CA09; Thu, 21 Feb 2008 01:24:50 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2087528CA6E for ; Thu, 21 Feb 2008 01:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI+9sWPLkr6x for ; Thu, 21 Feb 2008 01:24:44 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 3E44728C9B9 for ; Thu, 21 Feb 2008 01:24:44 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EBAB8A0684; Thu, 21 Feb 2008 10:24:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DDB64A067D; Thu, 21 Feb 2008 10:24:39 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B3426A0674; Thu, 21 Feb 2008 10:24:33 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1L9OXV00517; Thu, 21 Feb 2008 10:24:33 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 2EF68C7F16; Thu, 21 Feb 2008 10:24:25 +0100 (CET) Message-ID: <47BD4315.9040004@informatik.uni-wuerzburg.de> Date: Thu, 21 Feb 2008 10:23:33 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ingemar Johansson S References: <47BC05DA.7090701@informatik.uni-wuerzburg.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B4@E03MVZ1-UKDY.domain1.systemhost.net> <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, Ingemar Johansson S wrote: > Hi > > In this discussion it may be well worth the effort to consider the end > to end ECN usecases that we foresee when considering various PCN > encoding options. > Please have a look at > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > for a discussion of the use cases and a motivation to why end to end ECN > should be maintained even across PCN nodes even for non DF traffic. > I understand that ECN makes sense in all the use cases you mentioned in your draft. I would like to know 1. How important is it to use ECN also for PCN traffic 2. Although the use cases described in the draft make perfectly sense, is ECN really used for these purposes in practice, in particular for non-TCP traffic? What's its deployment? I see ECN as a feature to optimize TCP throughput, but it does not lead to a better service class. Correct me if I'm wrong! Regards, Michael > That said I realize that there is some cost associated to the use of > DSCP codepoints, this cost must however be weighted against the risk > that other functionality like end to end ECN semantics is probably > broken if a PCN encoding option "fiddles" with the ECN bits. It is easy > to see that if one wish to maintain support for end to end ECN (not only > in DF class) it simply costs more DSCP codepoints. > I am not explicitly saying don't do this or that but I wish to avoid a > situation where one technique has to be avoided in favor of the other as > it may in the end prevent deployment of both. If one can yank the two > together so much the better even though the cost e.g in DSCP code points > is regarded as higher. > > Regards > Ingemar > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of philip.eardley@bt.com >> Sent: den 20 februari 2008 17:44 >> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >> Cc: pcn@ietf.org; bob.briscoe@bt.com >> Subject: Re: [PCN] FW: RE: PCN encoding option >> >> Thanks Michael >> >> I agree with you that spending one DSCP value is quite >> expensive (not two, as one is spent anyway). I think the only >> way of really assessing this properly is for an alternative >> proposal (with pros and cons) that requires only one DSCP. >> Then we can see where the consensus for the best (/least bad) >> encoding lies. Personally I have no axe to grind for or >> against either - I'm not yet convinced that the proposal >> below is definitely the way to go, until compared it in >> detail with other proposals. >> >> So I think it would be really useful to have a "1 pager" for >> alternative >> proposal(s) before the ietf, as I think this would make >> Philadelphia discussions more productive. >> >> >> You're correct about one of the motivations (advantages) for >> this proposal (although I don't think the issues are exactly >> the same for 11 leakage as 01/10 leakage). >> >> Consider the case where 11 leaks out of the PCN domain. If >> the endpoints are ECN capable, then the ECN source slows down >> (seems reasonable). If they're not capable, then the impact >> outside the domain isn't any different to what would happen >> without PCN-domain. >> >> Consider the case where ECN-11 leaks into the PCN domain. >> Then this will lead to either flow admission or termination >> in the PCN-domain. These are both safe, in that the reaction >> is (I believe) at least as severe as would happen in an all >> ECN world. >> You mention that this might not terminate the ECN-11 flow >> specifically (some other flow might get terminated instead). >> I think this is true, though it also implies that [1] >> end-to-end ECN & PCN on the same flow really is useful, [2] >> the mechanism (eg tunnelling) to carry ECN-marking >> transparently across the PCN-domain has also failed, [3] the >> flows which are terminated aren't other ECN-11 flows that are >> also getting in due to the same misconfiguration. >> >> Best wishes >> Phil >> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>> Sent: 20 February 2008 10:50 >>> To: Moncaster,T,Toby,CXR9 R >>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; >>> babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; >>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>> Subject: Re: FW: RE: PCN encoding option >>> >>> Hi Toby, >>> >>> as I understand the proposal, the motivation is to avoid 01/10 >>> codepoints as it is not good if they leak out of the network since >>> >> 01/10 >> >>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>> >> However, there is >> >>> the same problem with 11 marking, i.e. 11-packets may not be dropped >>> >> by >> >>> ECN nodes outside the PCN domain although endpoints are not ECN >>> >> capable. >> >>> Even if 11-packets trigger flow termination, it is not >>> >> guaranteed that >> >>> exactly the marked flow going over an overloaded ECN node is >>> >> terminated. >> >>> Just want to say that this solution wants to solve a problem that >>> >> exists >> >>> only in case of misconfiguration (leaking packets), but >>> >> does not fully >> >>> achieve that objective. Therefore, I feel that spending two DSCP >>> >> values >> >>> is quite expensive. >>> >>> Regards, >>> >>> Michael >>> >>> toby.moncaster@bt.com wrote: >>> >>>> All, >>>> >>>> Phil and I have just been discussing the encoding draft >>>> >> and feel we >> may >> >>>> have lit upon a neat solution that seems to have lots of pros and >>>> >> few >> >>>> cons... In order to get a better feeling for this >>>> >> proposal I will go >> >>>> through the simplified version without Affected marking first: >>>> >>>> PCN Meaning ECN DSCP >>>> >>>> PCN capable 00 PCN 1 >>>> Admission Mark 11 PCN 1 >>>> Termination Mark 11/00 PCN 2 >>>> >>>> PCN 1 and PCN 2 are 2 different codepoints with the same PCN >>>> >> behaviour >> >>>> aggregate. >>>> >>>> Pros: >>>> o Termination marking and admission marking are independent, eg >>>> termination marking can be done after a packet has been admission >>>> marked. Therefore a router can write AM or TM without >>>> >> having to read >> the >> >>>> packet's PCN marking first, which is easier to implement. (Note: >>>> Over-writing a TM with AM is not allowed for 3SM & CL, see >>>> draft-charny-pcn-comparison.) >>>> >>>> o This scheme avoids giving semantics to ECT(0) and >>>> >> ECT(1). This is >> >>>> safest option if packets leak outside the PCN region, due to some >>>> >> fort >> >>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>> >> for a single >> >>>> domain deployment of PCN). >>>> >>>> o It leaves open the possibility of using ECT(0) and >>>> >> ECT(1) in some >> >>>> mysterious way in a future end-to-end PCN deployment >>>> >>>> o For a router to classify a packet as PCN, it simply reads its >>>> >> DSCP. >> >>>> This is probably easier than checking both its DSCP & ECN fields. >>>> >>>> o Incremental deployment steps are possible [1] could deploy SM >>>> initially and later AM/TM. Just add the second >>>> >> DSCP. >> >>>> If a router isn't upgraded at the same time nothing too horrific >>>> happens. >>>> [2] could just deploy admission control & add termination later, >>>> >> just by >> >>>> adding a new DSCP; there is no need to change the >>>> >> encoding and check >> for >> >>>> backwards compatibility? Vice-versa is also ok? >>>> >>>> Cons: >>>> o It needs an extra DSCP, per PCN behaviour aggregate. (Although >>>> possibly it's OK to use the same DSCP for TM for all PCN BAs?) >>>> >>>> o If a packet (in a PCN flow) arrives at the egress with >>>> >> its ECN = >> 11 >> >>>> and it really is required to preserve this info across the >>>> >> PCN-domain, >> >>>> then some complexity is needed at the PCN-boundary-nodes >>>> >> (tunnelling) >> >>>> o If the PCN-domain is operating multipath routing >>>> >> (ECMP) that uses >> the >> >>>> DSCP to select routes, then there may be mis-ordering of packets >>>> >> within >> >>>> a flow. This may be OK as (1) no-one has yet said they know of an >>>> >> ECMP >> >>>> algorithm that in practie uses the DSCP; (2) a risk of >>>> >> mis-ordering >> when >> >>>> there is termination marking may be acceptable >>>> >>>> If Affected marking is needed then the scheme can be modified as >>>> follows: >>>> >>>> PCN Meaning ECN DSCP >>>> >>>> PCN capable 00 PCN 1 >>>> Admission Mark 11 PCN 1 >>>> Termination Mark 11 PCN 2 >>>> Affected Mark 00 PCN 2 >>>> >>>> The pros for this scheme are broadly similar to the above. However >>>> >> there >> >>>> is a new con which may or may not matter: If a packet is affected >>>> >> marked >> >>>> and a later node is doing admission marking then it will >>>> >> reset the >> >>>> affected mark to a termination mark. Work would be needed >>>> >> to see if >> this >> >>>> skews the results and causes significant over-termination or not. >>>> >>>> Please could people look through this scheme and highlight any >>>> additional concerns that they may have (and extra benefits too). I >>>> >> would >> >>>> like to get as many opinions as possible. >>>> >>>> What I want to avoid is people just emailing back with >>>> >> "why not try >> this >> >>>> scheme instead". Currently we seem to have a plethora of possible >>>> schemes on the table and people need to start putting down much >>>> >> clearer >> >>>> pros and cons for the schemes they support... So it could >>>> >> be good to >> >>>> have a similar "one page" email about a specific scheme that only >>>> >> uses >> >>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>> >>>> Toby >>>> >>>> >> ____________________________________________________________________ >> >>>> Toby Moncaster, Networks Research >>>> >> Centre, BT >> >>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 >>>> >>>> >>> -- >>> 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 >> http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 01:38:29 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67ACD28CA6C; Thu, 21 Feb 2008 01:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Df5dGm1+wV12; Thu, 21 Feb 2008 01:38:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD9528CA3F; Thu, 21 Feb 2008 01:38:28 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97D928CA3F for ; Thu, 21 Feb 2008 01:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OArpXLYByP3Z for ; Thu, 21 Feb 2008 01:38:27 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id AB24028CA2D for ; Thu, 21 Feb 2008 01:38:25 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 09:38:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 09:38:20 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47BC679D.7090504@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: RE: PCN encoding option Thread-Index: Achz6Mp56ntrQWuuS8C31eqJ6I39qgAhANUw From: To: X-OriginalArrivalTime: 21 Feb 2008 09:38:21.0448 (UTC) FILETIME=[7F34C080:01C8746D] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > > > Consider the case where 11 leaks out of the PCN domain. If the endpoints > > are ECN capable, then the ECN source slows down (seems reasonable). If > > they're not capable, then the impact outside the domain isn't any > > different to what would happen without PCN-domain. > > > > No, there is a difference. 11-marked packets are not dropped when > congestion occurs and if the endpoints are not ECN-capable, they don't > backoff. That's the problem. That's why I say the solution is not fully > sound. > this is what I was trying to get at: assuming the ends aren't ECN-capable: (without PCN & with some ECN router marking 11) then the ends don't react to 11 (with PCN marking 11 & such a pkt leaking out of the PCN-domain ) then the ends don't react to 11 no difference? phil _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 02:02:38 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0CA28CA46; Thu, 21 Feb 2008 02:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 AesUnLsqTQ2M; Thu, 21 Feb 2008 02:02:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D6128CA5E; Thu, 21 Feb 2008 02:01:45 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB5628CA5E for ; Thu, 21 Feb 2008 02:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFQvS1puFDD9 for ; Thu, 21 Feb 2008 02:01:43 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6C87F28CA56 for ; Thu, 21 Feb 2008 02:01:43 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B5D11A067B; Thu, 21 Feb 2008 11:01:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A6062A0673; Thu, 21 Feb 2008 11:01:39 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 733DCA0653; Thu, 21 Feb 2008 11:01:30 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1LA1UV01023; Thu, 21 Feb 2008 11:01:30 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D876FC7F16; Thu, 21 Feb 2008 11:01:29 +0100 (CET) Message-ID: <47BD4BBE.8070102@informatik.uni-wuerzburg.de> Date: Thu, 21 Feb 2008 11:00:30 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B7@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: >>> Consider the case where 11 leaks out of the PCN domain. If the >>> > endpoints > >>> are ECN capable, then the ECN source slows down (seems reasonable). >>> > If > >>> they're not capable, then the impact outside the domain isn't any >>> different to what would happen without PCN-domain. >>> >>> >> No, there is a difference. 11-marked packets are not dropped when >> congestion occurs and if the endpoints are not ECN-capable, they don't >> backoff. That's the problem. That's why I say the solution is not >> > fully > >> sound. >> >> > this is what I was trying to get at: > > assuming the ends aren't ECN-capable: > (without PCN & with some ECN router marking 11) then the ends don't > react to 11 > (with PCN marking 11 & such a pkt leaking out of the PCN-domain ) then > the ends don't react to 11 > > no difference? > Ok, let me clarify what I mean. Yes, it's true that end nodes never react to 11-marked packets. The difference is: non-PCN packets have no reason to be remarked to 11 within a PCN domain and therefore, they cannot leak out of the domain with 11-marking which is different for PCN packets. So the problem arises only for PCN traffic but not for non-PCN traffic. Regards, Michael > phil > -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 02:08:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF7928CA8C; Thu, 21 Feb 2008 02:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.629 X-Spam-Level: X-Spam-Status: No, score=0.629 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 VXh44opIxdcK; Thu, 21 Feb 2008 02:08:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF6028CA86; Thu, 21 Feb 2008 02:08:21 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFD628CAA0 for ; Thu, 21 Feb 2008 02:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01GBx6hZ7Ssg for ; Thu, 21 Feb 2008 02:08:17 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 5709928CA26 for ; Thu, 21 Feb 2008 02:08:00 -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 m1LA6xiu000037; Thu, 21 Feb 2008 11:07:02 +0100 (MET) From: "Georgios Karagiannis" To: , References: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B6@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 21 Feb 2008 11:06:57 +0100 Message-ID: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B6@E03MVZ1-UKDY.domain1.systemhost.net> thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHw 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, 21 Feb 2008 11:07:04 +0100 (MET) Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, Hi all In order to make a selection of one single (or two) options, I think that the PCN WG should get the possibility to study all the possible and PCN relevant encoding options. In my opinion the goal of the encoding draft is to provide this information to the PCN-WG. Based on this information the PCN WG can discuss and decide which of the options should be used. The below text is copied from the current version of the encoding draft! Four options are described! Please note that the encoding draft should list all relevant options with advantages and disadvantages. Phil and Ingemar, if you can add advantages, disadvantages to the ones already mentioned below in Section 3.2.1 and 3.2.2 of the encoding draft, please do. Best regards, Georgios 3.2. Encoding Using DSCP Field In this type of encoding and transport method the congestion and precongestion information is encoded into the 6 DSCP bits that are transported in the IP header of the data packets. Four possible alternatives can be distinguished, as can be seen in Figure 3, with details provided by draft-westberg-pcn-load-control-02.txt [4]. Option 7 needs 2 additional DSCP values, Options 8 and 9 need three additional DSCP values and Option 10 needs four additional DSCP values. Note that all additional and experimental DSCP values are representing and are associated with the same PHB. The 1st, 2nd, 3rd, and 4th DSCP values are representing DSCP values that are assigned by IANA as DSCP experimental values, see RFC 2211 [9]. ----------------------------------------------------------------------- | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 | |===========++==========+===========+===========+===========+===========| | Option 6 || Not-PCN | PCN | AM/TM | NA | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 7 || Not-PCN | PCN | AM/TM | AfM | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 8 || Not-PCN | PCN | AM | TM | NA | |-----------++----------+-----------+-----------+-----------+-----------| | Option 9 || Not-PCN | PCN | AM | TM | AfM | ----------------------------------------------------------------------- Notes: Not-PCN means the packet is not PCN capable. Figure 2: Encoding of PCN Information Using DSCP Field 3.2.1. Benefits of Using DSCP Field The main benefit of using the DSCP field is that it is not affecting the end-to-end ECN semantics and therefore the issues and concerns raised in RFC 4774 [22] are not applicable for this encoding scheme. Another benefit is related to the fact that all 4 DSCP encoding options depicted in Figure 2 can support the PCN capable not congested (PCN) indication, the admission control (AM) and flow termination (TM) encoding states. In addition Option 8 and 10 can support the ECMP solution. 3.2.2. Drawbacks of Using DSCP Field This type of encoding needs to use per PHB, in addition to the original DSCP and depending on the encoding option used, one, two, three, or four DSCP values, respectively. These additional DSCP values can be taken from the DSCP values that are not defined by standards action, see RFC 2211 [9]. Note that all the additional DSCP values are representing and are associated with one PHB. The value of this DSCP/PHB can either follow a standards action or use a value that is applied for experimental or local use. It is important to note that the number of the DSCP values used for local or experimental use is restricted and therefore the number of different PHBs supported in the PCN domain will also be restricted. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: donderdag 21 februari 2008 10:24 > To: ingemar.s.johansson@ericsson.com; > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > Cc: pcn@ietf.org; bob.briscoe@bt.com > Subject: Re: [PCN] FW: RE: PCN encoding option > > Ingemar > > Re > > > consider the end to end ECN usecases > > I believe that the emails below about Toby's encoding > proposal do indeed already consider ECN. Would appreciate it > if you could add further text to it to better capture the > (pros and) cons. > > > more DSCP codepoints > I think you may be proposing an encoding that uses all dscp > codepoints (as has Georgios). That's fine - but a "1 pager" > setting out this option with its pros and cons (ie similar to > what toby has done below) is needed I think! At the moment we > have lots of options on the table - in order to reach a > decision, I think we really need very few options but with > their pros and cons better laid out. > > > I haven't managed to get to your draft yet, sorry (next week > hopefully) > - > Thanks > Phil > > > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: 21 February 2008 06:43 > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > Moncaster,T,Toby,CXR9 R > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > Hi > > > > In this discussion it may be well worth the effort to > consider the end > > to end ECN usecases that we foresee when considering various PCN > > encoding options. > > Please have a look at > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > for a discussion of the use cases and a motivation to why end to end > ECN > > should be maintained even across PCN nodes even for non DF traffic. > > That said I realize that there is some cost associated to > the use of > > DSCP codepoints, this cost must however be weighted against > the risk > > that other functionality like end to end ECN semantics is probably > > broken if a PCN encoding option "fiddles" with the ECN bits. It is > easy > > to see that if one wish to maintain support for end to end ECN (not > only > > in DF class) it simply costs more DSCP codepoints. > > I am not explicitly saying don't do this or that but I wish > to avoid a > > situation where one technique has to be avoided in favor of > the other > as > > it may in the end prevent deployment of both. If one can > yank the two > > together so much the better even though the cost e.g in DSCP code > points > > is regarded as higher. > > > > Regards > > Ingemar > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > > > Of philip.eardley@bt.com > > > Sent: den 20 februari 2008 17:44 > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > Thanks Michael > > > > > > I agree with you that spending one DSCP value is quite expensive > > > (not two, as one is spent anyway). I think the only way of really > > > assessing this properly is for an alternative proposal (with pros > > > and cons) that requires only one DSCP. > > > Then we can see where the consensus for the best (/least bad) > > > encoding lies. Personally I have no axe to grind for or against > > > either - I'm not yet convinced that the proposal below is > definitely > > > the way to go, until compared it in detail with other proposals. > > > > > > So I think it would be really useful to have a "1 pager" for > > > alternative > > > proposal(s) before the ietf, as I think this would make > Philadelphia > > > discussions more productive. > > > > > > > > > You're correct about one of the motivations (advantages) for this > > > proposal (although I don't think the issues are exactly > the same for > > > 11 leakage as 01/10 leakage). > > > > > > Consider the case where 11 leaks out of the PCN domain. If the > > > endpoints are ECN capable, then the ECN source slows down (seems > > > reasonable). If they're not capable, then the impact outside the > > > domain isn't any different to what would happen without > PCN-domain. > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > Then this will lead to either flow admission or > termination in the > > > PCN-domain. These are both safe, in that the reaction is > (I believe) > > > at least as severe as would happen in an all ECN world. > > > You mention that this might not terminate the ECN-11 flow > > > specifically (some other flow might get terminated instead). > > > I think this is true, though it also implies that [1] > end-to-end ECN > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > tunnelling) to carry ECN-marking transparently across the > PCN-domain > > > has also failed, [3] the flows which are terminated aren't other > > > ECN-11 flows that are also getting in due to the same > > > misconfiguration. > > > > > > Best wishes > > > Phil > > > > -----Original Message----- > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > Sent: 20 February 2008 10:50 > > > > To: Moncaster,T,Toby,CXR9 R > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > > > > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > Hi Toby, > > > > > > > > as I understand the proposal, the motivation is to avoid 01/10 > > > > codepoints as it is not good if they leak out of the > network since > > > 01/10 > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > However, there is > > > > the same problem with 11 marking, i.e. 11-packets may not be > dropped > > > by > > > > ECN nodes outside the PCN domain although endpoints are not ECN > > > capable. > > > > Even if 11-packets trigger flow termination, it is not > > > guaranteed that > > > > exactly the marked flow going over an overloaded ECN node is > > > terminated. > > > > Just want to say that this solution wants to solve a > problem that > > > exists > > > > only in case of misconfiguration (leaking packets), but > > > does not fully > > > > achieve that objective. Therefore, I feel that spending two DSCP > > > values > > > > is quite expensive. > > > > > > > > Regards, > > > > > > > > Michael > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > All, > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > and feel we > > > may > > > > > have lit upon a neat solution that seems to have lots of pros > and > > > few > > > > > cons... In order to get a better feeling for this > > > proposal I will go > > > > > through the simplified version without Affected marking first: > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > PCN capable 00 PCN 1 > > > > > Admission Mark 11 PCN 1 > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > > > behaviour > > > > > aggregate. > > > > > > > > > > Pros: > > > > > o Termination marking and admission marking are independent, > eg > > > > > termination marking can be done after a packet has been > admission > > > > > marked. Therefore a router can write AM or TM without > > > having to read > > > the > > > > > packet's PCN marking first, which is easier to > implement. (Note: > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > ECT(1). This is > > > > > safest option if packets leak outside the PCN region, due to > some > > > fort > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > for a single > > > > > domain deployment of PCN). > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > ECT(1) in some > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > o For a router to classify a packet as PCN, it > simply reads its > > > DSCP. > > > > > This is probably easier than checking both its DSCP & ECN > fields. > > > > > > > > > > o Incremental deployment steps are possible [1] > could deploy SM > > > > > initially and later AM/TM. Just add the second > > > DSCP. > > > > > If a router isn't upgraded at the same time nothing > too horrific > > > > > happens. > > > > > [2] could just deploy admission control & add > termination later, > > > just by > > > > > adding a new DSCP; there is no need to change the > > > encoding and check > > > for > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > Cons: > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > (Although > > > > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > its ECN = > > > 11 > > > > > and it really is required to preserve this info across the > > > PCN-domain, > > > > > then some complexity is needed at the PCN-boundary-nodes > > > (tunnelling) > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > (ECMP) that uses > > > the > > > > > DSCP to select routes, then there may be mis-ordering > of packets > > > within > > > > > a flow. This may be OK as (1) no-one has yet said they know of > an > > > ECMP > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > mis-ordering > > > when > > > > > there is termination marking may be acceptable > > > > > > > > > > If Affected marking is needed then the scheme can be > modified as > > > > > follows: > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > PCN capable 00 PCN 1 > > > > > Admission Mark 11 PCN 1 > > > > > Termination Mark 11 PCN 2 > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > The pros for this scheme are broadly similar to the above. > However > > > there > > > > > is a new con which may or may not matter: If a packet is > affected > > > marked > > > > > and a later node is doing admission marking then it will > > > reset the > > > > > affected mark to a termination mark. Work would be needed > > > to see if > > > this > > > > > skews the results and causes significant over-termination or > not. > > > > > > > > > > Please could people look through this scheme and > highlight any > > > > > additional concerns that they may have (and extra > benefits too). > I > > > would > > > > > like to get as many opinions as possible. > > > > > > > > > > What I want to avoid is people just emailing back with > > > "why not try > > > this > > > > > scheme instead". Currently we seem to have a plethora of > possible > > > > > schemes on the table and people need to start putting > down much > > > clearer > > > > > pros and cons for the schemes they support... So it could > > > be good to > > > > > have a similar "one page" email about a specific scheme that > only > > > uses > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > Toby > > > > > > > > > ____________________________________________________________________ > > > > > Toby Moncaster, Networks Research > > > Centre, BT > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > > > > -- > > > > 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 > > > http://www.ietf.org/mailman/listinfo/pcn > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 02:50:33 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E534928C6B7; Thu, 21 Feb 2008 02:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 KWv8YFV2vnmf; Thu, 21 Feb 2008 02:50:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0803A6C2E; Thu, 21 Feb 2008 02:50:32 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A6128C518 for ; Thu, 21 Feb 2008 02:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2VQOyjR-mDo for ; Thu, 21 Feb 2008 02:50:22 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 8190F3A695C for ; Thu, 21 Feb 2008 02:50:21 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:50:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 10:50:29 -0000 Message-ID: In-Reply-To: <47BD4BBE.8070102@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: RE: PCN encoding option thread-index: Ach0cMKtKd+ho3HyTNyywPSvSzHzdwAAd1Jg From: To: , X-OriginalArrivalTime: 21 Feb 2008 10:50:16.0541 (UTC) FILETIME=[8B33B0D0:01C87477] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Possible bad things that can happen: 1) 11 packets leak into PCN region through a misconfigured router that fails to tunnel them. With the proposed coding these will be treated at the egress as an indication of admission marking. However it is reasonably safe for the egress router to just let them out with the marking unchanged (see point 2 below). This is because at a conceptual level the PCN region can simply be seen as a non-ECN router on an ECN path (must be an ECN path for 11 to enter the region in the first place). Passing the mark on ensures it reaches the end destination although the presence of the mark may have marginally affected the measurement of that aggregate within the PCN region. 2) Packets marked 11 by the PCN region leaking out. If the packets are part of an ECN flow (which still seems very weird to me - ECN being designed for elastic traffic and PCN being designed for inelastic), then the packet would have carried 10 or 01 at the ingress and thus should have been tunnelled in some fashion. If this didn't happen through some misconfiguration then the receiver will see this as an indication of congestion and respond accordingly. This will indeed result in PCN traffic receiving "worse" treatment than non-PCN traffic following the same path, however as the reason for marking was to indicate pre-congestion and as the PCN region is principally concerned with providing a guaranteed level of service to traffic this may not matter. Once someone gives a really convincing explanation of why you would use ECN on a flow that is traversing a PCN region I will accept that we need to worry about this... My view is that it is nearly impossible to adequately address all the corner cases where there is some mis-configuration of the PCN region. All that is necessary is to document them and show that they have been adequately considered. At the end of the day there is every chance of misconfigured routers doing strange things anyway and that is just as true for DSCPs as for ECN. The really key thing to consider is do we care about letting packets we have marked 11 leak from the PCN region or should we re-set them to 00? If they are not ECN packets then the only detrimental affects of this are that ECN routers think they are ECN and can't use them to indicate congestion and misconfigured receivers may think these were part of an ECN flow. If we decide to reset them then concern 1) above does matter. One final thought - ECN is designed with inbuilt protection - ultimately if a router is congested it will revert to dropping packets. If this weren't so then there would be an enormous DoS vulnerability from just sending all packets with 11 already set... Toby NB very relevant text in section 8 of RFC3168: "The first two possible changes, falsely reporting congestion or disabling ECN-Capability for an individual packet, are no worse than if the router were to simply drop the packet. From a congestion control point of view, setting the CE codepoint in the absence of congestion by a non-compliant router would be no worse than a router dropping a packet unnecessarily. By "erasing" an ECT codepoint of a packet that is later dropped in the network, a router's actions could result in an unnecessary packet drop for that packet later in the network. However, as discussed in Section 18, a router that erases the ECN congestion indication or falsely indicates ECN-Capability could potentially do more damage to the flow that if it has simply dropped the packet. A rogue or broken router that "erased" the CE codepoint in arriving CE packets would prevent that indication of congestion from reaching downstream receivers. This could result in the failure of congestion control for that flow and a resulting increase in congestion in the network, ultimately resulting in subsequent packets dropped for this flow as the average queue size increased at the congested gateway." > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 21 February 2008 10:01 > To: Eardley,PL,Philip,CXR9 R > Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org; khchan@nortel.com; > babiarz@nortel.com; sob@harvard.edu; > steven.blake@ericsson.com; karagian@cs.utwente.nl; > Briscoe,RJ,Bob,CXR9 R > Subject: Re: FW: RE: PCN encoding option > > Hi Phil, > > philip.eardley@bt.com wrote: > >>> Consider the case where 11 leaks out of the PCN domain. If the > >>> > > endpoints > > > >>> are ECN capable, then the ECN source slows down (seems > reasonable). > >>> > > If > > > >>> they're not capable, then the impact outside the domain isn't any > >>> different to what would happen without PCN-domain. > >>> > >>> > >> No, there is a difference. 11-marked packets are not dropped when > >> congestion occurs and if the endpoints are not > ECN-capable, they don't > >> backoff. That's the problem. That's why I say the solution is not > >> > > fully > > > >> sound. > >> > >> > > this is what I was trying to get at: > > > > assuming the ends aren't ECN-capable: > > (without PCN & with some ECN router marking 11) then the ends don't > > react to 11 > > (with PCN marking 11 & such a pkt leaking out of the > PCN-domain ) then > > the ends don't react to 11 > > > > no difference? > > > Ok, let me clarify what I mean. Yes, it's true that end nodes never > react to 11-marked packets. The difference is: non-PCN > packets have no > reason to be remarked to 11 within a PCN domain and therefore, they > cannot leak out of the domain with 11-marking which is > different for PCN > packets. So the problem arises only for PCN traffic but not > for non-PCN > traffic. > > Regards, > > Michael > > > phil > > > > -- > 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 04:50:18 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B40728C7CC; Thu, 21 Feb 2008 04:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 bSoZMRiHZteJ; Thu, 21 Feb 2008 04:50:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCDB28C6C5; Thu, 21 Feb 2008 04:50:16 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5DD28C79D for ; Thu, 21 Feb 2008 04:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkx8ll1R9bNC for ; Thu, 21 Feb 2008 04:50:13 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D541C28C1F7 for ; Thu, 21 Feb 2008 04:50:11 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 12:50:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 12:50:06 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B9@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RA= From: To: , X-OriginalArrivalTime: 21 Feb 2008 12:50:07.0358 (UTC) FILETIME=[494349E0:01C87488] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Thanks for pointing at this. luckily your proposal is really one option (and not the daunting 4) - this would also enable your text to be shortened. I raised several suggestions & comments with this text, on the previous version of this draft round about the last ietf. http://www.ietf.org/mail-archive/web/pcn/current/msg00909.html . This had comments on the whole draft, some of which still apply, including these on your text below: ------ extract from email of 20 nov ------------ "In addition Option 8 and 10 can in addition support the ECMP solution." Replace: "They support Affected marking, which [ref] says has benefits if the PCN-domain operates ECMP multi-path routing" additional benefit (and in my view the most significant): exptal dscps are lightly standardised - limited rules on how you use them, largely up to the operator. 3.3.2 Drawbacks ... Clarify that particular issue for mpls [codepoint shortage] ... Major disadvantage: interactions with ECMP. ECMP algos can use a packet's DSCP when deciding what interface to fwd it on. In a PCN-domain running ECMP, for a flow which has some packets PCN-marked and some unmarked. its packets will travel over more than one path. This may well lead to mis-ordering. To me, this means that the S3.3 DSCP option is a non-starter in any PCN-domain that uses an ECMP algorithm that uses the DSCP. NB ECMP algos are proprietary to router vendors, ie operator has poor control over them. ------- end of extract ------ in addition: reading toby's email there are some additional points to raise: 1. extra con: router has to read the existing marking before writing (otherwise AM can over-write TM) 2. given Toby's option has some thoughts about what happens in the event that the PCN-boundary-nodes are misconfigured (and let 11 pkts sneak in or out), I think it would also be fair for your option to have some thinking about what happens if PCN-boundary-node misconfiguration allows a "PCN DSCP" to sneak in /out. Phil. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 21 February 2008 10:07 > To: Eardley,PL,Philip,CXR9 R; ingemar.s.johansson@ericsson.com > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni- > wuerzburg.de; Moncaster,T,Toby,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > > Hi Phil, Hi all > > In order to make a selection of one single (or two) options, I think that > the PCN WG should get the possibility to study all the possible and PCN > relevant encoding options. > > In my opinion the goal of the encoding draft is to provide this > information > to the PCN-WG. > Based on this information the PCN WG can discuss and decide which of the > options should be used. > > The below text is copied from the current version of the encoding draft! > Four options are described! > Please note that the encoding draft should list all relevant options with > advantages and disadvantages. > > Phil and Ingemar, if you can add advantages, disadvantages to the > ones already mentioned below in Section 3.2.1 and 3.2.2 of the encoding > draft, please do. > > Best regards, > Georgios > > > > 3.2. Encoding Using DSCP Field > > In this type of encoding and transport method the congestion and > precongestion information is encoded into the 6 DSCP bits that are > transported in the IP header of the data packets. Four possible > alternatives can be distinguished, as can be seen in Figure 3, with > details provided by draft-westberg-pcn-load-control-02.txt [4]. > Option 7 needs 2 additional DSCP values, Options 8 and 9 need three > additional DSCP values and Option 10 needs four additional DSCP > values. Note that all additional and experimental DSCP values are > representing and are associated with the same PHB. The 1st, 2nd, > 3rd, and 4th DSCP values are representing DSCP values that are > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > ----------------------------------------------------------------------- > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 | > |===========++==========+===========+===========+===========+=========== | > | Option 6 || Not-PCN | PCN | AM/TM | NA | NA | > |-----------++----------+-----------+-----------+-----------+----------- | > | Option 7 || Not-PCN | PCN | AM/TM | AfM | NA | > |-----------++----------+-----------+-----------+-----------+----------- | > | Option 8 || Not-PCN | PCN | AM | TM | NA | > |-----------++----------+-----------+-----------+-----------+----------- | > | Option 9 || Not-PCN | PCN | AM | TM | AfM | > ----------------------------------------------------------------------- > > Notes: Not-PCN means the packet is not PCN capable. > > Figure 2: Encoding of PCN Information Using DSCP Field > > 3.2.1. Benefits of Using DSCP Field > > The main benefit of using the DSCP field is that it is not affecting > the end-to-end ECN semantics and therefore the issues and concerns > raised in RFC 4774 [22] are not applicable for this encoding scheme. > Another benefit is related to the fact that all 4 DSCP encoding > options depicted in Figure 2 can support the PCN capable not > congested (PCN) indication, the admission control (AM) and flow > termination (TM) encoding states. In addition Option 8 and 10 can > support the ECMP solution. > > 3.2.2. Drawbacks of Using DSCP Field > > This type of encoding needs to use per PHB, in addition to the > original DSCP and depending on the encoding option used, one, two, > three, or four DSCP values, respectively. These additional DSCP > values can be taken from the DSCP values that are not defined by > standards action, see RFC 2211 [9]. Note that all the additional > DSCP values are representing and are associated with one PHB. The > value of this DSCP/PHB can either follow a standards action or use a > value that is applied for experimental or local use. It is important > to note that the number of the DSCP values used for local or > experimental use is restricted and therefore the number of different > PHBs supported in the PCN domain will also be restricted. > > Best regards, > Georgios > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of philip.eardley@bt.com > > Sent: donderdag 21 februari 2008 10:24 > > To: ingemar.s.johansson@ericsson.com; > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > Ingemar > > > > Re > > > > > consider the end to end ECN usecases > > > > I believe that the emails below about Toby's encoding > > proposal do indeed already consider ECN. Would appreciate it > > if you could add further text to it to better capture the > > (pros and) cons. > > > > > more DSCP codepoints > > I think you may be proposing an encoding that uses all dscp > > codepoints (as has Georgios). That's fine - but a "1 pager" > > setting out this option with its pros and cons (ie similar to > > what toby has done below) is needed I think! At the moment we > > have lots of options on the table - in order to reach a > > decision, I think we really need very few options but with > > their pros and cons better laid out. > > > > > > I haven't managed to get to your draft yet, sorry (next week > > hopefully) > > - > > Thanks > > Phil > > > > > > > -----Original Message----- > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > > Sent: 21 February 2008 06:43 > > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > > Moncaster,T,Toby,CXR9 R > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > Hi > > > > > > In this discussion it may be well worth the effort to > > consider the end > > > to end ECN usecases that we foresee when considering various PCN > > > encoding options. > > > Please have a look at > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > for a discussion of the use cases and a motivation to why end to end > > ECN > > > should be maintained even across PCN nodes even for non DF traffic. > > > That said I realize that there is some cost associated to > > the use of > > > DSCP codepoints, this cost must however be weighted against > > the risk > > > that other functionality like end to end ECN semantics is probably > > > broken if a PCN encoding option "fiddles" with the ECN bits. It is > > easy > > > to see that if one wish to maintain support for end to end ECN (not > > only > > > in DF class) it simply costs more DSCP codepoints. > > > I am not explicitly saying don't do this or that but I wish > > to avoid a > > > situation where one technique has to be avoided in favor of > > the other > > as > > > it may in the end prevent deployment of both. If one can > > yank the two > > > together so much the better even though the cost e.g in DSCP code > > points > > > is regarded as higher. > > > > > > Regards > > > Ingemar > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > On Behalf > > > > Of philip.eardley@bt.com > > > > Sent: den 20 februari 2008 17:44 > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > Thanks Michael > > > > > > > > I agree with you that spending one DSCP value is quite expensive > > > > (not two, as one is spent anyway). I think the only way of really > > > > assessing this properly is for an alternative proposal (with pros > > > > and cons) that requires only one DSCP. > > > > Then we can see where the consensus for the best (/least bad) > > > > encoding lies. Personally I have no axe to grind for or against > > > > either - I'm not yet convinced that the proposal below is > > definitely > > > > the way to go, until compared it in detail with other proposals. > > > > > > > > So I think it would be really useful to have a "1 pager" for > > > > alternative > > > > proposal(s) before the ietf, as I think this would make > > Philadelphia > > > > discussions more productive. > > > > > > > > > > > > You're correct about one of the motivations (advantages) for this > > > > proposal (although I don't think the issues are exactly > > the same for > > > > 11 leakage as 01/10 leakage). > > > > > > > > Consider the case where 11 leaks out of the PCN domain. If the > > > > endpoints are ECN capable, then the ECN source slows down (seems > > > > reasonable). If they're not capable, then the impact outside the > > > > domain isn't any different to what would happen without > > PCN-domain. > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > Then this will lead to either flow admission or > > termination in the > > > > PCN-domain. These are both safe, in that the reaction is > > (I believe) > > > > at least as severe as would happen in an all ECN world. > > > > You mention that this might not terminate the ECN-11 flow > > > > specifically (some other flow might get terminated instead). > > > > I think this is true, though it also implies that [1] > > end-to-end ECN > > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > > tunnelling) to carry ECN-marking transparently across the > > PCN-domain > > > > has also failed, [3] the flows which are terminated aren't other > > > > ECN-11 flows that are also getting in due to the same > > > > misconfiguration. > > > > > > > > Best wishes > > > > Phil > > > > > -----Original Message----- > > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > > Sent: 20 February 2008 10:50 > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; khchan@nortel.com; > > > > > babiarz@nortel.com; sob@harvard.edu; steven.blake@ericsson.com; > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > Hi Toby, > > > > > > > > > > as I understand the proposal, the motivation is to avoid 01/10 > > > > > codepoints as it is not good if they leak out of the > > network since > > > > 01/10 > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > However, there is > > > > > the same problem with 11 marking, i.e. 11-packets may not be > > dropped > > > > by > > > > > ECN nodes outside the PCN domain although endpoints are not ECN > > > > capable. > > > > > Even if 11-packets trigger flow termination, it is not > > > > guaranteed that > > > > > exactly the marked flow going over an overloaded ECN node is > > > > terminated. > > > > > Just want to say that this solution wants to solve a > > problem that > > > > exists > > > > > only in case of misconfiguration (leaking packets), but > > > > does not fully > > > > > achieve that objective. Therefore, I feel that spending two DSCP > > > > values > > > > > is quite expensive. > > > > > > > > > > Regards, > > > > > > > > > > Michael > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > All, > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > and feel we > > > > may > > > > > > have lit upon a neat solution that seems to have lots of pros > > and > > > > few > > > > > > cons... In order to get a better feeling for this > > > > proposal I will go > > > > > > through the simplified version without Affected marking first: > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > Admission Mark 11 PCN 1 > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > > > > behaviour > > > > > > aggregate. > > > > > > > > > > > > Pros: > > > > > > o Termination marking and admission marking are independent, > > eg > > > > > > termination marking can be done after a packet has been > > admission > > > > > > marked. Therefore a router can write AM or TM without > > > > having to read > > > > the > > > > > > packet's PCN marking first, which is easier to > > implement. (Note: > > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > ECT(1). This is > > > > > > safest option if packets leak outside the PCN region, due to > > some > > > > fort > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > for a single > > > > > > domain deployment of PCN). > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > ECT(1) in some > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > simply reads its > > > > DSCP. > > > > > > This is probably easier than checking both its DSCP & ECN > > fields. > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > could deploy SM > > > > > > initially and later AM/TM. Just add the second > > > > DSCP. > > > > > > If a router isn't upgraded at the same time nothing > > too horrific > > > > > > happens. > > > > > > [2] could just deploy admission control & add > > termination later, > > > > just by > > > > > > adding a new DSCP; there is no need to change the > > > > encoding and check > > > > for > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > Cons: > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > (Although > > > > > > possibly it's OK to use the same DSCP for TM for all PCN BAs?) > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > > its ECN = > > > > 11 > > > > > > and it really is required to preserve this info across the > > > > PCN-domain, > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > (tunnelling) > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > (ECMP) that uses > > > > the > > > > > > DSCP to select routes, then there may be mis-ordering > > of packets > > > > within > > > > > > a flow. This may be OK as (1) no-one has yet said they know of > > an > > > > ECMP > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > mis-ordering > > > > when > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > modified as > > > > > > follows: > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > Admission Mark 11 PCN 1 > > > > > > Termination Mark 11 PCN 2 > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > The pros for this scheme are broadly similar to the above. > > However > > > > there > > > > > > is a new con which may or may not matter: If a packet is > > affected > > > > marked > > > > > > and a later node is doing admission marking then it will > > > > reset the > > > > > > affected mark to a termination mark. Work would be needed > > > > to see if > > > > this > > > > > > skews the results and causes significant over-termination or > > not. > > > > > > > > > > > > Please could people look through this scheme and > > highlight any > > > > > > additional concerns that they may have (and extra > > benefits too). > > I > > > > would > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > "why not try > > > > this > > > > > > scheme instead". Currently we seem to have a plethora of > > possible > > > > > > schemes on the table and people need to start putting > > down much > > > > clearer > > > > > > pros and cons for the schemes they support... So it could > > > > be good to > > > > > > have a similar "one page" email about a specific scheme that > > only > > > > uses > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > Toby > > > > > > > > > > > > ____________________________________________________________________ > > > > > > Toby Moncaster, Networks Research > > > > Centre, BT > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 05:46:26 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446EE28C9FB; Thu, 21 Feb 2008 05:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.658 X-Spam-Level: X-Spam-Status: No, score=0.658 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 Pd2aUzKmYS6T; Thu, 21 Feb 2008 05:46:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21AF28C97F; Thu, 21 Feb 2008 05:46:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C1928C7CD for ; Thu, 21 Feb 2008 05:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGFBr1zPEIiy for ; Thu, 21 Feb 2008 05:46:12 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 5084828C56A for ; Thu, 21 Feb 2008 05:46:12 -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 m1LDjLIZ015027; Thu, 21 Feb 2008 14:45:39 +0100 (MET) From: "Georgios Karagiannis" To: , References: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B9@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 21 Feb 2008 14:45:16 +0100 Message-ID: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345B9@E03MVZ1-UKDY.domain1.systemhost.net> thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUA== 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, 21 Feb 2008 14:45:41 +0100 (MET) Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Thank you very much! Please see in line! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 21 februari 2008 13:50 > To: karagian@cs.utwente.nl; ingemar.s.johansson@ericsson.com > Cc: pcn@ietf.org; bob.briscoe@bt.com; > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > Subject: RE: [PCN] FW: RE: PCN encoding option > > Thanks for pointing at this. luckily your proposal is really > one option (and not the daunting 4) - this would also enable > your text to be shortened. Georgios: I think that they are 4! Later on the PCN-WG will make a slection of one of the 4! > > I raised several suggestions & comments with this text, on > the previous version of this draft round about the last ietf. > http://www.ietf.org/mail-archive/web/pcn/current/msg00909.html . > > This had comments on the whole draft, some of which still > apply, including these on your text below: Georgios: Thank you very much! > > ------ extract from email of 20 nov ------------ "In addition > Option 8 and 10 can in addition support the ECMP solution." > Replace: "They support Affected marking, which [ref] says has > benefits if the PCN-domain operates ECMP multi-path routing" Georgios: Agree! > > additional benefit (and in my view the most significant): > exptal dscps are lightly standardised - limited rules on how > you use them, largely up to the operator. Georgios: Agree! > > 3.3.2 Drawbacks > ... > > Clarify that particular issue for mpls [codepoint shortage] Georgios: I think that the issue is mentioned, but i will include the ECN-MPLS solution. > > ... > > Major disadvantage: interactions with ECMP. ECMP algos can > use a packet's DSCP when deciding what interface to fwd it > on. In a PCN-domain running ECMP, for a flow which has some > packets PCN-marked and some unmarked. its packets will travel > over more than one path. This may well lead to mis-ordering. > To me, this means that the S3.3 DSCP option is a non-starter > in any PCN-domain that uses an ECMP algorithm that uses the > DSCP. NB ECMP algos are proprietary to router vendors, ie > operator has poor control over them. Georgios: This will be a disadvantage only if ECMP based on DSCP is widely used. From the discussion that we have had, e.g., Rudiger, this ECMP option is not deployed in large scale. However, I can mention that if ECMP based on DSCP is used that this might cause reotrdering problems. > > ------- end of extract ------ > > in addition: > reading toby's email there are some additional points to raise: > > 1. extra con: router has to read the existing marking before > writing (otherwise AM can over-write TM) 2. given Toby's > option has some thoughts about what happens in the event that > the PCN-boundary-nodes are misconfigured (and let 11 pkts > sneak in or out), I think it would also be fair for your > option to have some thinking about what happens if > PCN-boundary-node misconfiguration allows a "PCN DSCP" to > sneak in /out. Georgios: I think that the issue of what happens if a PCN-boundary-node misconfiguration allows a "PCN DSCP" to sneak in /out does not cause any problem for the DSCP based options, because when no agreements exist between two neighboring PCN domains the PCN-ingress-node will have to remark all incoming packets to the DSCP value used for PCN capable not congested (PCN) indication. Best regards, Georgios > > Phil. > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 21 February 2008 10:07 > > To: Eardley,PL,Philip,CXR9 R; ingemar.s.johansson@ericsson.com > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni- > > wuerzburg.de; Moncaster,T,Toby,CXR9 R > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > Hi Phil, Hi all > > > > In order to make a selection of one single (or two) options, I think > that > > the PCN WG should get the possibility to study all the possible and > PCN > > relevant encoding options. > > > > In my opinion the goal of the encoding draft is to provide this > > information to the PCN-WG. > > Based on this information the PCN WG can discuss and decide which of > the > > options should be used. > > > > The below text is copied from the current version of the encoding > draft! > > Four options are described! > > Please note that the encoding draft should list all relevant options > with > > advantages and disadvantages. > > > > Phil and Ingemar, if you can add advantages, disadvantages > to the ones > > already mentioned below in Section 3.2.1 and 3.2.2 of the > encoding > > draft, please do. > > > > Best regards, > > Georgios > > > > > > > > 3.2. Encoding Using DSCP Field > > > > In this type of encoding and transport method the congestion and > > precongestion information is encoded into the 6 DSCP > bits that are > > transported in the IP header of the data packets. Four possible > > alternatives can be distinguished, as can be seen in > Figure 3, with > > details provided by draft-westberg-pcn-load-control-02.txt [4]. > > Option 7 needs 2 additional DSCP values, Options 8 and 9 > need three > > additional DSCP values and Option 10 needs four additional DSCP > > values. Note that all additional and experimental DSCP > values are > > representing and are associated with the same PHB. The 1st, 2nd, > > 3rd, and 4th DSCP values are representing DSCP values that are > > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > > > > > > -------------------------------------------------------------- > --------- > > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 > |Add DSCP > 4 | > > > |===========++==========+===========+===========+===========+= > ========== > | > > | Option 6 || Not-PCN | PCN | AM/TM | NA | NA > | > > > |-----------++----------+-----------+-----------+-----------+- > ---------- > | > > | Option 7 || Not-PCN | PCN | AM/TM | AfM | NA > | > > > |-----------++----------+-----------+-----------+-----------+- > ---------- > | > > | Option 8 || Not-PCN | PCN | AM | TM | NA > | > > > |-----------++----------+-----------+-----------+-----------+- > ---------- > | > > | Option 9 || Not-PCN | PCN | AM | TM | AfM > | > > > -------------------------------------------------------------- > --------- > > > > Notes: Not-PCN means the packet is not PCN capable. > > > > Figure 2: Encoding of PCN Information Using DSCP Field > > > > 3.2.1. Benefits of Using DSCP Field > > > > The main benefit of using the DSCP field is that it is not > affecting > > the end-to-end ECN semantics and therefore the issues > and concerns > > raised in RFC 4774 [22] are not applicable for this encoding > scheme. > > Another benefit is related to the fact that all 4 DSCP encoding > > options depicted in Figure 2 can support the PCN capable not > > congested (PCN) indication, the admission control (AM) and flow > > termination (TM) encoding states. In addition Option 8 > and 10 can > > support the ECMP solution. > > > > 3.2.2. Drawbacks of Using DSCP Field > > > > This type of encoding needs to use per PHB, in addition to the > > original DSCP and depending on the encoding option used, > one, two, > > three, or four DSCP values, respectively. These additional DSCP > > values can be taken from the DSCP values that are not defined by > > standards action, see RFC 2211 [9]. Note that all the additional > > DSCP values are representing and are associated with one > PHB. The > > value of this DSCP/PHB can either follow a standards > action or use > a > > value that is applied for experimental or local use. It is > important > > to note that the number of the DSCP values used for local or > > experimental use is restricted and therefore the number of > different > > PHBs supported in the PCN domain will also be restricted. > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > > > Of philip.eardley@bt.com > > > Sent: donderdag 21 februari 2008 10:24 > > > To: ingemar.s.johansson@ericsson.com; > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > Ingemar > > > > > > Re > > > > > > > consider the end to end ECN usecases > > > > > > I believe that the emails below about Toby's encoding proposal do > > > indeed already consider ECN. Would appreciate it if you could add > > > further text to it to better capture the (pros and) cons. > > > > > > > more DSCP codepoints > > > I think you may be proposing an encoding that uses all dscp > > > codepoints (as has Georgios). That's fine - but a "1 pager" > > > setting out this option with its pros and cons (ie > similar to what > > > toby has done below) is needed I think! At the moment we > have lots > > > of options on the table - in order to reach a decision, I > think we > > > really need very few options but with their pros and cons better > > > laid out. > > > > > > > > > I haven't managed to get to your draft yet, sorry (next week > > > hopefully) > > > - > > > Thanks > > > Phil > > > > > > > > > > -----Original Message----- > > > > From: Ingemar Johansson S > [mailto:ingemar.s.johansson@ericsson.com] > > > > Sent: 21 February 2008 06:43 > > > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > > > Moncaster,T,Toby,CXR9 R > > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > Hi > > > > > > > > In this discussion it may be well worth the effort to > > > consider the end > > > > to end ECN usecases that we foresee when considering > various PCN > > > > encoding options. > > > > Please have a look at > > > > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > > for a discussion of the use cases and a motivation to why end to > end > > > ECN > > > > should be maintained even across PCN nodes even for non DF > traffic. > > > > That said I realize that there is some cost associated to > > > the use of > > > > DSCP codepoints, this cost must however be weighted against > > > the risk > > > > that other functionality like end to end ECN semantics > is probably > > > > broken if a PCN encoding option "fiddles" with the ECN > bits. It is > > > easy > > > > to see that if one wish to maintain support for end to end ECN > (not > > > only > > > > in DF class) it simply costs more DSCP codepoints. > > > > I am not explicitly saying don't do this or that but I wish > > > to avoid a > > > > situation where one technique has to be avoided in favor of > > > the other > > > as > > > > it may in the end prevent deployment of both. If one can > > > yank the two > > > > together so much the better even though the cost e.g in > DSCP code > > > points > > > > is regarded as higher. > > > > > > > > Regards > > > > Ingemar > > > > > > > > > -----Original Message----- > > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > On Behalf > > > > > Of philip.eardley@bt.com > > > > > Sent: den 20 februari 2008 17:44 > > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > > > Thanks Michael > > > > > > > > > > I agree with you that spending one DSCP value is > quite expensive > > > > > (not two, as one is spent anyway). I think the only way of > really > > > > > assessing this properly is for an alternative proposal (with > pros > > > > > and cons) that requires only one DSCP. > > > > > Then we can see where the consensus for the best (/least bad) > > > > > encoding lies. Personally I have no axe to grind for > or against > > > > > either - I'm not yet convinced that the proposal below is > > > definitely > > > > > the way to go, until compared it in detail with other > proposals. > > > > > > > > > > So I think it would be really useful to have a "1 pager" for > > > > > alternative > > > > > proposal(s) before the ietf, as I think this would make > > > Philadelphia > > > > > discussions more productive. > > > > > > > > > > > > > > > You're correct about one of the motivations (advantages) for > this > > > > > proposal (although I don't think the issues are exactly > > > the same for > > > > > 11 leakage as 01/10 leakage). > > > > > > > > > > Consider the case where 11 leaks out of the PCN > domain. If the > > > > > endpoints are ECN capable, then the ECN source slows > down (seems > > > > > reasonable). If they're not capable, then the impact > outside the > > > > > domain isn't any different to what would happen without > > > PCN-domain. > > > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > > Then this will lead to either flow admission or > > > termination in the > > > > > PCN-domain. These are both safe, in that the reaction is > > > (I believe) > > > > > at least as severe as would happen in an all ECN world. > > > > > You mention that this might not terminate the ECN-11 flow > > > > > specifically (some other flow might get terminated instead). > > > > > I think this is true, though it also implies that [1] > > > end-to-end ECN > > > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > > > tunnelling) to carry ECN-marking transparently across the > > > PCN-domain > > > > > has also failed, [3] the flows which are terminated > aren't other > > > > > ECN-11 flows that are also getting in due to the same > > > > > misconfiguration. > > > > > > > > > > Best wishes > > > > > Phil > > > > > > -----Original Message----- > > > > > > From: Michael Menth > [mailto:menth@informatik.uni-wuerzburg.de] > > > > > > Sent: 20 February 2008 10:50 > > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > khchan@nortel.com; > > > > > > babiarz@nortel.com; sob@harvard.edu; > steven.blake@ericsson.com; > > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > > > Hi Toby, > > > > > > > > > > > > as I understand the proposal, the motivation is to > avoid 01/10 > > > > > > codepoints as it is not good if they leak out of the > > > network since > > > > > 01/10 > > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > > However, there is > > > > > > the same problem with 11 marking, i.e. 11-packets may not be > > > dropped > > > > > by > > > > > > ECN nodes outside the PCN domain although endpoints are not > ECN > > > > > capable. > > > > > > Even if 11-packets trigger flow termination, it is not > > > > > guaranteed that > > > > > > exactly the marked flow going over an overloaded ECN node is > > > > > terminated. > > > > > > Just want to say that this solution wants to solve a > > > problem that > > > > > exists > > > > > > only in case of misconfiguration (leaking packets), but > > > > > does not fully > > > > > > achieve that objective. Therefore, I feel that spending two > DSCP > > > > > values > > > > > > is quite expensive. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Michael > > > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > > and feel we > > > > > may > > > > > > > have lit upon a neat solution that seems to have lots of > pros > > > and > > > > > few > > > > > > > cons... In order to get a better feeling for this > > > > > proposal I will go > > > > > > > through the simplified version without Affected marking > first: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with > the same PCN > > > > > behaviour > > > > > > > aggregate. > > > > > > > > > > > > > > Pros: > > > > > > > o Termination marking and admission marking are > independent, > > > eg > > > > > > > termination marking can be done after a packet has been > > > admission > > > > > > > marked. Therefore a router can write AM or TM without > > > > > having to read > > > > > the > > > > > > > packet's PCN marking first, which is easier to > > > implement. (Note: > > > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > > ECT(1). This is > > > > > > > safest option if packets leak outside the PCN > region, due to > > > some > > > > > fort > > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > > for a single > > > > > > > domain deployment of PCN). > > > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > > ECT(1) in some > > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > > simply reads its > > > > > DSCP. > > > > > > > This is probably easier than checking both its DSCP & ECN > > > fields. > > > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > > could deploy SM > > > > > > > initially and later AM/TM. Just add the second > > > > > DSCP. > > > > > > > If a router isn't upgraded at the same time nothing > > > too horrific > > > > > > > happens. > > > > > > > [2] could just deploy admission control & add > > > termination later, > > > > > just by > > > > > > > adding a new DSCP; there is no need to change the > > > > > encoding and check > > > > > for > > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > > > Cons: > > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > > (Although > > > > > > > possibly it's OK to use the same DSCP for TM for all PCN > BAs?) > > > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > > > its ECN = > > > > > 11 > > > > > > > and it really is required to preserve this info across the > > > > > PCN-domain, > > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > > (tunnelling) > > > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > > (ECMP) that uses > > > > > the > > > > > > > DSCP to select routes, then there may be mis-ordering > > > of packets > > > > > within > > > > > > > a flow. This may be OK as (1) no-one has yet said > they know > of > > > an > > > > > ECMP > > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > > mis-ordering > > > > > when > > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > > modified as > > > > > > > follows: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11 PCN 2 > > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > > > The pros for this scheme are broadly similar to the above. > > > However > > > > > there > > > > > > > is a new con which may or may not matter: If a packet is > > > affected > > > > > marked > > > > > > > and a later node is doing admission marking then it will > > > > > reset the > > > > > > > affected mark to a termination mark. Work would be needed > > > > > to see if > > > > > this > > > > > > > skews the results and causes significant > over-termination or > > > not. > > > > > > > > > > > > > > Please could people look through this scheme and > > > highlight any > > > > > > > additional concerns that they may have (and extra > > > benefits too). > > > I > > > > > would > > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > > "why not try > > > > > this > > > > > > > scheme instead". Currently we seem to have a plethora of > > > possible > > > > > > > schemes on the table and people need to start putting > > > down much > > > > > clearer > > > > > > > pros and cons for the schemes they support... So it could > > > > > be good to > > > > > > > have a similar "one page" email about a specific > scheme that > > > only > > > > > uses > > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > > > Toby > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > Toby Moncaster, Networks Research > > > > > Centre, BT > > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > 1473 648734 > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 05:47:50 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBA928CA79; Thu, 21 Feb 2008 05:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 BfhwOMK4+UNU; Thu, 21 Feb 2008 05:47:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F16A28CA59; Thu, 21 Feb 2008 05:47:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E9E28C90B for ; Thu, 21 Feb 2008 05:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbl7c6u1asx1 for ; Thu, 21 Feb 2008 05:47:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 71A023A6DC8 for ; Thu, 21 Feb 2008 05:47:19 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C7EF220E14; Thu, 21 Feb 2008 14:47:12 +0100 (CET) X-AuditID: c1b4fb3c-ae8bcbb000007e19-6d-47bd80e087c9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABFAB20DFC; Thu, 21 Feb 2008 14:47:12 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 14:47:12 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:47:11 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> In-Reply-To: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAS8CrA= References: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B6@E03MVZ1-UKDY.domain1.systemhost.net> <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> From: "Ingemar Johansson S" To: "Georgios Karagiannis" , X-OriginalArrivalTime: 21 Feb 2008 13:47:12.0525 (UTC) FILETIME=[42D24BD0:01C87490] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Putting the issues with "leakage" aside (I cannot tell how serious this problem really is). I would prefer to sacrifice the end to end ECN semantics for the ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The reason is simply that from a realtime communication scenario with out of band signaling it is always possible to negotiate the use of ECN CE mark in wireless nodes by means of eg. SIP signaling. Also, atleast for RTP/UDP I see little use for ECN nonce like it is done with TCP as this is more or less an anti-cheat feature. One would then end up with a PCN encoding schema like (I beleve option 5 in figure 1 in the PCN encoding draft) is the closest. PCN Meaning ECN DSCP ============================= PCN capable 00 PCN 1 Admission Mark 01 PCN 1 Termination Mark 10 PCN 1 At PCN ingress the ECT(0) and ECT(1) codepoints should be set to "00", likewise at PCN egress. ECN CE is however left untouched. This has the effect that routers will be able to set ECN-CE on packets before they enter the first PCN domain, after exit from the PCN domain routers are not anymore allowed to set ECN-CE (RFC4774 section 4.3). Wireless nodes such as LTE-eNB (Long Term Evolution-Enhanced Node B) can however set ECN CE as this is can be managed by out of band signaling. Besides this I would prefer a solution that maintains end to end semantics regardless of DSCP value. If one consider DCCP we don't know today if it will be a best effort traffic alternatiive or if there is a benefit with it even with QoS and DCCP can use ECN nonce. /Ingemar > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: den 21 februari 2008 11:07 > To: philip.eardley@bt.com; Ingemar Johansson S > Cc: pcn@ietf.org; bob.briscoe@bt.com; > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > Subject: RE: [PCN] FW: RE: PCN encoding option > > > Hi Phil, Hi all > > In order to make a selection of one single (or two) options, > I think that the PCN WG should get the possibility to study > all the possible and PCN relevant encoding options. > > In my opinion the goal of the encoding draft is to provide > this information to the PCN-WG. > Based on this information the PCN WG can discuss and decide > which of the options should be used. > > The below text is copied from the current version of the > encoding draft! > Four options are described! > Please note that the encoding draft should list all relevant > options with advantages and disadvantages. > > Phil and Ingemar, if you can add advantages, disadvantages to > the ones already mentioned below in Section 3.2.1 and 3.2.2 > of the encoding draft, please do. > > Best regards, > Georgios > > > > 3.2. Encoding Using DSCP Field > > In this type of encoding and transport method the congestion and > precongestion information is encoded into the 6 DSCP bits that are > transported in the IP header of the data packets. Four possible > alternatives can be distinguished, as can be seen in Figure 3, with > details provided by draft-westberg-pcn-load-control-02.txt [4]. > Option 7 needs 2 additional DSCP values, Options 8 and 9 need three > additional DSCP values and Option 10 needs four additional DSCP > values. Note that all additional and experimental DSCP values are > representing and are associated with the same PHB. The 1st, 2nd, > 3rd, and 4th DSCP values are representing DSCP values that are > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > > -------------------------------------------------------------- > --------- > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 > |Add DSCP 4 > || > ===========++==========+===========+===========+===========+== > =========| > | Option 6 || Not-PCN | PCN | AM/TM | NA | > NA | > |-----------++----------+-----------+-----------+-----------+- > ----------| > | Option 7 || Not-PCN | PCN | AM/TM | AfM | > NA | > |-----------++----------+-----------+-----------+-----------+- > ----------| > | Option 8 || Not-PCN | PCN | AM | TM | > NA | > |-----------++----------+-----------+-----------+-----------+- > ----------| > | Option 9 || Not-PCN | PCN | AM | TM | > AfM | > > -------------------------------------------------------------- > --------- > > Notes: Not-PCN means the packet is not PCN capable. > > Figure 2: Encoding of PCN Information Using DSCP Field > > 3.2.1. Benefits of Using DSCP Field > > The main benefit of using the DSCP field is that it is not > affecting > the end-to-end ECN semantics and therefore the issues and concerns > raised in RFC 4774 [22] are not applicable for this > encoding scheme. > Another benefit is related to the fact that all 4 DSCP encoding > options depicted in Figure 2 can support the PCN capable not > congested (PCN) indication, the admission control (AM) and flow > termination (TM) encoding states. In addition Option 8 and 10 can > support the ECMP solution. > > 3.2.2. Drawbacks of Using DSCP Field > > This type of encoding needs to use per PHB, in addition to the > original DSCP and depending on the encoding option used, one, two, > three, or four DSCP values, respectively. These additional DSCP > values can be taken from the DSCP values that are not defined by > standards action, see RFC 2211 [9]. Note that all the additional > DSCP values are representing and are associated with one PHB. The > value of this DSCP/PHB can either follow a standards > action or use a > value that is applied for experimental or local use. It > is important > to note that the number of the DSCP values used for local or > experimental use is restricted and therefore the number of > different > PHBs supported in the PCN domain will also be restricted. > > Best regards, > Georgios > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > philip.eardley@bt.com > > Sent: donderdag 21 februari 2008 10:24 > > To: ingemar.s.johansson@ericsson.com; > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > Ingemar > > > > Re > > > > > consider the end to end ECN usecases > > > > I believe that the emails below about Toby's encoding proposal do > > indeed already consider ECN. Would appreciate it if you could add > > further text to it to better capture the (pros and) cons. > > > > > more DSCP codepoints > > I think you may be proposing an encoding that uses all dscp > codepoints > > (as has Georgios). That's fine - but a "1 pager" > > setting out this option with its pros and cons (ie similar to what > > toby has done below) is needed I think! At the moment we > have lots of > > options on the table - in order to reach a decision, I > think we really > > need very few options but with their pros and cons better laid out. > > > > > > I haven't managed to get to your draft yet, sorry (next week > > hopefully) > > - > > Thanks > > Phil > > > > > > > -----Original Message----- > > > From: Ingemar Johansson S > [mailto:ingemar.s.johansson@ericsson.com] > > > Sent: 21 February 2008 06:43 > > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > > Moncaster,T,Toby,CXR9 R > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > Hi > > > > > > In this discussion it may be well worth the effort to > > consider the end > > > to end ECN usecases that we foresee when considering various PCN > > > encoding options. > > > Please have a look at > > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > for a discussion of the use cases and a motivation to why > end to end > > ECN > > > should be maintained even across PCN nodes even for non > DF traffic. > > > That said I realize that there is some cost associated to > > the use of > > > DSCP codepoints, this cost must however be weighted against > > the risk > > > that other functionality like end to end ECN semantics is > probably > > > broken if a PCN encoding option "fiddles" with the ECN bits. It is > > easy > > > to see that if one wish to maintain support for end to > end ECN (not > > only > > > in DF class) it simply costs more DSCP codepoints. > > > I am not explicitly saying don't do this or that but I wish > > to avoid a > > > situation where one technique has to be avoided in favor of > > the other > > as > > > it may in the end prevent deployment of both. If one can > > yank the two > > > together so much the better even though the cost e.g in DSCP code > > points > > > is regarded as higher. > > > > > > Regards > > > Ingemar > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > On Behalf > > > > Of philip.eardley@bt.com > > > > Sent: den 20 februari 2008 17:44 > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > Thanks Michael > > > > > > > > I agree with you that spending one DSCP value is quite > expensive > > > > (not two, as one is spent anyway). I think the only way > of really > > > > assessing this properly is for an alternative proposal > (with pros > > > > and cons) that requires only one DSCP. > > > > Then we can see where the consensus for the best (/least bad) > > > > encoding lies. Personally I have no axe to grind for or against > > > > either - I'm not yet convinced that the proposal below is > > definitely > > > > the way to go, until compared it in detail with other proposals. > > > > > > > > So I think it would be really useful to have a "1 pager" for > > > > alternative > > > > proposal(s) before the ietf, as I think this would make > > Philadelphia > > > > discussions more productive. > > > > > > > > > > > > You're correct about one of the motivations > (advantages) for this > > > > proposal (although I don't think the issues are exactly > > the same for > > > > 11 leakage as 01/10 leakage). > > > > > > > > Consider the case where 11 leaks out of the PCN domain. If the > > > > endpoints are ECN capable, then the ECN source slows > down (seems > > > > reasonable). If they're not capable, then the impact > outside the > > > > domain isn't any different to what would happen without > > PCN-domain. > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > Then this will lead to either flow admission or > > termination in the > > > > PCN-domain. These are both safe, in that the reaction is > > (I believe) > > > > at least as severe as would happen in an all ECN world. > > > > You mention that this might not terminate the ECN-11 flow > > > > specifically (some other flow might get terminated instead). > > > > I think this is true, though it also implies that [1] > > end-to-end ECN > > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > > tunnelling) to carry ECN-marking transparently across the > > PCN-domain > > > > has also failed, [3] the flows which are terminated aren't other > > > > ECN-11 flows that are also getting in due to the same > > > > misconfiguration. > > > > > > > > Best wishes > > > > Phil > > > > > -----Original Message----- > > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > > Sent: 20 February 2008 10:50 > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > khchan@nortel.com; > > > > > babiarz@nortel.com; sob@harvard.edu; > steven.blake@ericsson.com; > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > Hi Toby, > > > > > > > > > > as I understand the proposal, the motivation is to > avoid 01/10 > > > > > codepoints as it is not good if they leak out of the > > network since > > > > 01/10 > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > However, there is > > > > > the same problem with 11 marking, i.e. 11-packets may not be > > dropped > > > > by > > > > > ECN nodes outside the PCN domain although endpoints > are not ECN > > > > capable. > > > > > Even if 11-packets trigger flow termination, it is not > > > > guaranteed that > > > > > exactly the marked flow going over an overloaded ECN node is > > > > terminated. > > > > > Just want to say that this solution wants to solve a > > problem that > > > > exists > > > > > only in case of misconfiguration (leaking packets), but > > > > does not fully > > > > > achieve that objective. Therefore, I feel that > spending two DSCP > > > > values > > > > > is quite expensive. > > > > > > > > > > Regards, > > > > > > > > > > Michael > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > All, > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > and feel we > > > > may > > > > > > have lit upon a neat solution that seems to have > lots of pros > > and > > > > few > > > > > > cons... In order to get a better feeling for this > > > > proposal I will go > > > > > > through the simplified version without Affected > marking first: > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > Admission Mark 11 PCN 1 > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > > > > behaviour > > > > > > aggregate. > > > > > > > > > > > > Pros: > > > > > > o Termination marking and admission marking are > independent, > > eg > > > > > > termination marking can be done after a packet has been > > admission > > > > > > marked. Therefore a router can write AM or TM without > > > > having to read > > > > the > > > > > > packet's PCN marking first, which is easier to > > implement. (Note: > > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > ECT(1). This is > > > > > > safest option if packets leak outside the PCN region, due to > > some > > > > fort > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > for a single > > > > > > domain deployment of PCN). > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > ECT(1) in some > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > simply reads its > > > > DSCP. > > > > > > This is probably easier than checking both its DSCP & ECN > > fields. > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > could deploy SM > > > > > > initially and later AM/TM. Just add the second > > > > DSCP. > > > > > > If a router isn't upgraded at the same time nothing > > too horrific > > > > > > happens. > > > > > > [2] could just deploy admission control & add > > termination later, > > > > just by > > > > > > adding a new DSCP; there is no need to change the > > > > encoding and check > > > > for > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > Cons: > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > (Although > > > > > > possibly it's OK to use the same DSCP for TM for > all PCN BAs?) > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > > its ECN = > > > > 11 > > > > > > and it really is required to preserve this info across the > > > > PCN-domain, > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > (tunnelling) > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > (ECMP) that uses > > > > the > > > > > > DSCP to select routes, then there may be mis-ordering > > of packets > > > > within > > > > > > a flow. This may be OK as (1) no-one has yet said > they know of > > an > > > > ECMP > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > mis-ordering > > > > when > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > modified as > > > > > > follows: > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > Admission Mark 11 PCN 1 > > > > > > Termination Mark 11 PCN 2 > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > The pros for this scheme are broadly similar to the above. > > However > > > > there > > > > > > is a new con which may or may not matter: If a packet is > > affected > > > > marked > > > > > > and a later node is doing admission marking then it will > > > > reset the > > > > > > affected mark to a termination mark. Work would be needed > > > > to see if > > > > this > > > > > > skews the results and causes significant over-termination or > > not. > > > > > > > > > > > > Please could people look through this scheme and > > highlight any > > > > > > additional concerns that they may have (and extra > > benefits too). > > I > > > > would > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > "why not try > > > > this > > > > > > scheme instead". Currently we seem to have a plethora of > > possible > > > > > > schemes on the table and people need to start putting > > down much > > > > clearer > > > > > > pros and cons for the schemes they support... So it could > > > > be good to > > > > > > have a similar "one page" email about a specific scheme that > > only > > > > uses > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > Toby > > > > > > > > > > > > ____________________________________________________________________ > > > > > > Toby Moncaster, Networks Research > > > > Centre, BT > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:18:42 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6703A6E94; Thu, 21 Feb 2008 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 4TMlaPG7T8Wk; Thu, 21 Feb 2008 06:18:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458B93A6E87; Thu, 21 Feb 2008 06:18:41 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28BA3A696A for ; Thu, 21 Feb 2008 06:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh5fsayejk0r for ; Thu, 21 Feb 2008 06:18:39 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D18243A6E8A for ; Thu, 21 Feb 2008 06:18:37 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 14:18:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:18:21 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345BA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7Ig From: To: , X-OriginalArrivalTime: 21 Feb 2008 14:18:33.0534 (UTC) FILETIME=[A3FD7DE0:01C87494] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > Georgios: I think that they are 4! > Later on the PCN-WG will make a slection of one of the 4! Well, we have a decision about how many codepoints to support, and we have a decision about how to support this number of codepoints. So: we look at the 4 encodings option, in order to compare it with toby's email. > > ... > > > > Major disadvantage: interactions with ECMP. ECMP algos can > > use a packet's DSCP when deciding what interface to fwd it > > on. In a PCN-domain running ECMP, for a flow which has some > > packets PCN-marked and some unmarked. its packets will travel > > over more than one path. This may well lead to mis-ordering. > > To me, this means that the S3.3 DSCP option is a non-starter > > in any PCN-domain that uses an ECMP algorithm that uses the > > DSCP. NB ECMP algos are proprietary to router vendors, ie > > operator has poor control over them. > > Georgios: This will be a disadvantage only if ECMP based on DSCP is widely > used. > From the discussion that we have had, e.g., Rudiger, this ECMP option is > not deployed in large scale. > However, I can mention that if ECMP based on DSCP is used that this might > cause > reotrdering problems. As far as I remember, the entire input on whether ecmp algorithms actually use dscp was the following email from Rudiger [22nov]: "true, the DSCP shouldn't be used to influence ECMP decissions. IP adresses and may be ports. I'd have to ask my staff to get details. I've no problem to recommend not to base ECMP decisions on DSCPs. " please can you point at other emails I missed about " this ECMP option is not deployed in large scale", as I'd be very interested in this. so: it is clear that in theory ecmp algorithms may use dscp value, and that at the moment we don't know in practice or whether there are vendor plans to do so in the future. > > > > 1. extra con: router has to read the existing marking before > > writing (otherwise AM can over-write TM) please remember this con. 2. given Toby's > > option has some thoughts about what happens in the event that > > the PCN-boundary-nodes are misconfigured (and let 11 pkts > > sneak in or out), I think it would also be fair for your > > option to have some thinking about what happens if > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to > > sneak in /out. > > Georgios: I think that the issue of what happens if > a PCN-boundary-node misconfiguration allows a "PCN DSCP" to > sneak in /out does not cause any problem for the DSCP based options, > because > > when no agreements exist between two neighboring PCN domains the > PCN-ingress-node will have to remark all incoming packets to the DSCP > value > used for PCN capable not congested (PCN) indication. To clarify: I was saying there should be text (not whether it was a con) _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:22:42 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D413A6EA5; Thu, 21 Feb 2008 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 HwHH-rddhTss; Thu, 21 Feb 2008 06:22:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0E03A6E8D; Thu, 21 Feb 2008 06:22:40 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E1D3A68ED for ; Thu, 21 Feb 2008 06:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyHGoD56WNfj for ; Thu, 21 Feb 2008 06:22:38 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 9295B3A6EA5 for ; Thu, 21 Feb 2008 06:22:29 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 21 Feb 2008 15:22:25 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 15:22:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 15:23:22 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD2EFA9@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routers and ECMP (part of FW: RE: PCN encoding option) Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABRuAg References: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl><75A199C5D243C741BF3D3F1EBCEF9BA503B345B9@E03MVZ1-UKDY.domain1.systemhost.net> <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Feb 2008 14:22:24.0068 (UTC) FILETIME=[2D663040:01C87495] Cc: pcn@ietf.org Subject: [PCN] Routers and ECMP (part of FW: RE: PCN encoding option) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, unfortunately the ECMP issue is less simple than assumed. Solutions implemented by a single vendor or for a specific protocol don't have to work for other vendors, protocols and may even change with operation systems or hardware platforms of the same vendor. Unless you have spoken with your backbone vendors or even better, unless you have standardised it, you can't for sure say that vendors don't use DSCPs for ECMP. Using IP adresses for the purpose of ECMP is very popular however, that's true. Also the IETF assumes that many routers do that. Regards, Ruediger | > ... | > | > Major disadvantage: interactions with ECMP. ECMP algos can use a | > packet's DSCP when deciding what interface to fwd it on. In a | > PCN-domain running ECMP, for a flow which has some packets PCN-marked | > and some unmarked. its packets will travel over more than one path. | > This may well lead to mis-ordering. | > To me, this means that the S3.3 DSCP option is a non-starter in any | > PCN-domain that uses an ECMP algorithm that uses the DSCP. NB ECMP | > algos are proprietary to router vendors, ie operator has poor control | > over them. | | Georgios: This will be a disadvantage only if ECMP based on | DSCP is widely used. | From the discussion that we have had, e.g., Rudiger, this | ECMP option is not deployed in large scale. | However, I can mention that if ECMP based on DSCP is used | that this might cause reotrdering problems. | _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:31:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2091D3A6EBD; Thu, 21 Feb 2008 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.041 X-Spam-Level: X-Spam-Status: No, score=0.041 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 inFBPwEZ8Db4; Thu, 21 Feb 2008 06:31:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B173A6E92; Thu, 21 Feb 2008 06:31:16 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8235C3A6E91 for ; Thu, 21 Feb 2008 06:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjtG+Qet-Gwz for ; Thu, 21 Feb 2008 06:31:14 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 563AF3A6EBB for ; Thu, 21 Feb 2008 06:31:13 -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 m1LEV42Z018350; Thu, 21 Feb 2008 15:31:07 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345BA@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 21 Feb 2008 15:30:59 +0100 Message-ID: <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345BA@E03MVZ1-UKDY.domain1.systemhost.net> thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7IgAACz93A= 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, 21 Feb 2008 15:31:08 +0100 (MET) Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Please see in line! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 21 februari 2008 15:18 > To: karagian@cs.utwente.nl; ingemar.s.johansson@ericsson.com > Cc: pcn@ietf.org; bob.briscoe@bt.com; > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > Georgios: I think that they are 4! > > Later on the PCN-WG will make a slection of one of the 4! > > Well, we have a decision about how many codepoints to > support, and we have a decision about how to support this > number of codepoints. > So: we look at the 4 encodings option, in order to compare it > with toby's email. Georgios: You mean Toby and you had a decission! > > > > ... > > > > > > Major disadvantage: interactions with ECMP. ECMP algos can use a > > > packet's DSCP when deciding what interface to fwd it on. In a > > > PCN-domain running ECMP, for a flow which has some packets > > > PCN-marked and some unmarked. its packets will travel > over more than > > > one path. This may well lead to mis-ordering. > > > To me, this means that the S3.3 DSCP option is a > non-starter in any > > > PCN-domain that uses an ECMP algorithm that uses the > DSCP. NB ECMP > > > algos are proprietary to router vendors, ie operator has poor > > > control over them. > > > > Georgios: This will be a disadvantage only if ECMP based on DSCP is > widely > > used. > > From the discussion that we have had, e.g., Rudiger, this > ECMP option > is > > not deployed in large scale. > > However, I can mention that if ECMP based on DSCP is used that this > might > > cause > > reotrdering problems. > > As far as I remember, the entire input on whether ecmp > algorithms actually use dscp was the following email from > Rudiger [22nov]: > "true, the DSCP shouldn't be used to influence ECMP > decissions. IP adresses and may be ports. I'd have to ask my > staff to get details. I've no problem to recommend not to > base ECMP decisions on DSCPs. " > please can you point at other emails I missed about " this > ECMP option is not deployed in large scale", as I'd be very > interested in this. > > so: it is clear that in theory ecmp algorithms may use dscp > value, and that at the moment we don't know in practice or > whether there are vendor plans to do so in the future. Georgios: I am not sure if this is the email that encaptured that discussion. It will be good if we can get more input from operators on the usage of DSCP for ECMP. However, as I already mentioned, a sentence associated with this issue can be included in the text! > > > > > > > > 1. extra con: router has to read the existing marking > before writing > > > (otherwise AM can over-write TM) > > please remember this con. Georgios: I do not understand this statement! A router has to know what it has to mark and how. Or am I missing something here? The same holds for marking ECN bits! > > 2. given Toby's > > > option has some thoughts about what happens in the event that the > > > PCN-boundary-nodes are misconfigured (and let 11 pkts sneak in or > > > out), I think it would also be fair for your option to have some > > > thinking about what happens if PCN-boundary-node misconfiguration > > > allows a "PCN DSCP" to sneak in /out. > > > > Georgios: I think that the issue of what happens if a > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to sneak in > > /out does not cause any problem for the DSCP based options, because > > > > when no agreements exist between two neighboring PCN domains the > > PCN-ingress-node will have to remark all incoming packets > to the DSCP > > value used for PCN capable not congested (PCN) indication. > > To clarify: I was saying there should be text (not whether it > was a con) Best regards, Georgios > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:34:34 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912A43A6EB4; Thu, 21 Feb 2008 06:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 uN08eBlaWnVh; Thu, 21 Feb 2008 06:34:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4CE3A6ECC; Thu, 21 Feb 2008 06:34:16 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C463A6ECC for ; Thu, 21 Feb 2008 06:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjBAEntm9JHB for ; Thu, 21 Feb 2008 06:34:09 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 2C98B3A6EFD for ; Thu, 21 Feb 2008 06:33:50 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 14:33:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:33:57 -0000 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAS8CrAABOGu8A== From: To: , , X-OriginalArrivalTime: 21 Feb 2008 14:33:45.0658 (UTC) FILETIME=[C3A891A0:01C87496] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, This is exactly the sort of thing Phil and I were hoping to trigger people to write in response to our email. We are hoping to settle on what are the real options people support for the encoding and why they support them... Just one quick observation - if we have to leave 11 unchanged across the PCN domain this will mean that such packets can't be PCN marked and thus they should not form part of any PCN aggregate (in my opinion)... Toby > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 21 February 2008 13:47 > To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi > > Putting the issues with "leakage" aside (I cannot tell how > serious this > problem really is). > > I would prefer to sacrifice the end to end ECN semantics for > the ECT(0) > and ECT(1) codepoints instead of the ECN-CE codepoint. The reason is > simply that from a realtime communication scenario with out of band > signaling it is always possible to negotiate the use of ECN CE mark in > wireless nodes by means of eg. SIP signaling. Also, atleast > for RTP/UDP > I see little use for ECN nonce like it is done with TCP as > this is more > or less an anti-cheat feature. > > > One would then end up with a PCN encoding schema like (I > beleve option 5 > in figure 1 in the PCN encoding draft) is the closest. > > PCN Meaning ECN DSCP > ============================= > PCN capable 00 PCN 1 > Admission Mark 01 PCN 1 > Termination Mark 10 PCN 1 > > At PCN ingress the ECT(0) and ECT(1) codepoints should be set to "00", > likewise at PCN egress. ECN CE is however left untouched. This has the > effect that routers will be able to set ECN-CE on packets before they > enter the first PCN domain, after exit from the PCN domain > routers are > not anymore allowed to set ECN-CE (RFC4774 section 4.3). > Wireless nodes > such as LTE-eNB (Long Term Evolution-Enhanced Node B) can however set > ECN CE as this is can be managed by out of band signaling. > > Besides this I would prefer a solution that maintains end to end > semantics regardless of DSCP value. If one consider DCCP we don't know > today if it will be a best effort traffic alternatiive or if > there is a > benefit with it even with QoS and DCCP can use ECN nonce. > > /Ingemar > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: den 21 februari 2008 11:07 > > To: philip.eardley@bt.com; Ingemar Johansson S > > Cc: pcn@ietf.org; bob.briscoe@bt.com; > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > Hi Phil, Hi all > > > > In order to make a selection of one single (or two) options, > > I think that the PCN WG should get the possibility to study > > all the possible and PCN relevant encoding options. > > > > In my opinion the goal of the encoding draft is to provide > > this information to the PCN-WG. > > Based on this information the PCN WG can discuss and decide > > which of the options should be used. > > > > The below text is copied from the current version of the > > encoding draft! > > Four options are described! > > Please note that the encoding draft should list all relevant > > options with advantages and disadvantages. > > > > Phil and Ingemar, if you can add advantages, disadvantages to > > the ones already mentioned below in Section 3.2.1 and 3.2.2 > > of the encoding draft, please do. > > > > Best regards, > > Georgios > > > > > > > > 3.2. Encoding Using DSCP Field > > > > In this type of encoding and transport method the congestion and > > precongestion information is encoded into the 6 DSCP > bits that are > > transported in the IP header of the data packets. Four possible > > alternatives can be distinguished, as can be seen in > Figure 3, with > > details provided by draft-westberg-pcn-load-control-02.txt [4]. > > Option 7 needs 2 additional DSCP values, Options 8 and 9 > need three > > additional DSCP values and Option 10 needs four additional DSCP > > values. Note that all additional and experimental DSCP > values are > > representing and are associated with the same PHB. The 1st, 2nd, > > 3rd, and 4th DSCP values are representing DSCP values that are > > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > > > > > > > -------------------------------------------------------------- > > --------- > > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 > > |Add DSCP 4 > > || > > ===========++==========+===========+===========+===========+== > > =========| > > | Option 6 || Not-PCN | PCN | AM/TM | NA | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 7 || Not-PCN | PCN | AM/TM | AfM | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 8 || Not-PCN | PCN | AM | TM | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 9 || Not-PCN | PCN | AM | TM | > > AfM | > > > > -------------------------------------------------------------- > > --------- > > > > Notes: Not-PCN means the packet is not PCN capable. > > > > Figure 2: Encoding of PCN Information Using DSCP Field > > > > 3.2.1. Benefits of Using DSCP Field > > > > The main benefit of using the DSCP field is that it is not > > affecting > > the end-to-end ECN semantics and therefore the issues > and concerns > > raised in RFC 4774 [22] are not applicable for this > > encoding scheme. > > Another benefit is related to the fact that all 4 DSCP encoding > > options depicted in Figure 2 can support the PCN capable not > > congested (PCN) indication, the admission control (AM) and flow > > termination (TM) encoding states. In addition Option 8 > and 10 can > > support the ECMP solution. > > > > 3.2.2. Drawbacks of Using DSCP Field > > > > This type of encoding needs to use per PHB, in addition to the > > original DSCP and depending on the encoding option used, > one, two, > > three, or four DSCP values, respectively. These additional DSCP > > values can be taken from the DSCP values that are not defined by > > standards action, see RFC 2211 [9]. Note that all the additional > > DSCP values are representing and are associated with one > PHB. The > > value of this DSCP/PHB can either follow a standards > > action or use a > > value that is applied for experimental or local use. It > > is important > > to note that the number of the DSCP values used for local or > > experimental use is restricted and therefore the number of > > different > > PHBs supported in the PCN domain will also be restricted. > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > philip.eardley@bt.com > > > Sent: donderdag 21 februari 2008 10:24 > > > To: ingemar.s.johansson@ericsson.com; > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > Ingemar > > > > > > Re > > > > > > > consider the end to end ECN usecases > > > > > > I believe that the emails below about Toby's encoding proposal do > > > indeed already consider ECN. Would appreciate it if you could add > > > further text to it to better capture the (pros and) cons. > > > > > > > more DSCP codepoints > > > I think you may be proposing an encoding that uses all dscp > > codepoints > > > (as has Georgios). That's fine - but a "1 pager" > > > setting out this option with its pros and cons (ie > similar to what > > > toby has done below) is needed I think! At the moment we > > have lots of > > > options on the table - in order to reach a decision, I > > think we really > > > need very few options but with their pros and cons better > laid out. > > > > > > > > > I haven't managed to get to your draft yet, sorry (next week > > > hopefully) > > > - > > > Thanks > > > Phil > > > > > > > > > > -----Original Message----- > > > > From: Ingemar Johansson S > > [mailto:ingemar.s.johansson@ericsson.com] > > > > Sent: 21 February 2008 06:43 > > > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > > > Moncaster,T,Toby,CXR9 R > > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > Hi > > > > > > > > In this discussion it may be well worth the effort to > > > consider the end > > > > to end ECN usecases that we foresee when considering > various PCN > > > > encoding options. > > > > Please have a look at > > > > > > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > > for a discussion of the use cases and a motivation to why > > end to end > > > ECN > > > > should be maintained even across PCN nodes even for non > > DF traffic. > > > > That said I realize that there is some cost associated to > > > the use of > > > > DSCP codepoints, this cost must however be weighted against > > > the risk > > > > that other functionality like end to end ECN semantics is > > probably > > > > broken if a PCN encoding option "fiddles" with the ECN > bits. It is > > > easy > > > > to see that if one wish to maintain support for end to > > end ECN (not > > > only > > > > in DF class) it simply costs more DSCP codepoints. > > > > I am not explicitly saying don't do this or that but I wish > > > to avoid a > > > > situation where one technique has to be avoided in favor of > > > the other > > > as > > > > it may in the end prevent deployment of both. If one can > > > yank the two > > > > together so much the better even though the cost e.g in > DSCP code > > > points > > > > is regarded as higher. > > > > > > > > Regards > > > > Ingemar > > > > > > > > > -----Original Message----- > > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > On Behalf > > > > > Of philip.eardley@bt.com > > > > > Sent: den 20 februari 2008 17:44 > > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > > > Thanks Michael > > > > > > > > > > I agree with you that spending one DSCP value is quite > > expensive > > > > > (not two, as one is spent anyway). I think the only way > > of really > > > > > assessing this properly is for an alternative proposal > > (with pros > > > > > and cons) that requires only one DSCP. > > > > > Then we can see where the consensus for the best (/least bad) > > > > > encoding lies. Personally I have no axe to grind for > or against > > > > > either - I'm not yet convinced that the proposal below is > > > definitely > > > > > the way to go, until compared it in detail with other > proposals. > > > > > > > > > > So I think it would be really useful to have a "1 pager" for > > > > > alternative > > > > > proposal(s) before the ietf, as I think this would make > > > Philadelphia > > > > > discussions more productive. > > > > > > > > > > > > > > > You're correct about one of the motivations > > (advantages) for this > > > > > proposal (although I don't think the issues are exactly > > > the same for > > > > > 11 leakage as 01/10 leakage). > > > > > > > > > > Consider the case where 11 leaks out of the PCN > domain. If the > > > > > endpoints are ECN capable, then the ECN source slows > > down (seems > > > > > reasonable). If they're not capable, then the impact > > outside the > > > > > domain isn't any different to what would happen without > > > PCN-domain. > > > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > > Then this will lead to either flow admission or > > > termination in the > > > > > PCN-domain. These are both safe, in that the reaction is > > > (I believe) > > > > > at least as severe as would happen in an all ECN world. > > > > > You mention that this might not terminate the ECN-11 flow > > > > > specifically (some other flow might get terminated instead). > > > > > I think this is true, though it also implies that [1] > > > end-to-end ECN > > > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > > > tunnelling) to carry ECN-marking transparently across the > > > PCN-domain > > > > > has also failed, [3] the flows which are terminated > aren't other > > > > > ECN-11 flows that are also getting in due to the same > > > > > misconfiguration. > > > > > > > > > > Best wishes > > > > > Phil > > > > > > -----Original Message----- > > > > > > From: Michael Menth > [mailto:menth@informatik.uni-wuerzburg.de] > > > > > > Sent: 20 February 2008 10:50 > > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > > khchan@nortel.com; > > > > > > babiarz@nortel.com; sob@harvard.edu; > > steven.blake@ericsson.com; > > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > > > Hi Toby, > > > > > > > > > > > > as I understand the proposal, the motivation is to > > avoid 01/10 > > > > > > codepoints as it is not good if they leak out of the > > > network since > > > > > 01/10 > > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > > However, there is > > > > > > the same problem with 11 marking, i.e. 11-packets may not be > > > dropped > > > > > by > > > > > > ECN nodes outside the PCN domain although endpoints > > are not ECN > > > > > capable. > > > > > > Even if 11-packets trigger flow termination, it is not > > > > > guaranteed that > > > > > > exactly the marked flow going over an overloaded ECN node is > > > > > terminated. > > > > > > Just want to say that this solution wants to solve a > > > problem that > > > > > exists > > > > > > only in case of misconfiguration (leaking packets), but > > > > > does not fully > > > > > > achieve that objective. Therefore, I feel that > > spending two DSCP > > > > > values > > > > > > is quite expensive. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Michael > > > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > > and feel we > > > > > may > > > > > > > have lit upon a neat solution that seems to have > > lots of pros > > > and > > > > > few > > > > > > > cons... In order to get a better feeling for this > > > > > proposal I will go > > > > > > > through the simplified version without Affected > > marking first: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with > the same PCN > > > > > behaviour > > > > > > > aggregate. > > > > > > > > > > > > > > Pros: > > > > > > > o Termination marking and admission marking are > > independent, > > > eg > > > > > > > termination marking can be done after a packet has been > > > admission > > > > > > > marked. Therefore a router can write AM or TM without > > > > > having to read > > > > > the > > > > > > > packet's PCN marking first, which is easier to > > > implement. (Note: > > > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > > ECT(1). This is > > > > > > > safest option if packets leak outside the PCN > region, due to > > > some > > > > > fort > > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > > for a single > > > > > > > domain deployment of PCN). > > > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > > ECT(1) in some > > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > > simply reads its > > > > > DSCP. > > > > > > > This is probably easier than checking both its DSCP & ECN > > > fields. > > > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > > could deploy SM > > > > > > > initially and later AM/TM. Just add the second > > > > > DSCP. > > > > > > > If a router isn't upgraded at the same time nothing > > > too horrific > > > > > > > happens. > > > > > > > [2] could just deploy admission control & add > > > termination later, > > > > > just by > > > > > > > adding a new DSCP; there is no need to change the > > > > > encoding and check > > > > > for > > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > > > Cons: > > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > > (Although > > > > > > > possibly it's OK to use the same DSCP for TM for > > all PCN BAs?) > > > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > > > its ECN = > > > > > 11 > > > > > > > and it really is required to preserve this info across the > > > > > PCN-domain, > > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > > (tunnelling) > > > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > > (ECMP) that uses > > > > > the > > > > > > > DSCP to select routes, then there may be mis-ordering > > > of packets > > > > > within > > > > > > > a flow. This may be OK as (1) no-one has yet said > > they know of > > > an > > > > > ECMP > > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > > mis-ordering > > > > > when > > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > > modified as > > > > > > > follows: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11 PCN 2 > > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > > > The pros for this scheme are broadly similar to the above. > > > However > > > > > there > > > > > > > is a new con which may or may not matter: If a packet is > > > affected > > > > > marked > > > > > > > and a later node is doing admission marking then it will > > > > > reset the > > > > > > > affected mark to a termination mark. Work would be needed > > > > > to see if > > > > > this > > > > > > > skews the results and causes significant > over-termination or > > > not. > > > > > > > > > > > > > > Please could people look through this scheme and > > > highlight any > > > > > > > additional concerns that they may have (and extra > > > benefits too). > > > I > > > > > would > > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > > "why not try > > > > > this > > > > > > > scheme instead". Currently we seem to have a plethora of > > > possible > > > > > > > schemes on the table and people need to start putting > > > down much > > > > > clearer > > > > > > > pros and cons for the schemes they support... So it could > > > > > be good to > > > > > > > have a similar "one page" email about a specific > scheme that > > > only > > > > > uses > > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > > > Toby > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > Toby Moncaster, Networks Research > > > > > Centre, BT > > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > 1473 648734 > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:37:46 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1733A6E9A; Thu, 21 Feb 2008 06:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 vVMuF8c0bAm4; Thu, 21 Feb 2008 06:37:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C5F3A6E87; Thu, 21 Feb 2008 06:37:45 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1E73A6E83 for ; Thu, 21 Feb 2008 06:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oQ+xbZduAVO for ; Thu, 21 Feb 2008 06:37:43 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B37CE3A6E7C for ; Thu, 21 Feb 2008 06:37:10 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 14:37:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:37:19 -0000 Message-ID: In-Reply-To: <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7IgAACz93AAAGEwMA== From: To: , , X-OriginalArrivalTime: 21 Feb 2008 14:37:06.0695 (UTC) FILETIME=[3B7C6170:01C87497] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Please see inline > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 21 February 2008 14:31 > To: Eardley,PL,Philip,CXR9 R; ingemar.s.johansson@ericsson.com > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi Phil > > Please see in line! > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: donderdag 21 februari 2008 15:18 > > To: karagian@cs.utwente.nl; ingemar.s.johansson@ericsson.com > > Cc: pcn@ietf.org; bob.briscoe@bt.com; > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > Georgios: I think that they are 4! > > > Later on the PCN-WG will make a slection of one of the 4! > > > > Well, we have a decision about how many codepoints to > > support, and we have a decision about how to support this > > number of codepoints. > > So: we look at the 4 encodings option, in order to compare it > > with toby's email. > > Georgios: You mean Toby and you had a decission! > Toby: From minutes of IETF 70: "Need to say that range of states required is 3 to 5. Agreed." The actual discussion was that the states needed were a selection of 3 4 or 5 states from not PCN, PCN capable, Admission Mark (or equiv), Termination Mark (or equiv) and Affected Mark. Ignoring the Not Pcn state (as this is a separate issue) this leaves the 4 encodings Phil is referring to > > > > > > ... > > > > > > > > Major disadvantage: interactions with ECMP. ECMP algos > can use a > > > > packet's DSCP when deciding what interface to fwd it on. In a > > > > PCN-domain running ECMP, for a flow which has some packets > > > > PCN-marked and some unmarked. its packets will travel > > over more than > > > > one path. This may well lead to mis-ordering. > > > > To me, this means that the S3.3 DSCP option is a > > non-starter in any > > > > PCN-domain that uses an ECMP algorithm that uses the > > DSCP. NB ECMP > > > > algos are proprietary to router vendors, ie operator has poor > > > > control over them. > > > > > > Georgios: This will be a disadvantage only if ECMP based > on DSCP is > > widely > > > used. > > > From the discussion that we have had, e.g., Rudiger, this > > ECMP option > > is > > > not deployed in large scale. > > > However, I can mention that if ECMP based on DSCP is used > that this > > might > > > cause > > > reotrdering problems. > > > > As far as I remember, the entire input on whether ecmp > > algorithms actually use dscp was the following email from > > Rudiger [22nov]: > > "true, the DSCP shouldn't be used to influence ECMP > > decissions. IP adresses and may be ports. I'd have to ask my > > staff to get details. I've no problem to recommend not to > > base ECMP decisions on DSCPs. " > > please can you point at other emails I missed about " this > > ECMP option is not deployed in large scale", as I'd be very > > interested in this. > > > > so: it is clear that in theory ecmp algorithms may use dscp > > value, and that at the moment we don't know in practice or > > whether there are vendor plans to do so in the future. > > Georgios: I am not sure if this is the email that encaptured that > discussion. > It will be good if we can get more input from operators on > the usage of DSCP > for ECMP. > However, as I already mentioned, a sentence associated with > this issue can > be included in the text! > > > > > > > > > > > > > > > 1. extra con: router has to read the existing marking > > before writing > > > > (otherwise AM can over-write TM) > > > > please remember this con. > > Georgios: I do not understand this statement! A router has to > know what it > has > to mark and how. Or am I missing something here? The same holds for > marking ECN bits! > > > > > > 2. given Toby's > > > > option has some thoughts about what happens in the > event that the > > > > PCN-boundary-nodes are misconfigured (and let 11 pkts > sneak in or > > > > out), I think it would also be fair for your option to > have some > > > > thinking about what happens if PCN-boundary-node > misconfiguration > > > > allows a "PCN DSCP" to sneak in /out. > > > > > > Georgios: I think that the issue of what happens if a > > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to > sneak in > > > /out does not cause any problem for the DSCP based > options, because > > > > > > when no agreements exist between two neighboring PCN domains the > > > PCN-ingress-node will have to remark all incoming packets > > to the DSCP > > > value used for PCN capable not congested (PCN) indication. > > > > To clarify: I was saying there should be text (not whether it > > was a con) > > Best regards, > Georgios > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 06:49:21 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DA73A6E76; Thu, 21 Feb 2008 06:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 q7ahrOoNrf2F; Thu, 21 Feb 2008 06:49:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D753A6E88; Thu, 21 Feb 2008 06:49:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EB43A6E76 for ; Thu, 21 Feb 2008 06:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly3Tx4-spWZa for ; Thu, 21 Feb 2008 06:49:18 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 5F1D13A6E82 for ; Thu, 21 Feb 2008 06:49:18 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 14:49:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:49:13 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345BB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7IgAACz93AAAJnaEA== From: To: , X-OriginalArrivalTime: 21 Feb 2008 14:49:14.0122 (UTC) FILETIME=[ED10EEA0:01C87498] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > > > Well, we have a decision about how many codepoints to > > support, and we have a decision about how to support this > > number of codepoints. > > So: we look at the 4 encodings option, in order to compare it > > with toby's email. > > Georgios: You mean Toby and you had a decission! I meant this. my brain cannot hold all debates simultaneously. So: have the discussion about how many different encoding states are needed. Have the discussion about how you encode each of those states. Toby's email assumes all 4 states are needed. In any case - is there really any substantive difference, in terms of pros and cons, between your 4 options? They're all "just use as many dscps as required", and all have similar pros and cons surely? > > > > 1. extra con: router has to read the existing marking > > before writing > > > > (otherwise AM can over-write TM) > > > > please remember this con. > > Georgios: I do not understand this statement! A router has to know what it > has > to mark and how. Or am I missing something here? The same holds for > marking ECN bits! is whether the router has to check what the pkt's marking is before it marks it. with your scheme it does. As toby's email: " (Note: Over-writing a TM with AM is not allowed for 3SM & CL, see draft-charny-pcn-comparison.)" _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 07:19:04 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104E928C72F; Thu, 21 Feb 2008 07:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 ZehH59aRERVI; Thu, 21 Feb 2008 07:19:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3AAE28C5FD; Thu, 21 Feb 2008 07:18:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003BC28C557 for ; Thu, 21 Feb 2008 07:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx+VUd5HUDHR for ; Thu, 21 Feb 2008 07:18:58 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id BD0C328C281 for ; Thu, 21 Feb 2008 07:18:57 -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 m1LFIiCe021843; Thu, 21 Feb 2008 16:18:47 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> Date: Thu, 21 Feb 2008 16:18:41 +0100 Message-ID: <002901c8749d$0c47f8f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7IgAACz93AAAGEwMAABZktw 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, 21 Feb 2008 16:18:48 +0100 (MET) Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby > "Need to say that range of states required is 3 to 5. Agreed." The sentence above mentiones that it has to be said how many number of states an option requires: 3, 4 or 5. It does not say anything about the selection of an option that supports 4 states! Or am I missing something here! Best regards, Georgios > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: donderdag 21 februari 2008 15:37 > To: karagian@cs.utwente.nl; philip.eardley@bt.com; > ingemar.s.johansson@ericsson.com > Cc: pcn@ietf.org; bob.briscoe@bt.com; > menth@informatik.uni-wuerzburg.de > Subject: RE: [PCN] FW: RE: PCN encoding option > > Please see inline > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 21 February 2008 14:31 > > To: Eardley,PL,Philip,CXR9 R; ingemar.s.johansson@ericsson.com > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > > menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > Hi Phil > > > > Please see in line! > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: donderdag 21 februari 2008 15:18 > > > To: karagian@cs.utwente.nl; ingemar.s.johansson@ericsson.com > > > Cc: pcn@ietf.org; bob.briscoe@bt.com; > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > > > > Georgios: I think that they are 4! > > > > Later on the PCN-WG will make a slection of one of the 4! > > > > > > Well, we have a decision about how many codepoints to > support, and > > > we have a decision about how to support this number of codepoints. > > > So: we look at the 4 encodings option, in order to > compare it with > > > toby's email. > > > > Georgios: You mean Toby and you had a decission! > > > > Toby: From minutes of IETF 70: > > "Need to say that range of states required is 3 to 5. Agreed." > > The actual discussion was that the states needed were a > selection of 3 4 or 5 states from not PCN, PCN capable, > Admission Mark (or equiv), Termination Mark (or equiv) and > Affected Mark. Ignoring the Not Pcn state (as this is a > separate issue) this leaves the 4 encodings Phil is referring to > > > > > > > > > > ... > > > > > > > > > > Major disadvantage: interactions with ECMP. ECMP algos > > can use a > > > > > packet's DSCP when deciding what interface to fwd it on. In a > > > > > PCN-domain running ECMP, for a flow which has some packets > > > > > PCN-marked and some unmarked. its packets will travel > > > over more than > > > > > one path. This may well lead to mis-ordering. > > > > > To me, this means that the S3.3 DSCP option is a > > > non-starter in any > > > > > PCN-domain that uses an ECMP algorithm that uses the > > > DSCP. NB ECMP > > > > > algos are proprietary to router vendors, ie operator has poor > > > > > control over them. > > > > > > > > Georgios: This will be a disadvantage only if ECMP based > > on DSCP is > > > widely > > > > used. > > > > From the discussion that we have had, e.g., Rudiger, this > > > ECMP option > > > is > > > > not deployed in large scale. > > > > However, I can mention that if ECMP based on DSCP is used > > that this > > > might > > > > cause > > > > reotrdering problems. > > > > > > As far as I remember, the entire input on whether ecmp algorithms > > > actually use dscp was the following email from Rudiger [22nov]: > > > "true, the DSCP shouldn't be used to influence ECMP > decissions. IP > > > adresses and may be ports. I'd have to ask my staff to > get details. > > > I've no problem to recommend not to base ECMP decisions > on DSCPs. " > > > please can you point at other emails I missed about " this ECMP > > > option is not deployed in large scale", as I'd be very > interested in > > > this. > > > > > > so: it is clear that in theory ecmp algorithms may use > dscp value, > > > and that at the moment we don't know in practice or whether there > > > are vendor plans to do so in the future. > > > > Georgios: I am not sure if this is the email that encaptured that > > discussion. > > It will be good if we can get more input from operators on > the usage > > of DSCP for ECMP. > > However, as I already mentioned, a sentence associated with > this issue > > can be included in the text! > > > > > > > > > > > > > > > > > > > > > > 1. extra con: router has to read the existing marking > > > before writing > > > > > (otherwise AM can over-write TM) > > > > > > please remember this con. > > > > Georgios: I do not understand this statement! A router has to know > > what it has to mark and how. Or am I missing something > here? The same > > holds for marking ECN bits! > > > > > > > > > > 2. given Toby's > > > > > option has some thoughts about what happens in the > > event that the > > > > > PCN-boundary-nodes are misconfigured (and let 11 pkts > > sneak in or > > > > > out), I think it would also be fair for your option to > > have some > > > > > thinking about what happens if PCN-boundary-node > > misconfiguration > > > > > allows a "PCN DSCP" to sneak in /out. > > > > > > > > Georgios: I think that the issue of what happens if a > > > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to > > sneak in > > > > /out does not cause any problem for the DSCP based > > options, because > > > > > > > > when no agreements exist between two neighboring PCN > domains the > > > > PCN-ingress-node will have to remark all incoming packets > > > to the DSCP > > > > value used for PCN capable not congested (PCN) indication. > > > > > > To clarify: I was saying there should be text (not > whether it was a > > > con) > > > > Best regards, > > Georgios > > > > > > > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 08:17:50 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2764A28C72F; Thu, 21 Feb 2008 08:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 dvptGijUgIMa; Thu, 21 Feb 2008 08:17:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109A13A6E92; Thu, 21 Feb 2008 08:17:49 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6659328C73C for ; Thu, 21 Feb 2008 08:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqoRHJ9mJ9-S for ; Thu, 21 Feb 2008 08:17:46 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 7301628C29D for ; Thu, 21 Feb 2008 08:17:04 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 21 Feb 2008 17:16:48 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 17:16:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 17:17:46 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8BBDA@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAABD7IgAACz93AAA9EIIA== References: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl><75A199C5D243C741BF3D3F1EBCEF9BA503B345BA@E03MVZ1-UKDY.domain1.systemhost.net> <002301c87496$63be4730$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Feb 2008 16:16:48.0259 (UTC) FILETIME=[28C69D30:01C874A5] Cc: pcn@ietf.org Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, I copy one statement from below: | Georgios: I am not sure if this is the email that encaptured | that discussion. | It will be good if we can get more input from operators on | the usage of DSCP for ECMP. [snip] You should look for that input from vendors. Operators have the choice to activate or deactivate ECMP. They can't configure it (at least not with the systems from our vendors). Regards, Ruediger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Georgios Karagiannis | Sent: Thursday, February 21, 2008 3:31 PM | To: philip.eardley@bt.com; ingemar.s.johansson@ericsson.com | Cc: pcn@ietf.org; bob.briscoe@bt.com | Subject: Re: [PCN] FW: RE: PCN encoding option | | Hi Phil | | Please see in line! | | | > -----Original Message----- | > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > Sent: donderdag 21 februari 2008 15:18 | > To: karagian@cs.utwente.nl; ingemar.s.johansson@ericsson.com | > Cc: pcn@ietf.org; bob.briscoe@bt.com; | > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | > Subject: RE: [PCN] FW: RE: PCN encoding option | > | > > | > > Georgios: I think that they are 4! | > > Later on the PCN-WG will make a slection of one of the 4! | > | > Well, we have a decision about how many codepoints to | support, and we | > have a decision about how to support this number of codepoints. | > So: we look at the 4 encodings option, in order to compare it with | > toby's email. | | Georgios: You mean Toby and you had a decission! | | > | > > > ... | > > > | > > > Major disadvantage: interactions with ECMP. ECMP algos | can use a | > > > packet's DSCP when deciding what interface to fwd it on. In a | > > > PCN-domain running ECMP, for a flow which has some packets | > > > PCN-marked and some unmarked. its packets will travel | > over more than | > > > one path. This may well lead to mis-ordering. | > > > To me, this means that the S3.3 DSCP option is a | > non-starter in any | > > > PCN-domain that uses an ECMP algorithm that uses the | > DSCP. NB ECMP | > > > algos are proprietary to router vendors, ie operator has poor | > > > control over them. | > > | > > Georgios: This will be a disadvantage only if ECMP based | on DSCP is | > widely | > > used. | > > From the discussion that we have had, e.g., Rudiger, this | > ECMP option | > is | > > not deployed in large scale. | > > However, I can mention that if ECMP based on DSCP is used | that this | > might | > > cause | > > reotrdering problems. | > | > As far as I remember, the entire input on whether ecmp algorithms | > actually use dscp was the following email from Rudiger [22nov]: | > "true, the DSCP shouldn't be used to influence ECMP decissions. IP | > adresses and may be ports. I'd have to ask my staff to get details. | > I've no problem to recommend not to base ECMP decisions on DSCPs. " | > please can you point at other emails I missed about " this | ECMP option | > is not deployed in large scale", as I'd be very interested in this. | > | > so: it is clear that in theory ecmp algorithms may use dscp | value, and | > that at the moment we don't know in practice or whether there are | > vendor plans to do so in the future. | | Georgios: I am not sure if this is the email that encaptured | that discussion. | It will be good if we can get more input from operators on | the usage of DSCP for ECMP. | However, as I already mentioned, a sentence associated with | this issue can be included in the text! | | | | > | > | > > > | > > > 1. extra con: router has to read the existing marking | > before writing | > > > (otherwise AM can over-write TM) | > | > please remember this con. | | Georgios: I do not understand this statement! A router has to | know what it has to mark and how. Or am I missing something | here? The same holds for marking ECN bits! | | | > | > 2. given Toby's | > > > option has some thoughts about what happens in the | event that the | > > > PCN-boundary-nodes are misconfigured (and let 11 pkts | sneak in or | > > > out), I think it would also be fair for your option to | have some | > > > thinking about what happens if PCN-boundary-node | misconfiguration | > > > allows a "PCN DSCP" to sneak in /out. | > > | > > Georgios: I think that the issue of what happens if a | > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to | sneak in | > > /out does not cause any problem for the DSCP based | options, because | > > | > > when no agreements exist between two neighboring PCN domains the | > > PCN-ingress-node will have to remark all incoming packets | > to the DSCP | > > value used for PCN capable not congested (PCN) indication. | > | > To clarify: I was saying there should be text (not whether it | > was a con) | | Best regards, | Georgios | | > | > | | | _______________________________________________ | PCN mailing list | PCN@ietf.org | http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 09:00:42 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CD928CAEF; Thu, 21 Feb 2008 09:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 zSivZQeBz0ty; Thu, 21 Feb 2008 09:00:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145C028CB3A; Thu, 21 Feb 2008 08:59:22 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF5428CB07 for ; Thu, 21 Feb 2008 08:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8nTrbW+gQeP for ; Thu, 21 Feb 2008 08:59:17 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6126128CB77 for ; Thu, 21 Feb 2008 08:56:06 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1LGtqb6021852 for ; Thu, 21 Feb 2008 18:56:00 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:55:56 +0200 Received: from [192.168.255.2] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:55:55 +0200 Message-Id: <6E2F4FD9-4DB7-4077-88D2-26B1E23AB764@nokia.com> From: Lars Eggert To: pcn IETF In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 18:55:52 +0200 References: <026F8EEDAD2C4342A993203088C1FC050260E1C4@esealmw109.eemea.ericsson.se> <75A199C5D243C741BF3D3F1EBCEF9BA503B345B6@E03MVZ1-UKDY.domain1.systemhost.net> <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl> <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 21 Feb 2008 16:55:56.0024 (UTC) FILETIME=[A0271F80:01C874AA] X-Nokia-AV: Clean Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, just a quick reminder that any use of the ECN bits by PCN absolutely must conform to RFC4774. Lars _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 23:14:41 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544303A6806; Thu, 21 Feb 2008 23:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.267 X-Spam-Level: X-Spam-Status: No, score=0.267 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 kuE0tXdE54tU; Thu, 21 Feb 2008 23:14:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AD63A685E; Thu, 21 Feb 2008 23:14:39 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3933A685E for ; Thu, 21 Feb 2008 23:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIYPHFbgNUu3 for ; Thu, 21 Feb 2008 23:14:36 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id EA2B33A6806 for ; Thu, 21 Feb 2008 23:14:35 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DCCB0198EE6; Fri, 22 Feb 2008 08:14:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CCD53198EE9; Fri, 22 Feb 2008 08:14:30 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 33101198EE4; Fri, 22 Feb 2008 08:14:25 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1M7EPV10768; Fri, 22 Feb 2008 08:14:25 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id C8220C81C1; Fri, 22 Feb 2008 08:14:24 +0100 (CET) Message-ID: <47BE7612.2060003@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 08:13:22 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, toby.moncaster@bt.com wrote: > Hi Ingemar, > > This is exactly the sort of thing Phil and I were hoping to trigger > people to write in response to our email. We are hoping to settle on > what are the real options people support for the encoding and why they > support them... > > Just one quick observation - if we have to leave 11 unchanged across the > PCN domain this will mean that such packets can't be PCN marked and thus > they should not form part of any PCN aggregate (in my opinion)... > I find they should be metered, but never remarked. Regards, Michael > Toby > > >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: 21 February 2008 13:47 >> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >> Subject: RE: [PCN] FW: RE: PCN encoding option >> >> Hi >> >> Putting the issues with "leakage" aside (I cannot tell how >> serious this >> problem really is). >> >> I would prefer to sacrifice the end to end ECN semantics for >> the ECT(0) >> and ECT(1) codepoints instead of the ECN-CE codepoint. The reason is >> simply that from a realtime communication scenario with out of band >> signaling it is always possible to negotiate the use of ECN CE mark in >> wireless nodes by means of eg. SIP signaling. Also, atleast >> for RTP/UDP >> I see little use for ECN nonce like it is done with TCP as >> this is more >> or less an anti-cheat feature. >> >> >> One would then end up with a PCN encoding schema like (I >> beleve option 5 >> in figure 1 in the PCN encoding draft) is the closest. >> >> PCN Meaning ECN DSCP >> ============================= >> PCN capable 00 PCN 1 >> Admission Mark 01 PCN 1 >> Termination Mark 10 PCN 1 >> >> At PCN ingress the ECT(0) and ECT(1) codepoints should be set to "00", >> likewise at PCN egress. ECN CE is however left untouched. This has the >> effect that routers will be able to set ECN-CE on packets before they >> enter the first PCN domain, after exit from the PCN domain >> routers are >> not anymore allowed to set ECN-CE (RFC4774 section 4.3). >> Wireless nodes >> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can however set >> ECN CE as this is can be managed by out of band signaling. >> >> Besides this I would prefer a solution that maintains end to end >> semantics regardless of DSCP value. If one consider DCCP we don't know >> today if it will be a best effort traffic alternatiive or if >> there is a >> benefit with it even with QoS and DCCP can use ECN nonce. >> >> /Ingemar >> >> >> >>> -----Original Message----- >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> Sent: den 21 februari 2008 11:07 >>> To: philip.eardley@bt.com; Ingemar Johansson S >>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>> Subject: RE: [PCN] FW: RE: PCN encoding option >>> >>> >>> Hi Phil, Hi all >>> >>> In order to make a selection of one single (or two) options, >>> I think that the PCN WG should get the possibility to study >>> all the possible and PCN relevant encoding options. >>> >>> In my opinion the goal of the encoding draft is to provide >>> this information to the PCN-WG. >>> Based on this information the PCN WG can discuss and decide >>> which of the options should be used. >>> >>> The below text is copied from the current version of the >>> encoding draft! >>> Four options are described! >>> Please note that the encoding draft should list all relevant >>> options with advantages and disadvantages. >>> >>> Phil and Ingemar, if you can add advantages, disadvantages to >>> the ones already mentioned below in Section 3.2.1 and 3.2.2 >>> of the encoding draft, please do. >>> >>> Best regards, >>> Georgios >>> >>> >>> >>> 3.2. Encoding Using DSCP Field >>> >>> In this type of encoding and transport method the congestion and >>> precongestion information is encoded into the 6 DSCP >>> >> bits that are >> >>> transported in the IP header of the data packets. Four possible >>> alternatives can be distinguished, as can be seen in >>> >> Figure 3, with >> >>> details provided by draft-westberg-pcn-load-control-02.txt [4]. >>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>> >> need three >> >>> additional DSCP values and Option 10 needs four additional DSCP >>> values. Note that all additional and experimental DSCP >>> >> values are >> >>> representing and are associated with the same PHB. The 1st, 2nd, >>> 3rd, and 4th DSCP values are representing DSCP values that are >>> assigned by IANA as DSCP experimental values, see RFC 2211 [9]. >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> --------- >>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 >>> |Add DSCP 4 >>> || >>> ===========++==========+===========+===========+===========+== >>> =========| >>> | Option 6 || Not-PCN | PCN | AM/TM | NA | >>> NA | >>> |-----------++----------+-----------+-----------+-----------+- >>> ----------| >>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | >>> NA | >>> |-----------++----------+-----------+-----------+-----------+- >>> ----------| >>> | Option 8 || Not-PCN | PCN | AM | TM | >>> NA | >>> |-----------++----------+-----------+-----------+-----------+- >>> ----------| >>> | Option 9 || Not-PCN | PCN | AM | TM | >>> AfM | >>> >>> -------------------------------------------------------------- >>> --------- >>> >>> Notes: Not-PCN means the packet is not PCN capable. >>> >>> Figure 2: Encoding of PCN Information Using DSCP Field >>> >>> 3.2.1. Benefits of Using DSCP Field >>> >>> The main benefit of using the DSCP field is that it is not >>> affecting >>> the end-to-end ECN semantics and therefore the issues >>> >> and concerns >> >>> raised in RFC 4774 [22] are not applicable for this >>> encoding scheme. >>> Another benefit is related to the fact that all 4 DSCP encoding >>> options depicted in Figure 2 can support the PCN capable not >>> congested (PCN) indication, the admission control (AM) and flow >>> termination (TM) encoding states. In addition Option 8 >>> >> and 10 can >> >>> support the ECMP solution. >>> >>> 3.2.2. Drawbacks of Using DSCP Field >>> >>> This type of encoding needs to use per PHB, in addition to the >>> original DSCP and depending on the encoding option used, >>> >> one, two, >> >>> three, or four DSCP values, respectively. These additional DSCP >>> values can be taken from the DSCP values that are not defined by >>> standards action, see RFC 2211 [9]. Note that all the additional >>> DSCP values are representing and are associated with one >>> >> PHB. The >> >>> value of this DSCP/PHB can either follow a standards >>> action or use a >>> value that is applied for experimental or local use. It >>> is important >>> to note that the number of the DSCP values used for local or >>> experimental use is restricted and therefore the number of >>> different >>> PHBs supported in the PCN domain will also be restricted. >>> >>> Best regards, >>> Georgios >>> >>> >>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>> >>> Behalf Of >>> >>>> philip.eardley@bt.com >>>> Sent: donderdag 21 februari 2008 10:24 >>>> To: ingemar.s.johansson@ericsson.com; >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>> >>>> Ingemar >>>> >>>> Re >>>> >>>> >>>>> consider the end to end ECN usecases >>>>> >>>> I believe that the emails below about Toby's encoding proposal do >>>> indeed already consider ECN. Would appreciate it if you could add >>>> further text to it to better capture the (pros and) cons. >>>> >>>> >>>>> more DSCP codepoints >>>>> >>>> I think you may be proposing an encoding that uses all dscp >>>> >>> codepoints >>> >>>> (as has Georgios). That's fine - but a "1 pager" >>>> setting out this option with its pros and cons (ie >>>> >> similar to what >> >>>> toby has done below) is needed I think! At the moment we >>>> >>> have lots of >>> >>>> options on the table - in order to reach a decision, I >>>> >>> think we really >>> >>>> need very few options but with their pros and cons better >>>> >> laid out. >> >>>> I haven't managed to get to your draft yet, sorry (next week >>>> hopefully) >>>> - >>>> Thanks >>>> Phil >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ingemar Johansson S >>>>> >>> [mailto:ingemar.s.johansson@ericsson.com] >>> >>>>> Sent: 21 February 2008 06:43 >>>>> To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; >>>>> Moncaster,T,Toby,CXR9 R >>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>> >>>>> Hi >>>>> >>>>> In this discussion it may be well worth the effort to >>>>> >>>> consider the end >>>> >>>>> to end ECN usecases that we foresee when considering >>>>> >> various PCN >> >>>>> encoding options. >>>>> Please have a look at >>>>> >>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>>> for a discussion of the use cases and a motivation to why >>>>> >>> end to end >>> >>>> ECN >>>> >>>>> should be maintained even across PCN nodes even for non >>>>> >>> DF traffic. >>> >>>>> That said I realize that there is some cost associated to >>>>> >>>> the use of >>>> >>>>> DSCP codepoints, this cost must however be weighted against >>>>> >>>> the risk >>>> >>>>> that other functionality like end to end ECN semantics is >>>>> >>> probably >>> >>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>> >> bits. It is >> >>>> easy >>>> >>>>> to see that if one wish to maintain support for end to >>>>> >>> end ECN (not >>> >>>> only >>>> >>>>> in DF class) it simply costs more DSCP codepoints. >>>>> I am not explicitly saying don't do this or that but I wish >>>>> >>>> to avoid a >>>> >>>>> situation where one technique has to be avoided in favor of >>>>> >>>> the other >>>> as >>>> >>>>> it may in the end prevent deployment of both. If one can >>>>> >>>> yank the two >>>> >>>>> together so much the better even though the cost e.g in >>>>> >> DSCP code >> >>>> points >>>> >>>>> is regarded as higher. >>>>> >>>>> Regards >>>>> Ingemar >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>> >>>> On Behalf >>>> >>>>>> Of philip.eardley@bt.com >>>>>> Sent: den 20 februari 2008 17:44 >>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Thanks Michael >>>>>> >>>>>> I agree with you that spending one DSCP value is quite >>>>>> >>> expensive >>> >>>>>> (not two, as one is spent anyway). I think the only way >>>>>> >>> of really >>> >>>>>> assessing this properly is for an alternative proposal >>>>>> >>> (with pros >>> >>>>>> and cons) that requires only one DSCP. >>>>>> Then we can see where the consensus for the best (/least bad) >>>>>> encoding lies. Personally I have no axe to grind for >>>>>> >> or against >> >>>>>> either - I'm not yet convinced that the proposal below is >>>>>> >>>> definitely >>>> >>>>>> the way to go, until compared it in detail with other >>>>>> >> proposals. >> >>>>>> So I think it would be really useful to have a "1 pager" for >>>>>> alternative >>>>>> proposal(s) before the ietf, as I think this would make >>>>>> >>>> Philadelphia >>>> >>>>>> discussions more productive. >>>>>> >>>>>> >>>>>> You're correct about one of the motivations >>>>>> >>> (advantages) for this >>> >>>>>> proposal (although I don't think the issues are exactly >>>>>> >>>> the same for >>>> >>>>>> 11 leakage as 01/10 leakage). >>>>>> >>>>>> Consider the case where 11 leaks out of the PCN >>>>>> >> domain. If the >> >>>>>> endpoints are ECN capable, then the ECN source slows >>>>>> >>> down (seems >>> >>>>>> reasonable). If they're not capable, then the impact >>>>>> >>> outside the >>> >>>>>> domain isn't any different to what would happen without >>>>>> >>>> PCN-domain. >>>> >>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>> Then this will lead to either flow admission or >>>>>> >>>> termination in the >>>> >>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>> >>>> (I believe) >>>> >>>>>> at least as severe as would happen in an all ECN world. >>>>>> You mention that this might not terminate the ECN-11 flow >>>>>> specifically (some other flow might get terminated instead). >>>>>> I think this is true, though it also implies that [1] >>>>>> >>>> end-to-end ECN >>>> >>>>>> & PCN on the same flow really is useful, [2] the mechanism (eg >>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>> >>>> PCN-domain >>>> >>>>>> has also failed, [3] the flows which are terminated >>>>>> >> aren't other >> >>>>>> ECN-11 flows that are also getting in due to the same >>>>>> misconfiguration. >>>>>> >>>>>> Best wishes >>>>>> Phil >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Menth >>>>>>> >> [mailto:menth@informatik.uni-wuerzburg.de] >> >>>>>>> Sent: 20 February 2008 10:50 >>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>> >>> khchan@nortel.com; >>> >>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>> >>> steven.blake@ericsson.com; >>> >>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>> >>>>>>> Hi Toby, >>>>>>> >>>>>>> as I understand the proposal, the motivation is to >>>>>>> >>> avoid 01/10 >>> >>>>>>> codepoints as it is not good if they leak out of the >>>>>>> >>>> network since >>>> >>>>>> 01/10 >>>>>> >>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>> >>>>>> However, there is >>>>>> >>>>>>> the same problem with 11 marking, i.e. 11-packets may not be >>>>>>> >>>> dropped >>>> >>>>>> by >>>>>> >>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>> >>> are not ECN >>> >>>>>> capable. >>>>>> >>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>> >>>>>> guaranteed that >>>>>> >>>>>>> exactly the marked flow going over an overloaded ECN node is >>>>>>> >>>>>> terminated. >>>>>> >>>>>>> Just want to say that this solution wants to solve a >>>>>>> >>>> problem that >>>> >>>>>> exists >>>>>> >>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>> >>>>>> does not fully >>>>>> >>>>>>> achieve that objective. Therefore, I feel that >>>>>>> >>> spending two DSCP >>> >>>>>> values >>>>>> >>>>>>> is quite expensive. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> toby.moncaster@bt.com wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>> >>>>>> and feel we >>>>>> may >>>>>> >>>>>>>> have lit upon a neat solution that seems to have >>>>>>>> >>> lots of pros >>> >>>> and >>>> >>>>>> few >>>>>> >>>>>>>> cons... In order to get a better feeling for this >>>>>>>> >>>>>> proposal I will go >>>>>> >>>>>>>> through the simplified version without Affected >>>>>>>> >>> marking first: >>> >>>>>>>> PCN Meaning ECN DSCP >>>>>>>> >>>>>>>> PCN capable 00 PCN 1 >>>>>>>> Admission Mark 11 PCN 1 >>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>> >>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>> >> the same PCN >> >>>>>> behaviour >>>>>> >>>>>>>> aggregate. >>>>>>>> >>>>>>>> Pros: >>>>>>>> o Termination marking and admission marking are >>>>>>>> >>> independent, >>> >>>> eg >>>> >>>>>>>> termination marking can be done after a packet has been >>>>>>>> >>>> admission >>>> >>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>> >>>>>> having to read >>>>>> the >>>>>> >>>>>>>> packet's PCN marking first, which is easier to >>>>>>>> >>>> implement. (Note: >>>> >>>>>>>> Over-writing a TM with AM is not allowed for 3SM & CL, see >>>>>>>> draft-charny-pcn-comparison.) >>>>>>>> >>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>> >>>>>> ECT(1). This is >>>>>> >>>>>>>> safest option if packets leak outside the PCN >>>>>>>> >> region, due to >> >>>> some >>>> >>>>>> fort >>>>>> >>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>> >>>>>> for a single >>>>>> >>>>>>>> domain deployment of PCN). >>>>>>>> >>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>> >>>>>> ECT(1) in some >>>>>> >>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>> >>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>> >>>> simply reads its >>>> >>>>>> DSCP. >>>>>> >>>>>>>> This is probably easier than checking both its DSCP & ECN >>>>>>>> >>>> fields. >>>> >>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>> >>>> could deploy SM >>>> >>>>>>>> initially and later AM/TM. Just add the second >>>>>>>> >>>>>> DSCP. >>>>>> >>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>> >>>> too horrific >>>> >>>>>>>> happens. >>>>>>>> [2] could just deploy admission control & add >>>>>>>> >>>> termination later, >>>> >>>>>> just by >>>>>> >>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>> >>>>>> encoding and check >>>>>> for >>>>>> >>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>> >>>>>>>> Cons: >>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>> >>>> (Although >>>> >>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>> >>> all PCN BAs?) >>> >>>>>>>> o If a packet (in a PCN flow) arrives at the egress with >>>>>>>> >>>>>> its ECN = >>>>>> 11 >>>>>> >>>>>>>> and it really is required to preserve this info across the >>>>>>>> >>>>>> PCN-domain, >>>>>> >>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>> >>>>>> (tunnelling) >>>>>> >>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>> >>>>>> (ECMP) that uses >>>>>> the >>>>>> >>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>> >>>> of packets >>>> >>>>>> within >>>>>> >>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>> >>> they know of >>> >>>> an >>>> >>>>>> ECMP >>>>>> >>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>> >>>>>> mis-ordering >>>>>> when >>>>>> >>>>>>>> there is termination marking may be acceptable >>>>>>>> >>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>> >>>> modified as >>>> >>>>>>>> follows: >>>>>>>> >>>>>>>> PCN Meaning ECN DSCP >>>>>>>> >>>>>>>> PCN capable 00 PCN 1 >>>>>>>> Admission Mark 11 PCN 1 >>>>>>>> Termination Mark 11 PCN 2 >>>>>>>> Affected Mark 00 PCN 2 >>>>>>>> >>>>>>>> The pros for this scheme are broadly similar to the above. >>>>>>>> >>>> However >>>> >>>>>> there >>>>>> >>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>> >>>> affected >>>> >>>>>> marked >>>>>> >>>>>>>> and a later node is doing admission marking then it will >>>>>>>> >>>>>> reset the >>>>>> >>>>>>>> affected mark to a termination mark. Work would be needed >>>>>>>> >>>>>> to see if >>>>>> this >>>>>> >>>>>>>> skews the results and causes significant >>>>>>>> >> over-termination or >> >>>> not. >>>> >>>>>>>> Please could people look through this scheme and >>>>>>>> >>>> highlight any >>>> >>>>>>>> additional concerns that they may have (and extra >>>>>>>> >>>> benefits too). >>>> I >>>> >>>>>> would >>>>>> >>>>>>>> like to get as many opinions as possible. >>>>>>>> >>>>>>>> What I want to avoid is people just emailing back with >>>>>>>> >>>>>> "why not try >>>>>> this >>>>>> >>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>> >>>> possible >>>> >>>>>>>> schemes on the table and people need to start putting >>>>>>>> >>>> down much >>>> >>>>>> clearer >>>>>> >>>>>>>> pros and cons for the schemes they support... So it could >>>>>>>> >>>>>> be good to >>>>>> >>>>>>>> have a similar "one page" email about a specific >>>>>>>> >> scheme that >> >>>> only >>>> >>>>>> uses >>>>>> >>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>> >>>>>>>> Toby >>>>>>>> >>>>>>>> >> ____________________________________________________________________ >> >>>>>>>> Toby Moncaster, Networks Research >>>>>>>> >>>>>> Centre, BT >>>>>> >>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>> >> 1473 648734 >> >>>>>>> -- >>>>>>> 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 >>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>> >>>>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 21 23:44:08 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF9E3A6957; Thu, 21 Feb 2008 23:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 hhNTyhaXudZi; Thu, 21 Feb 2008 23:44:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAD03A6839; Thu, 21 Feb 2008 23:44:05 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F243A6839 for ; Thu, 21 Feb 2008 23:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx5Id6shtBxM for ; Thu, 21 Feb 2008 23:44:03 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id B6CF33A681C for ; Thu, 21 Feb 2008 23:44:02 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Fri, 22 Feb 2008 08:43:48 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 08:43:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 08:44:46 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8BC6A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAVM5RAAAkVJUAAlwGEw References: <001801c87471$80e42160$810c5982@dynamic.ewi.utwente.nl><75A199C5D243C741BF3D3F1EBCEF9BA503B345B9@E03MVZ1-UKDY.domain1.systemhost.net> <002001c87490$0825b260$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 22 Feb 2008 07:43:47.0969 (UTC) FILETIME=[A8B4D710:01C87526] Cc: pcn@ietf.org Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, hi Georgios, a misconfigured router could let some DSCPs or ECN codepoints slip out and another misconfigured router could let the very same packets slip in without a change. This is all ugly. I'd prefer discussions like this to be dropped. Misconfigurations may end with ugly things. If they are dangerous, there should be no configuration options (an example related to the subject: once a router talks BGP on an interface, it will never forward a PCN coloured packet across that interface. If this policy is supposed to change and misconfigs should be avoided, one could ask particular BGP based solutions to signal and enable PCN by that on the interface and so on). Regards, Ruediger > 2. given Toby's > > > option has some thoughts about what happens in the event that the > > > PCN-boundary-nodes are misconfigured (and let 11 pkts sneak in or > > > out), I think it would also be fair for your option to have some > > > thinking about what happens if PCN-boundary-node misconfiguration > > > allows a "PCN DSCP" to sneak in /out. > > > > Georgios: I think that the issue of what happens if a > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to sneak in > > /out does not cause any problem for the DSCP based options, because > > > > when no agreements exist between two neighboring PCN domains the > > PCN-ingress-node will have to remark all incoming packets > to the DSCP > > value used for PCN capable not congested (PCN) indication. > > To clarify: I was saying there should be text (not whether it > was a con) _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 00:23:24 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C143428C5EA; Fri, 22 Feb 2008 00:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, 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 zP7VkiM539V2; Fri, 22 Feb 2008 00:23:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120B43A6C50; Fri, 22 Feb 2008 00:23:21 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861053A6C4A for ; Fri, 22 Feb 2008 00:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMPAZghEf2vE for ; Fri, 22 Feb 2008 00:23:17 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E116A28C17D for ; Fri, 22 Feb 2008 00:22:38 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E103921A5C; Fri, 22 Feb 2008 09:22:33 +0100 (CET) X-AuditID: c1b4fb3e-aa1febb000000b15-06-47be86497b97 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B8DD120069; Fri, 22 Feb 2008 09:22:33 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:22:33 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 09:22:32 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAS8CrAABOGu8AAjPyiw References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> From: "Ingemar Johansson S" To: , , X-OriginalArrivalTime: 22 Feb 2008 08:22:33.0156 (UTC) FILETIME=[12A03840:01C8752C] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Answers inline > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: den 21 februari 2008 15:34 > To: Ingemar Johansson S; karagian@cs.utwente.nl; philip.eardley@bt.com > Cc: pcn@ietf.org; bob.briscoe@bt.com; > menth@informatik.uni-wuerzburg.de > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi Ingemar, > > This is exactly the sort of thing Phil and I were hoping to > trigger people to write in response to our email. We are > hoping to settle on what are the real options people support > for the encoding and why they support them... > > Just one quick observation - if we have to leave 11 unchanged > across the PCN domain this will mean that such packets can't > be PCN marked and thus they should not form part of any PCN > aggregate (in my opinion)... Realized that this is one (big) problem, thanks for pointing out this issue. The next alternative is then PCN Meaning ECN DSCP ============================= PCN capable 00 PCN 1 Admission Mark 01 PCN 1 Termination Mark 10 PCN 1 PCN capable+ECN CE 00 PCN 2 AM+ECN CE 01 PCN 2 TM+ECN CE 10 PCN 2 I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN egress PCN 2 is mapped back to the ECN bits as ECN-CE "11". AfM can also be included in the schema I know this does cost an extra DSCP codepoint and it completely disregards the leakage issue, also it possible that this alternative or something similar is given in the PCN encoding draft but I don't think so as this alternative does not preserve the end to end ECN semantics to 100%, rather it assumes that negotiation of the use of ECN is done out of band at session setup. /Ingemar > Toby > > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: 21 February 2008 13:47 > > To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > > menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > Hi > > > > Putting the issues with "leakage" aside (I cannot tell how serious > > this problem really is). > > > > I would prefer to sacrifice the end to end ECN semantics for the > > ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The > > reason is simply that from a realtime communication > scenario with out > > of band signaling it is always possible to negotiate the > use of ECN CE > > mark in wireless nodes by means of eg. SIP signaling. Also, atleast > > for RTP/UDP I see little use for ECN nonce like it is done > with TCP as > > this is more or less an anti-cheat feature. > > > > > > One would then end up with a PCN encoding schema like (I > > beleve option 5 > > in figure 1 in the PCN encoding draft) is the closest. > > > > PCN Meaning ECN DSCP > > ============================= > > PCN capable 00 PCN 1 > > Admission Mark 01 PCN 1 > > Termination Mark 10 PCN 1 > > > > At PCN ingress the ECT(0) and ECT(1) codepoints should be > set to "00", > > likewise at PCN egress. ECN CE is however left untouched. > This has the > > effect that routers will be able to set ECN-CE on packets > before they > > enter the first PCN domain, after exit from the PCN domain > > routers are > > not anymore allowed to set ECN-CE (RFC4774 section 4.3). > > Wireless nodes > > such as LTE-eNB (Long Term Evolution-Enhanced Node B) can > however set > > ECN CE as this is can be managed by out of band signaling. > > > > Besides this I would prefer a solution that maintains end to end > > semantics regardless of DSCP value. If one consider DCCP we > don't know > > today if it will be a best effort traffic alternatiive or if > > there is a > > benefit with it even with QoS and DCCP can use ECN nonce. > > > > /Ingemar > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: den 21 februari 2008 11:07 > > > To: philip.eardley@bt.com; Ingemar Johansson S > > > Cc: pcn@ietf.org; bob.briscoe@bt.com; > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > > Hi Phil, Hi all > > > > > > In order to make a selection of one single (or two) options, > > > I think that the PCN WG should get the possibility to study > > > all the possible and PCN relevant encoding options. > > > > > > In my opinion the goal of the encoding draft is to provide > > > this information to the PCN-WG. > > > Based on this information the PCN WG can discuss and decide > > > which of the options should be used. > > > > > > The below text is copied from the current version of the > > > encoding draft! > > > Four options are described! > > > Please note that the encoding draft should list all relevant > > > options with advantages and disadvantages. > > > > > > Phil and Ingemar, if you can add advantages, disadvantages to > > > the ones already mentioned below in Section 3.2.1 and 3.2.2 > > > of the encoding draft, please do. > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > 3.2. Encoding Using DSCP Field > > > > > > In this type of encoding and transport method the > congestion and > > > precongestion information is encoded into the 6 DSCP > > bits that are > > > transported in the IP header of the data packets. > Four possible > > > alternatives can be distinguished, as can be seen in > > Figure 3, with > > > details provided by draft-westberg-pcn-load-control-02.txt [4]. > > > Option 7 needs 2 additional DSCP values, Options 8 and 9 > > need three > > > additional DSCP values and Option 10 needs four additional DSCP > > > values. Note that all additional and experimental DSCP > > values are > > > representing and are associated with the same PHB. > The 1st, 2nd, > > > 3rd, and 4th DSCP values are representing DSCP values that are > > > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > --------- > > > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 > > > |Add DSCP 4 > > > || > > > ===========++==========+===========+===========+===========+== > > > =========| > > > | Option 6 || Not-PCN | PCN | AM/TM | NA | > > > NA | > > > |-----------++----------+-----------+-----------+-----------+- > > > ----------| > > > | Option 7 || Not-PCN | PCN | AM/TM | AfM | > > > NA | > > > |-----------++----------+-----------+-----------+-----------+- > > > ----------| > > > | Option 8 || Not-PCN | PCN | AM | TM | > > > NA | > > > |-----------++----------+-----------+-----------+-----------+- > > > ----------| > > > | Option 9 || Not-PCN | PCN | AM | TM | > > > AfM | > > > > > > -------------------------------------------------------------- > > > --------- > > > > > > Notes: Not-PCN means the packet is not PCN capable. > > > > > > Figure 2: Encoding of PCN Information Using DSCP Field > > > > > > 3.2.1. Benefits of Using DSCP Field > > > > > > The main benefit of using the DSCP field is that it is not > > > affecting > > > the end-to-end ECN semantics and therefore the issues > > and concerns > > > raised in RFC 4774 [22] are not applicable for this > > > encoding scheme. > > > Another benefit is related to the fact that all 4 DSCP encoding > > > options depicted in Figure 2 can support the PCN capable not > > > congested (PCN) indication, the admission control (AM) and flow > > > termination (TM) encoding states. In addition Option 8 > > and 10 can > > > support the ECMP solution. > > > > > > 3.2.2. Drawbacks of Using DSCP Field > > > > > > This type of encoding needs to use per PHB, in addition to the > > > original DSCP and depending on the encoding option used, > > one, two, > > > three, or four DSCP values, respectively. These > additional DSCP > > > values can be taken from the DSCP values that are not > defined by > > > standards action, see RFC 2211 [9]. Note that all the > additional > > > DSCP values are representing and are associated with one > > PHB. The > > > value of this DSCP/PHB can either follow a standards > > > action or use a > > > value that is applied for experimental or local use. It > > > is important > > > to note that the number of the DSCP values used for local or > > > experimental use is restricted and therefore the number of > > > different > > > PHBs supported in the PCN domain will also be restricted. > > > > > > Best regards, > > > Georgios > > > > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > > Behalf Of > > > > philip.eardley@bt.com > > > > Sent: donderdag 21 februari 2008 10:24 > > > > To: ingemar.s.johansson@ericsson.com; > > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > Ingemar > > > > > > > > Re > > > > > > > > > consider the end to end ECN usecases > > > > > > > > I believe that the emails below about Toby's encoding > proposal do > > > > indeed already consider ECN. Would appreciate it if you > could add > > > > further text to it to better capture the (pros and) cons. > > > > > > > > > more DSCP codepoints > > > > I think you may be proposing an encoding that uses all dscp > > > codepoints > > > > (as has Georgios). That's fine - but a "1 pager" > > > > setting out this option with its pros and cons (ie > > similar to what > > > > toby has done below) is needed I think! At the moment we > > > have lots of > > > > options on the table - in order to reach a decision, I > > > think we really > > > > need very few options but with their pros and cons better > > laid out. > > > > > > > > > > > > I haven't managed to get to your draft yet, sorry (next week > > > > hopefully) > > > > - > > > > Thanks > > > > Phil > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ingemar Johansson S > > > [mailto:ingemar.s.johansson@ericsson.com] > > > > > Sent: 21 February 2008 06:43 > > > > > To: Eardley,PL,Philip,CXR9 R; > menth@informatik.uni-wuerzburg.de; > > > > > Moncaster,T,Toby,CXR9 R > > > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > > > Hi > > > > > > > > > > In this discussion it may be well worth the effort to > > > > consider the end > > > > > to end ECN usecases that we foresee when considering > > various PCN > > > > > encoding options. > > > > > Please have a look at > > > > > > > > > > > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > > > for a discussion of the use cases and a motivation to why > > > end to end > > > > ECN > > > > > should be maintained even across PCN nodes even for non > > > DF traffic. > > > > > That said I realize that there is some cost associated to > > > > the use of > > > > > DSCP codepoints, this cost must however be weighted against > > > > the risk > > > > > that other functionality like end to end ECN semantics is > > > probably > > > > > broken if a PCN encoding option "fiddles" with the ECN > > bits. It is > > > > easy > > > > > to see that if one wish to maintain support for end to > > > end ECN (not > > > > only > > > > > in DF class) it simply costs more DSCP codepoints. > > > > > I am not explicitly saying don't do this or that but I wish > > > > to avoid a > > > > > situation where one technique has to be avoided in favor of > > > > the other > > > > as > > > > > it may in the end prevent deployment of both. If one can > > > > yank the two > > > > > together so much the better even though the cost e.g in > > DSCP code > > > > points > > > > > is regarded as higher. > > > > > > > > > > Regards > > > > > Ingemar > > > > > > > > > > > -----Original Message----- > > > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > > On Behalf > > > > > > Of philip.eardley@bt.com > > > > > > Sent: den 20 februari 2008 17:44 > > > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > > > > > Thanks Michael > > > > > > > > > > > > I agree with you that spending one DSCP value is quite > > > expensive > > > > > > (not two, as one is spent anyway). I think the only way > > > of really > > > > > > assessing this properly is for an alternative proposal > > > (with pros > > > > > > and cons) that requires only one DSCP. > > > > > > Then we can see where the consensus for the best > (/least bad) > > > > > > encoding lies. Personally I have no axe to grind for > > or against > > > > > > either - I'm not yet convinced that the proposal below is > > > > definitely > > > > > > the way to go, until compared it in detail with other > > proposals. > > > > > > > > > > > > So I think it would be really useful to have a "1 > pager" for > > > > > > alternative > > > > > > proposal(s) before the ietf, as I think this would make > > > > Philadelphia > > > > > > discussions more productive. > > > > > > > > > > > > > > > > > > You're correct about one of the motivations > > > (advantages) for this > > > > > > proposal (although I don't think the issues are exactly > > > > the same for > > > > > > 11 leakage as 01/10 leakage). > > > > > > > > > > > > Consider the case where 11 leaks out of the PCN > > domain. If the > > > > > > endpoints are ECN capable, then the ECN source slows > > > down (seems > > > > > > reasonable). If they're not capable, then the impact > > > outside the > > > > > > domain isn't any different to what would happen without > > > > PCN-domain. > > > > > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > > > Then this will lead to either flow admission or > > > > termination in the > > > > > > PCN-domain. These are both safe, in that the reaction is > > > > (I believe) > > > > > > at least as severe as would happen in an all ECN world. > > > > > > You mention that this might not terminate the ECN-11 flow > > > > > > specifically (some other flow might get terminated instead). > > > > > > I think this is true, though it also implies that [1] > > > > end-to-end ECN > > > > > > & PCN on the same flow really is useful, [2] the > mechanism (eg > > > > > > tunnelling) to carry ECN-marking transparently across the > > > > PCN-domain > > > > > > has also failed, [3] the flows which are terminated > > aren't other > > > > > > ECN-11 flows that are also getting in due to the same > > > > > > misconfiguration. > > > > > > > > > > > > Best wishes > > > > > > Phil > > > > > > > -----Original Message----- > > > > > > > From: Michael Menth > > [mailto:menth@informatik.uni-wuerzburg.de] > > > > > > > Sent: 20 February 2008 10:50 > > > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > > > khchan@nortel.com; > > > > > > > babiarz@nortel.com; sob@harvard.edu; > > > steven.blake@ericsson.com; > > > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > > > > > Hi Toby, > > > > > > > > > > > > > > as I understand the proposal, the motivation is to > > > avoid 01/10 > > > > > > > codepoints as it is not good if they leak out of the > > > > network since > > > > > > 01/10 > > > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > > > However, there is > > > > > > > the same problem with 11 marking, i.e. 11-packets > may not be > > > > dropped > > > > > > by > > > > > > > ECN nodes outside the PCN domain although endpoints > > > are not ECN > > > > > > capable. > > > > > > > Even if 11-packets trigger flow termination, it is not > > > > > > guaranteed that > > > > > > > exactly the marked flow going over an overloaded > ECN node is > > > > > > terminated. > > > > > > > Just want to say that this solution wants to solve a > > > > problem that > > > > > > exists > > > > > > > only in case of misconfiguration (leaking packets), but > > > > > > does not fully > > > > > > > achieve that objective. Therefore, I feel that > > > spending two DSCP > > > > > > values > > > > > > > is quite expensive. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > > > and feel we > > > > > > may > > > > > > > > have lit upon a neat solution that seems to have > > > lots of pros > > > > and > > > > > > few > > > > > > > > cons... In order to get a better feeling for this > > > > > > proposal I will go > > > > > > > > through the simplified version without Affected > > > marking first: > > > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > > Admission Mark 11 PCN 1 > > > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with > > the same PCN > > > > > > behaviour > > > > > > > > aggregate. > > > > > > > > > > > > > > > > Pros: > > > > > > > > o Termination marking and admission marking are > > > independent, > > > > eg > > > > > > > > termination marking can be done after a packet has been > > > > admission > > > > > > > > marked. Therefore a router can write AM or TM without > > > > > > having to read > > > > > > the > > > > > > > > packet's PCN marking first, which is easier to > > > > implement. (Note: > > > > > > > > Over-writing a TM with AM is not allowed for > 3SM & CL, see > > > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > > > ECT(1). This is > > > > > > > > safest option if packets leak outside the PCN > > region, due to > > > > some > > > > > > fort > > > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > > > for a single > > > > > > > > domain deployment of PCN). > > > > > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > > > ECT(1) in some > > > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > > > simply reads its > > > > > > DSCP. > > > > > > > > This is probably easier than checking both its > DSCP & ECN > > > > fields. > > > > > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > > > could deploy SM > > > > > > > > initially and later AM/TM. Just add the second > > > > > > DSCP. > > > > > > > > If a router isn't upgraded at the same time nothing > > > > too horrific > > > > > > > > happens. > > > > > > > > [2] could just deploy admission control & add > > > > termination later, > > > > > > just by > > > > > > > > adding a new DSCP; there is no need to change the > > > > > > encoding and check > > > > > > for > > > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > > > > > Cons: > > > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > > > (Although > > > > > > > > possibly it's OK to use the same DSCP for TM for > > > all PCN BAs?) > > > > > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the > egress with > > > > > > its ECN = > > > > > > 11 > > > > > > > > and it really is required to preserve this info > across the > > > > > > PCN-domain, > > > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > > > (tunnelling) > > > > > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > > > (ECMP) that uses > > > > > > the > > > > > > > > DSCP to select routes, then there may be mis-ordering > > > > of packets > > > > > > within > > > > > > > > a flow. This may be OK as (1) no-one has yet said > > > they know of > > > > an > > > > > > ECMP > > > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > > > mis-ordering > > > > > > when > > > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > > > modified as > > > > > > > > follows: > > > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > > Admission Mark 11 PCN 1 > > > > > > > > Termination Mark 11 PCN 2 > > > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > > > > > The pros for this scheme are broadly similar to > the above. > > > > However > > > > > > there > > > > > > > > is a new con which may or may not matter: If a packet is > > > > affected > > > > > > marked > > > > > > > > and a later node is doing admission marking then it will > > > > > > reset the > > > > > > > > affected mark to a termination mark. Work would > be needed > > > > > > to see if > > > > > > this > > > > > > > > skews the results and causes significant > > over-termination or > > > > not. > > > > > > > > > > > > > > > > Please could people look through this scheme and > > > > highlight any > > > > > > > > additional concerns that they may have (and extra > > > > benefits too). > > > > I > > > > > > would > > > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > > > "why not try > > > > > > this > > > > > > > > scheme instead". Currently we seem to have a plethora of > > > > possible > > > > > > > > schemes on the table and people need to start putting > > > > down much > > > > > > clearer > > > > > > > > pros and cons for the schemes they support... > So it could > > > > > > be good to > > > > > > > > have a similar "one page" email about a specific > > scheme that > > > > only > > > > > > uses > > > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > > > > > Toby > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > Toby Moncaster, > Networks Research > > > > > > Centre, BT > > > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > > 1473 648734 > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > 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 > > > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > _______________________________________________ > > > > PCN mailing list > > > > PCN@ietf.org > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 01:14:40 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A5C28C104; Fri, 22 Feb 2008 01:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.89 X-Spam-Level: X-Spam-Status: No, score=0.89 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, 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 RRpA2IYt6cfc; Fri, 22 Feb 2008 01:14:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4068D28C148; Fri, 22 Feb 2008 01:14:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4CF28C124 for ; Fri, 22 Feb 2008 01:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ3Z6BDkGAva for ; Fri, 22 Feb 2008 01:14:35 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id BE27128C148 for ; Fri, 22 Feb 2008 01:14:34 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 63320198DF1; Fri, 22 Feb 2008 10:14:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 56123198DE9; Fri, 22 Feb 2008 10:14:30 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B5689198D76; Fri, 22 Feb 2008 10:14:24 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1M9EOV11718; Fri, 22 Feb 2008 10:14:24 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 6BB8AC81C1; Fri, 22 Feb 2008 10:14:24 +0100 (CET) Message-ID: <47BE9231.2010602@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 10:13:21 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ingemar Johansson S References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, this solution essentially spends a DSCP to save 11-marking through the PCN domain and allow them to be PCN-marked. This is a rather high price, in particular because the PCN packets need to be remarked to 00. This has the consequence that ECN capability is lost for the rest of the path. Therefore, I opt for one of the two versions 1) discard 11-marked PCN packets before entering the PCN domain OR 2) let them go through the PCN domain, take them into account for metering, but do not remark them. The first option loses ECN capability for PCN traffic, the second option keeps it on the subpath before entering the PCN domain. Regards, Michael Ingemar Johansson S wrote: > Hi > > Answers inline > > >> -----Original Message----- >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >> Sent: den 21 februari 2008 15:34 >> To: Ingemar Johansson S; karagian@cs.utwente.nl; philip.eardley@bt.com >> Cc: pcn@ietf.org; bob.briscoe@bt.com; >> menth@informatik.uni-wuerzburg.de >> Subject: RE: [PCN] FW: RE: PCN encoding option >> >> Hi Ingemar, >> >> This is exactly the sort of thing Phil and I were hoping to >> trigger people to write in response to our email. We are >> hoping to settle on what are the real options people support >> for the encoding and why they support them... >> >> Just one quick observation - if we have to leave 11 unchanged >> across the PCN domain this will mean that such packets can't >> be PCN marked and thus they should not form part of any PCN >> aggregate (in my opinion)... >> > > Realized that this is one (big) problem, thanks for pointing out this > issue. > > The next alternative is then > PCN Meaning ECN DSCP > ============================= > PCN capable 00 PCN 1 > Admission Mark 01 PCN 1 > Termination Mark 10 PCN 1 > > PCN capable+ECN CE 00 PCN 2 > AM+ECN CE 01 PCN 2 > TM+ECN CE 10 PCN 2 > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN egress PCN 2 > is mapped back to the ECN bits as ECN-CE "11". > > AfM can also be included in the schema > > I know this does cost an extra DSCP codepoint and it completely > disregards the leakage issue, also it possible that this alternative or > something similar is given in the PCN encoding draft but I don't think > so as this alternative does not preserve the end to end ECN semantics to > 100%, rather it assumes that negotiation of the use of ECN is done out > of band at session setup. > > /Ingemar > > > >> Toby >> >> >>> -----Original Message----- >>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >>> Sent: 21 February 2008 13:47 >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>> Subject: RE: [PCN] FW: RE: PCN encoding option >>> >>> Hi >>> >>> Putting the issues with "leakage" aside (I cannot tell how serious >>> this problem really is). >>> >>> I would prefer to sacrifice the end to end ECN semantics for the >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The >>> reason is simply that from a realtime communication >>> >> scenario with out >> >>> of band signaling it is always possible to negotiate the >>> >> use of ECN CE >> >>> mark in wireless nodes by means of eg. SIP signaling. Also, atleast >>> for RTP/UDP I see little use for ECN nonce like it is done >>> >> with TCP as >> >>> this is more or less an anti-cheat feature. >>> >>> >>> One would then end up with a PCN encoding schema like (I >>> beleve option 5 >>> in figure 1 in the PCN encoding draft) is the closest. >>> >>> PCN Meaning ECN DSCP >>> ============================= >>> PCN capable 00 PCN 1 >>> Admission Mark 01 PCN 1 >>> Termination Mark 10 PCN 1 >>> >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>> >> set to "00", >> >>> likewise at PCN egress. ECN CE is however left untouched. >>> >> This has the >> >>> effect that routers will be able to set ECN-CE on packets >>> >> before they >> >>> enter the first PCN domain, after exit from the PCN domain >>> routers are >>> not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>> Wireless nodes >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>> >> however set >> >>> ECN CE as this is can be managed by out of band signaling. >>> >>> Besides this I would prefer a solution that maintains end to end >>> semantics regardless of DSCP value. If one consider DCCP we >>> >> don't know >> >>> today if it will be a best effort traffic alternatiive or if >>> there is a >>> benefit with it even with QoS and DCCP can use ECN nonce. >>> >>> /Ingemar >>> >>> >>> >>>> -----Original Message----- >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>> Sent: den 21 februari 2008 11:07 >>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>> >>>> >>>> Hi Phil, Hi all >>>> >>>> In order to make a selection of one single (or two) options, >>>> I think that the PCN WG should get the possibility to study >>>> all the possible and PCN relevant encoding options. >>>> >>>> In my opinion the goal of the encoding draft is to provide >>>> this information to the PCN-WG. >>>> Based on this information the PCN WG can discuss and decide >>>> which of the options should be used. >>>> >>>> The below text is copied from the current version of the >>>> encoding draft! >>>> Four options are described! >>>> Please note that the encoding draft should list all relevant >>>> options with advantages and disadvantages. >>>> >>>> Phil and Ingemar, if you can add advantages, disadvantages to >>>> the ones already mentioned below in Section 3.2.1 and 3.2.2 >>>> of the encoding draft, please do. >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>> 3.2. Encoding Using DSCP Field >>>> >>>> In this type of encoding and transport method the >>>> >> congestion and >> >>>> precongestion information is encoded into the 6 DSCP >>>> >>> bits that are >>> >>>> transported in the IP header of the data packets. >>>> >> Four possible >> >>>> alternatives can be distinguished, as can be seen in >>>> >>> Figure 3, with >>> >>>> details provided by draft-westberg-pcn-load-control-02.txt [4]. >>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>> >>> need three >>> >>>> additional DSCP values and Option 10 needs four additional DSCP >>>> values. Note that all additional and experimental DSCP >>>> >>> values are >>> >>>> representing and are associated with the same PHB. >>>> >> The 1st, 2nd, >> >>>> 3rd, and 4th DSCP values are representing DSCP values that are >>>> assigned by IANA as DSCP experimental values, see RFC 2211 [9]. >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------- >>>> --------- >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 >>>> |Add DSCP 4 >>>> || >>>> ===========++==========+===========+===========+===========+== >>>> =========| >>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | >>>> NA | >>>> |-----------++----------+-----------+-----------+-----------+- >>>> ----------| >>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | >>>> NA | >>>> |-----------++----------+-----------+-----------+-----------+- >>>> ----------| >>>> | Option 8 || Not-PCN | PCN | AM | TM | >>>> NA | >>>> |-----------++----------+-----------+-----------+-----------+- >>>> ----------| >>>> | Option 9 || Not-PCN | PCN | AM | TM | >>>> AfM | >>>> >>>> -------------------------------------------------------------- >>>> --------- >>>> >>>> Notes: Not-PCN means the packet is not PCN capable. >>>> >>>> Figure 2: Encoding of PCN Information Using DSCP Field >>>> >>>> 3.2.1. Benefits of Using DSCP Field >>>> >>>> The main benefit of using the DSCP field is that it is not >>>> affecting >>>> the end-to-end ECN semantics and therefore the issues >>>> >>> and concerns >>> >>>> raised in RFC 4774 [22] are not applicable for this >>>> encoding scheme. >>>> Another benefit is related to the fact that all 4 DSCP encoding >>>> options depicted in Figure 2 can support the PCN capable not >>>> congested (PCN) indication, the admission control (AM) and flow >>>> termination (TM) encoding states. In addition Option 8 >>>> >>> and 10 can >>> >>>> support the ECMP solution. >>>> >>>> 3.2.2. Drawbacks of Using DSCP Field >>>> >>>> This type of encoding needs to use per PHB, in addition to the >>>> original DSCP and depending on the encoding option used, >>>> >>> one, two, >>> >>>> three, or four DSCP values, respectively. These >>>> >> additional DSCP >> >>>> values can be taken from the DSCP values that are not >>>> >> defined by >> >>>> standards action, see RFC 2211 [9]. Note that all the >>>> >> additional >> >>>> DSCP values are representing and are associated with one >>>> >>> PHB. The >>> >>>> value of this DSCP/PHB can either follow a standards >>>> action or use a >>>> value that is applied for experimental or local use. It >>>> is important >>>> to note that the number of the DSCP values used for local or >>>> experimental use is restricted and therefore the number of >>>> different >>>> PHBs supported in the PCN domain will also be restricted. >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>> >>>> Behalf Of >>>> >>>>> philip.eardley@bt.com >>>>> Sent: donderdag 21 februari 2008 10:24 >>>>> To: ingemar.s.johansson@ericsson.com; >>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>> >>>>> Ingemar >>>>> >>>>> Re >>>>> >>>>> >>>>>> consider the end to end ECN usecases >>>>>> >>>>> I believe that the emails below about Toby's encoding >>>>> >> proposal do >> >>>>> indeed already consider ECN. Would appreciate it if you >>>>> >> could add >> >>>>> further text to it to better capture the (pros and) cons. >>>>> >>>>> >>>>>> more DSCP codepoints >>>>>> >>>>> I think you may be proposing an encoding that uses all dscp >>>>> >>>> codepoints >>>> >>>>> (as has Georgios). That's fine - but a "1 pager" >>>>> setting out this option with its pros and cons (ie >>>>> >>> similar to what >>> >>>>> toby has done below) is needed I think! At the moment we >>>>> >>>> have lots of >>>> >>>>> options on the table - in order to reach a decision, I >>>>> >>>> think we really >>>> >>>>> need very few options but with their pros and cons better >>>>> >>> laid out. >>> >>>>> I haven't managed to get to your draft yet, sorry (next week >>>>> hopefully) >>>>> - >>>>> Thanks >>>>> Phil >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ingemar Johansson S >>>>>> >>>> [mailto:ingemar.s.johansson@ericsson.com] >>>> >>>>>> Sent: 21 February 2008 06:43 >>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>> >> menth@informatik.uni-wuerzburg.de; >> >>>>>> Moncaster,T,Toby,CXR9 R >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Hi >>>>>> >>>>>> In this discussion it may be well worth the effort to >>>>>> >>>>> consider the end >>>>> >>>>>> to end ECN usecases that we foresee when considering >>>>>> >>> various PCN >>> >>>>>> encoding options. >>>>>> Please have a look at >>>>>> >>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>>>> for a discussion of the use cases and a motivation to why >>>>>> >>>> end to end >>>> >>>>> ECN >>>>> >>>>>> should be maintained even across PCN nodes even for non >>>>>> >>>> DF traffic. >>>> >>>>>> That said I realize that there is some cost associated to >>>>>> >>>>> the use of >>>>> >>>>>> DSCP codepoints, this cost must however be weighted against >>>>>> >>>>> the risk >>>>> >>>>>> that other functionality like end to end ECN semantics is >>>>>> >>>> probably >>>> >>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>> >>> bits. It is >>> >>>>> easy >>>>> >>>>>> to see that if one wish to maintain support for end to >>>>>> >>>> end ECN (not >>>> >>>>> only >>>>> >>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>> I am not explicitly saying don't do this or that but I wish >>>>>> >>>>> to avoid a >>>>> >>>>>> situation where one technique has to be avoided in favor of >>>>>> >>>>> the other >>>>> as >>>>> >>>>>> it may in the end prevent deployment of both. If one can >>>>>> >>>>> yank the two >>>>> >>>>>> together so much the better even though the cost e.g in >>>>>> >>> DSCP code >>> >>>>> points >>>>> >>>>>> is regarded as higher. >>>>>> >>>>>> Regards >>>>>> Ingemar >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>> >>>>> On Behalf >>>>> >>>>>>> Of philip.eardley@bt.com >>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>> >>>>>>> Thanks Michael >>>>>>> >>>>>>> I agree with you that spending one DSCP value is quite >>>>>>> >>>> expensive >>>> >>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>> >>>> of really >>>> >>>>>>> assessing this properly is for an alternative proposal >>>>>>> >>>> (with pros >>>> >>>>>>> and cons) that requires only one DSCP. >>>>>>> Then we can see where the consensus for the best >>>>>>> >> (/least bad) >> >>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>> >>> or against >>> >>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>> >>>>> definitely >>>>> >>>>>>> the way to go, until compared it in detail with other >>>>>>> >>> proposals. >>> >>>>>>> So I think it would be really useful to have a "1 >>>>>>> >> pager" for >> >>>>>>> alternative >>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>> >>>>> Philadelphia >>>>> >>>>>>> discussions more productive. >>>>>>> >>>>>>> >>>>>>> You're correct about one of the motivations >>>>>>> >>>> (advantages) for this >>>> >>>>>>> proposal (although I don't think the issues are exactly >>>>>>> >>>>> the same for >>>>> >>>>>>> 11 leakage as 01/10 leakage). >>>>>>> >>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>> >>> domain. If the >>> >>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>> >>>> down (seems >>>> >>>>>>> reasonable). If they're not capable, then the impact >>>>>>> >>>> outside the >>>> >>>>>>> domain isn't any different to what would happen without >>>>>>> >>>>> PCN-domain. >>>>> >>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>> Then this will lead to either flow admission or >>>>>>> >>>>> termination in the >>>>> >>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>> >>>>> (I believe) >>>>> >>>>>>> at least as severe as would happen in an all ECN world. >>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>> specifically (some other flow might get terminated instead). >>>>>>> I think this is true, though it also implies that [1] >>>>>>> >>>>> end-to-end ECN >>>>> >>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>> >> mechanism (eg >> >>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>> >>>>> PCN-domain >>>>> >>>>>>> has also failed, [3] the flows which are terminated >>>>>>> >>> aren't other >>> >>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>> misconfiguration. >>>>>>> >>>>>>> Best wishes >>>>>>> Phil >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Michael Menth >>>>>>>> >>> [mailto:menth@informatik.uni-wuerzburg.de] >>> >>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>> >>>> khchan@nortel.com; >>>> >>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>> >>>> steven.blake@ericsson.com; >>>> >>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>> >>>>>>>> Hi Toby, >>>>>>>> >>>>>>>> as I understand the proposal, the motivation is to >>>>>>>> >>>> avoid 01/10 >>>> >>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>> >>>>> network since >>>>> >>>>>>> 01/10 >>>>>>> >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>> >>>>>>> However, there is >>>>>>> >>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>> >> may not be >> >>>>> dropped >>>>> >>>>>>> by >>>>>>> >>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>> >>>> are not ECN >>>> >>>>>>> capable. >>>>>>> >>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>> >>>>>>> guaranteed that >>>>>>> >>>>>>>> exactly the marked flow going over an overloaded >>>>>>>> >> ECN node is >> >>>>>>> terminated. >>>>>>> >>>>>>>> Just want to say that this solution wants to solve a >>>>>>>> >>>>> problem that >>>>> >>>>>>> exists >>>>>>> >>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>> >>>>>>> does not fully >>>>>>> >>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>> >>>> spending two DSCP >>>> >>>>>>> values >>>>>>> >>>>>>>> is quite expensive. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>> >>>>>>> and feel we >>>>>>> may >>>>>>> >>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>> >>>> lots of pros >>>> >>>>> and >>>>> >>>>>>> few >>>>>>> >>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>> >>>>>>> proposal I will go >>>>>>> >>>>>>>>> through the simplified version without Affected >>>>>>>>> >>>> marking first: >>>> >>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>> >>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>> >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>> >>> the same PCN >>> >>>>>>> behaviour >>>>>>> >>>>>>>>> aggregate. >>>>>>>>> >>>>>>>>> Pros: >>>>>>>>> o Termination marking and admission marking are >>>>>>>>> >>>> independent, >>>> >>>>> eg >>>>> >>>>>>>>> termination marking can be done after a packet has been >>>>>>>>> >>>>> admission >>>>> >>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>> >>>>>>> having to read >>>>>>> the >>>>>>> >>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>> >>>>> implement. (Note: >>>>> >>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>> >> 3SM & CL, see >> >>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>> >>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>> >>>>>>> ECT(1). This is >>>>>>> >>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>> >>> region, due to >>> >>>>> some >>>>> >>>>>>> fort >>>>>>> >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>> >>>>>>> for a single >>>>>>> >>>>>>>>> domain deployment of PCN). >>>>>>>>> >>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>> >>>>>>> ECT(1) in some >>>>>>> >>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>> >>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>> >>>>> simply reads its >>>>> >>>>>>> DSCP. >>>>>>> >>>>>>>>> This is probably easier than checking both its >>>>>>>>> >> DSCP & ECN >> >>>>> fields. >>>>> >>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>> >>>>> could deploy SM >>>>> >>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>> >>>>>>> DSCP. >>>>>>> >>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>> >>>>> too horrific >>>>> >>>>>>>>> happens. >>>>>>>>> [2] could just deploy admission control & add >>>>>>>>> >>>>> termination later, >>>>> >>>>>>> just by >>>>>>> >>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>> >>>>>>> encoding and check >>>>>>> for >>>>>>> >>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>> >>>>>>>>> Cons: >>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>> >>>>> (Although >>>>> >>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>> >>>> all PCN BAs?) >>>> >>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>> >> egress with >> >>>>>>> its ECN = >>>>>>> 11 >>>>>>> >>>>>>>>> and it really is required to preserve this info >>>>>>>>> >> across the >> >>>>>>> PCN-domain, >>>>>>> >>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>> >>>>>>> (tunnelling) >>>>>>> >>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>> >>>>>>> (ECMP) that uses >>>>>>> the >>>>>>> >>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>> >>>>> of packets >>>>> >>>>>>> within >>>>>>> >>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>> >>>> they know of >>>> >>>>> an >>>>> >>>>>>> ECMP >>>>>>> >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>> >>>>>>> mis-ordering >>>>>>> when >>>>>>> >>>>>>>>> there is termination marking may be acceptable >>>>>>>>> >>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>> >>>>> modified as >>>>> >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>> >>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>> >>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>> >> the above. >> >>>>> However >>>>> >>>>>>> there >>>>>>> >>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>> >>>>> affected >>>>> >>>>>>> marked >>>>>>> >>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>> >>>>>>> reset the >>>>>>> >>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>> >> be needed >> >>>>>>> to see if >>>>>>> this >>>>>>> >>>>>>>>> skews the results and causes significant >>>>>>>>> >>> over-termination or >>> >>>>> not. >>>>> >>>>>>>>> Please could people look through this scheme and >>>>>>>>> >>>>> highlight any >>>>> >>>>>>>>> additional concerns that they may have (and extra >>>>>>>>> >>>>> benefits too). >>>>> I >>>>> >>>>>>> would >>>>>>> >>>>>>>>> like to get as many opinions as possible. >>>>>>>>> >>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>> >>>>>>> "why not try >>>>>>> this >>>>>>> >>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>> >>>>> possible >>>>> >>>>>>>>> schemes on the table and people need to start putting >>>>>>>>> >>>>> down much >>>>> >>>>>>> clearer >>>>>>> >>>>>>>>> pros and cons for the schemes they support... >>>>>>>>> >> So it could >> >>>>>>> be good to >>>>>>> >>>>>>>>> have a similar "one page" email about a specific >>>>>>>>> >>> scheme that >>> >>>>> only >>>>> >>>>>>> uses >>>>>>> >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>> >>>>>>>>> Toby >>>>>>>>> >>>>>>>>> >>> ____________________________________________________________________ >>> >>>>>>>>> Toby Moncaster, >>>>>>>>> >> Networks Research >> >>>>>>> Centre, BT >>>>>>> >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>> >>> 1473 648734 >>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> PCN mailing list >>>>> PCN@ietf.org >>>>> http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 01:39:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F7E28C235; Fri, 22 Feb 2008 01:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.531 X-Spam-Level: X-Spam-Status: No, score=0.531 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, 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 7fRNptNOnDH9; Fri, 22 Feb 2008 01:39:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484693A6C48; Fri, 22 Feb 2008 01:39:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E29A28C0E3 for ; Fri, 22 Feb 2008 01:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArpkNlvwvBEL for ; Fri, 22 Feb 2008 01:39:00 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 82FA03A6C16 for ; Fri, 22 Feb 2008 01:38:59 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 22 Feb 2008 10:38:40 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 10:38:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 10:39:38 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8BD51@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47BE9231.2010602@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Ach1M119RThbW6rpSqSGhbljzj9rRwAAzj2Q References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se><026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 22 Feb 2008 09:38:40.0176 (UTC) FILETIME=[B4C82B00:01C87536] Cc: pcn@ietf.org Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, I support your views and prefer 2), as it seems more user friendly. Regards, Ruediger | -----Original Message----- | From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] | Sent: Friday, February 22, 2008 10:13 AM | To: Ingemar Johansson S | Cc: pcn@ietf.org; bob.briscoe@bt.com | Subject: Re: [PCN] FW: RE: PCN encoding option | | Hi Ingemar, | | this solution essentially spends a DSCP to save 11-marking | through the PCN domain and allow them to be PCN-marked. This | is a rather high price, in particular because the PCN packets | need to be remarked to 00. This has the consequence that ECN | capability is lost for the rest of the path. | | Therefore, I opt for one of the two versions | 1) discard 11-marked PCN packets before entering the PCN domain OR | 2) let them go through the PCN domain, take them into account | for metering, but do not remark them. | The first option loses ECN capability for PCN traffic, the | second option keeps it on the subpath before entering the PCN domain. | | Regards, | | Michael | | Ingemar Johansson S wrote: | > Hi | > | > Answers inline | > | > | >> -----Original Message----- | >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] | >> Sent: den 21 februari 2008 15:34 | >> To: Ingemar Johansson S; karagian@cs.utwente.nl; | >> philip.eardley@bt.com | >> Cc: pcn@ietf.org; bob.briscoe@bt.com; | >> menth@informatik.uni-wuerzburg.de | >> Subject: RE: [PCN] FW: RE: PCN encoding option | >> | >> Hi Ingemar, | >> | >> This is exactly the sort of thing Phil and I were hoping | to trigger | >> people to write in response to our email. We are hoping to | settle on | >> what are the real options people support for the encoding and why | >> they support them... | >> | >> Just one quick observation - if we have to leave 11 | unchanged across | >> the PCN domain this will mean that such packets can't be | PCN marked | >> and thus they should not form part of any PCN aggregate (in my | >> opinion)... | >> | > | > Realized that this is one (big) problem, thanks for | pointing out this | > issue. | > | > The next alternative is then | > PCN Meaning ECN DSCP | > ============================= | > PCN capable 00 PCN 1 | > Admission Mark 01 PCN 1 | > Termination Mark 10 PCN 1 | > | > PCN capable+ECN CE 00 PCN 2 | > AM+ECN CE 01 PCN 2 | > TM+ECN CE 10 PCN 2 | > | > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN | egress PCN | > 2 is mapped back to the ECN bits as ECN-CE "11". | > | > AfM can also be included in the schema | > | > I know this does cost an extra DSCP codepoint and it completely | > disregards the leakage issue, also it possible that this | alternative | > or something similar is given in the PCN encoding draft but I don't | > think so as this alternative does not preserve the end to end ECN | > semantics to 100%, rather it assumes that negotiation of the use of | > ECN is done out of band at session setup. | > | > /Ingemar | > | > | > | >> Toby | >> | >> | >>> -----Original Message----- | >>> From: Ingemar Johansson S | [mailto:ingemar.s.johansson@ericsson.com] | >>> Sent: 21 February 2008 13:47 | >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R | >>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; | >>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R | >>> Subject: RE: [PCN] FW: RE: PCN encoding option | >>> | >>> Hi | >>> | >>> Putting the issues with "leakage" aside (I cannot tell | how serious | >>> this problem really is). | >>> | >>> I would prefer to sacrifice the end to end ECN semantics for the | >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The | >>> reason is simply that from a realtime communication | >>> | >> scenario with out | >> | >>> of band signaling it is always possible to negotiate the | >>> | >> use of ECN CE | >> | >>> mark in wireless nodes by means of eg. SIP signaling. | Also, atleast | >>> for RTP/UDP I see little use for ECN nonce like it is done | >>> | >> with TCP as | >> | >>> this is more or less an anti-cheat feature. | >>> | >>> | >>> One would then end up with a PCN encoding schema like (I beleve | >>> option 5 in figure 1 in the PCN encoding draft) is the closest. | >>> | >>> PCN Meaning ECN DSCP | >>> ============================= | >>> PCN capable 00 PCN 1 | >>> Admission Mark 01 PCN 1 | >>> Termination Mark 10 PCN 1 | >>> | >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be | >>> | >> set to "00", | >> | >>> likewise at PCN egress. ECN CE is however left untouched. | >>> | >> This has the | >> | >>> effect that routers will be able to set ECN-CE on packets | >>> | >> before they | >> | >>> enter the first PCN domain, after exit from the PCN | domain routers | >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). | >>> Wireless nodes | >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can | >>> | >> however set | >> | >>> ECN CE as this is can be managed by out of band signaling. | >>> | >>> Besides this I would prefer a solution that maintains end to end | >>> semantics regardless of DSCP value. If one consider DCCP we | >>> | >> don't know | >> | >>> today if it will be a best effort traffic alternatiive or | if there | >>> is a benefit with it even with QoS and DCCP can use ECN nonce. | >>> | >>> /Ingemar | >>> | >>> | >>> | >>>> -----Original Message----- | >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | >>>> Sent: den 21 februari 2008 11:07 | >>>> To: philip.eardley@bt.com; Ingemar Johansson S | >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; | >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | >>>> Subject: RE: [PCN] FW: RE: PCN encoding option | >>>> | >>>> | >>>> Hi Phil, Hi all | >>>> | >>>> In order to make a selection of one single (or two) options, I | >>>> think that the PCN WG should get the possibility to | study all the | >>>> possible and PCN relevant encoding options. | >>>> | >>>> In my opinion the goal of the encoding draft is to provide this | >>>> information to the PCN-WG. | >>>> Based on this information the PCN WG can discuss and | decide which | >>>> of the options should be used. | >>>> | >>>> The below text is copied from the current version of the | encoding | >>>> draft! | >>>> Four options are described! | >>>> Please note that the encoding draft should list all relevant | >>>> options with advantages and disadvantages. | >>>> | >>>> Phil and Ingemar, if you can add advantages, | disadvantages to the | >>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the | >>>> encoding draft, please do. | >>>> | >>>> Best regards, | >>>> Georgios | >>>> | >>>> | >>>> | >>>> 3.2. Encoding Using DSCP Field | >>>> | >>>> In this type of encoding and transport method the | >>>> | >> congestion and | >> | >>>> precongestion information is encoded into the 6 DSCP | >>>> | >>> bits that are | >>> | >>>> transported in the IP header of the data packets. | >>>> | >> Four possible | >> | >>>> alternatives can be distinguished, as can be seen in | >>>> | >>> Figure 3, with | >>> | >>>> details provided by | draft-westberg-pcn-load-control-02.txt [4]. | >>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 | >>>> | >>> need three | >>> | >>>> additional DSCP values and Option 10 needs four | additional DSCP | >>>> values. Note that all additional and experimental DSCP | >>>> | >>> values are | >>> | >>>> representing and are associated with the same PHB. | >>>> | >> The 1st, 2nd, | >> | >>>> 3rd, and 4th DSCP values are representing DSCP values that are | >>>> assigned by IANA as DSCP experimental values, see RFC | 2211 [9]. | >>>> | >>>> | >>>> | >>>> | >>>> -------------------------------------------------------------- | >>>> --------- | >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 Add | >>>> |DSCP 4 | >>>> || | >>>> ===========++==========+===========+===========+===========+== | >>>> =========| | >>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | | >>>> NA | | >>>> |-----------++----------+-----------+-----------+-----------+- | >>>> ----------| | >>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | | >>>> NA | | >>>> |-----------++----------+-----------+-----------+-----------+- | >>>> ----------| | >>>> | Option 8 || Not-PCN | PCN | AM | TM | | >>>> NA | | >>>> |-----------++----------+-----------+-----------+-----------+- | >>>> ----------| | >>>> | Option 9 || Not-PCN | PCN | AM | TM | | >>>> AfM | | >>>> | >>>> -------------------------------------------------------------- | >>>> --------- | >>>> | >>>> Notes: Not-PCN means the packet is not PCN capable. | >>>> | >>>> Figure 2: Encoding of PCN Information Using DSCP Field | >>>> | >>>> 3.2.1. Benefits of Using DSCP Field | >>>> | >>>> The main benefit of using the DSCP field is that it is not | >>>> affecting | >>>> the end-to-end ECN semantics and therefore the issues | >>>> | >>> and concerns | >>> | >>>> raised in RFC 4774 [22] are not applicable for this encoding | >>>> scheme. | >>>> Another benefit is related to the fact that all 4 | DSCP encoding | >>>> options depicted in Figure 2 can support the PCN capable not | >>>> congested (PCN) indication, the admission control | (AM) and flow | >>>> termination (TM) encoding states. In addition Option 8 | >>>> | >>> and 10 can | >>> | >>>> support the ECMP solution. | >>>> | >>>> 3.2.2. Drawbacks of Using DSCP Field | >>>> | >>>> This type of encoding needs to use per PHB, in addition to the | >>>> original DSCP and depending on the encoding option used, | >>>> | >>> one, two, | >>> | >>>> three, or four DSCP values, respectively. These | >>>> | >> additional DSCP | >> | >>>> values can be taken from the DSCP values that are not | >>>> | >> defined by | >> | >>>> standards action, see RFC 2211 [9]. Note that all the | >>>> | >> additional | >> | >>>> DSCP values are representing and are associated with one | >>>> | >>> PHB. The | >>> | >>>> value of this DSCP/PHB can either follow a standards | action or | >>>> use a | >>>> value that is applied for experimental or local use. It is | >>>> important | >>>> to note that the number of the DSCP values used for local or | >>>> experimental use is restricted and therefore the number of | >>>> different | >>>> PHBs supported in the PCN domain will also be restricted. | >>>> | >>>> Best regards, | >>>> Georgios | >>>> | >>>> | >>>> | >>>>> -----Original Message----- | >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | >>>>> | >>>> Behalf Of | >>>> | >>>>> philip.eardley@bt.com | >>>>> Sent: donderdag 21 februari 2008 10:24 | >>>>> To: ingemar.s.johansson@ericsson.com; | >>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com | >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option | >>>>> | >>>>> Ingemar | >>>>> | >>>>> Re | >>>>> | >>>>> | >>>>>> consider the end to end ECN usecases | >>>>>> | >>>>> I believe that the emails below about Toby's encoding | >>>>> | >> proposal do | >> | >>>>> indeed already consider ECN. Would appreciate it if you | >>>>> | >> could add | >> | >>>>> further text to it to better capture the (pros and) cons. | >>>>> | >>>>> | >>>>>> more DSCP codepoints | >>>>>> | >>>>> I think you may be proposing an encoding that uses all dscp | >>>>> | >>>> codepoints | >>>> | >>>>> (as has Georgios). That's fine - but a "1 pager" | >>>>> setting out this option with its pros and cons (ie | >>>>> | >>> similar to what | >>> | >>>>> toby has done below) is needed I think! At the moment we | >>>>> | >>>> have lots of | >>>> | >>>>> options on the table - in order to reach a decision, I | >>>>> | >>>> think we really | >>>> | >>>>> need very few options but with their pros and cons better | >>>>> | >>> laid out. | >>> | >>>>> I haven't managed to get to your draft yet, sorry (next week | >>>>> hopefully) | >>>>> - | >>>>> Thanks | >>>>> Phil | >>>>> | >>>>> | >>>>> | >>>>>> -----Original Message----- | >>>>>> From: Ingemar Johansson S | >>>>>> | >>>> [mailto:ingemar.s.johansson@ericsson.com] | >>>> | >>>>>> Sent: 21 February 2008 06:43 | >>>>>> To: Eardley,PL,Philip,CXR9 R; | >>>>>> | >> menth@informatik.uni-wuerzburg.de; | >> | >>>>>> Moncaster,T,Toby,CXR9 R | >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R | >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option | >>>>>> | >>>>>> Hi | >>>>>> | >>>>>> In this discussion it may be well worth the effort to | >>>>>> | >>>>> consider the end | >>>>> | >>>>>> to end ECN usecases that we foresee when considering | >>>>>> | >>> various PCN | >>> | >>>>>> encoding options. | >>>>>> Please have a look at | >>>>>> | >>>>>> | >> | http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt | >> | >>>>>> for a discussion of the use cases and a motivation to why | >>>>>> | >>>> end to end | >>>> | >>>>> ECN | >>>>> | >>>>>> should be maintained even across PCN nodes even for non | >>>>>> | >>>> DF traffic. | >>>> | >>>>>> That said I realize that there is some cost associated to | >>>>>> | >>>>> the use of | >>>>> | >>>>>> DSCP codepoints, this cost must however be weighted against | >>>>>> | >>>>> the risk | >>>>> | >>>>>> that other functionality like end to end ECN semantics is | >>>>>> | >>>> probably | >>>> | >>>>>> broken if a PCN encoding option "fiddles" with the ECN | >>>>>> | >>> bits. It is | >>> | >>>>> easy | >>>>> | >>>>>> to see that if one wish to maintain support for end to | >>>>>> | >>>> end ECN (not | >>>> | >>>>> only | >>>>> | >>>>>> in DF class) it simply costs more DSCP codepoints. | >>>>>> I am not explicitly saying don't do this or that but I wish | >>>>>> | >>>>> to avoid a | >>>>> | >>>>>> situation where one technique has to be avoided in favor of | >>>>>> | >>>>> the other | >>>>> as | >>>>> | >>>>>> it may in the end prevent deployment of both. If one can | >>>>>> | >>>>> yank the two | >>>>> | >>>>>> together so much the better even though the cost e.g in | >>>>>> | >>> DSCP code | >>> | >>>>> points | >>>>> | >>>>>> is regarded as higher. | >>>>>> | >>>>>> Regards | >>>>>> Ingemar | >>>>>> | >>>>>> | >>>>>>> -----Original Message----- | >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] | >>>>>>> | >>>>> On Behalf | >>>>> | >>>>>>> Of philip.eardley@bt.com | >>>>>>> Sent: den 20 februari 2008 17:44 | >>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com | >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option | >>>>>>> | >>>>>>> Thanks Michael | >>>>>>> | >>>>>>> I agree with you that spending one DSCP value is quite | >>>>>>> | >>>> expensive | >>>> | >>>>>>> (not two, as one is spent anyway). I think the only way | >>>>>>> | >>>> of really | >>>> | >>>>>>> assessing this properly is for an alternative proposal | >>>>>>> | >>>> (with pros | >>>> | >>>>>>> and cons) that requires only one DSCP. | >>>>>>> Then we can see where the consensus for the best | >>>>>>> | >> (/least bad) | >> | >>>>>>> encoding lies. Personally I have no axe to grind for | >>>>>>> | >>> or against | >>> | >>>>>>> either - I'm not yet convinced that the proposal below is | >>>>>>> | >>>>> definitely | >>>>> | >>>>>>> the way to go, until compared it in detail with other | >>>>>>> | >>> proposals. | >>> | >>>>>>> So I think it would be really useful to have a "1 | >>>>>>> | >> pager" for | >> | >>>>>>> alternative | >>>>>>> proposal(s) before the ietf, as I think this would make | >>>>>>> | >>>>> Philadelphia | >>>>> | >>>>>>> discussions more productive. | >>>>>>> | >>>>>>> | >>>>>>> You're correct about one of the motivations | >>>>>>> | >>>> (advantages) for this | >>>> | >>>>>>> proposal (although I don't think the issues are exactly | >>>>>>> | >>>>> the same for | >>>>> | >>>>>>> 11 leakage as 01/10 leakage). | >>>>>>> | >>>>>>> Consider the case where 11 leaks out of the PCN | >>>>>>> | >>> domain. If the | >>> | >>>>>>> endpoints are ECN capable, then the ECN source slows | >>>>>>> | >>>> down (seems | >>>> | >>>>>>> reasonable). If they're not capable, then the impact | >>>>>>> | >>>> outside the | >>>> | >>>>>>> domain isn't any different to what would happen without | >>>>>>> | >>>>> PCN-domain. | >>>>> | >>>>>>> Consider the case where ECN-11 leaks into the PCN domain. | >>>>>>> Then this will lead to either flow admission or | >>>>>>> | >>>>> termination in the | >>>>> | >>>>>>> PCN-domain. These are both safe, in that the reaction is | >>>>>>> | >>>>> (I believe) | >>>>> | >>>>>>> at least as severe as would happen in an all ECN world. | >>>>>>> You mention that this might not terminate the ECN-11 flow | >>>>>>> specifically (some other flow might get terminated instead). | >>>>>>> I think this is true, though it also implies that [1] | >>>>>>> | >>>>> end-to-end ECN | >>>>> | >>>>>>> & PCN on the same flow really is useful, [2] the | >>>>>>> | >> mechanism (eg | >> | >>>>>>> tunnelling) to carry ECN-marking transparently across the | >>>>>>> | >>>>> PCN-domain | >>>>> | >>>>>>> has also failed, [3] the flows which are terminated | >>>>>>> | >>> aren't other | >>> | >>>>>>> ECN-11 flows that are also getting in due to the same | >>>>>>> misconfiguration. | >>>>>>> | >>>>>>> Best wishes | >>>>>>> Phil | >>>>>>> | >>>>>>>> -----Original Message----- | >>>>>>>> From: Michael Menth | >>>>>>>> | >>> [mailto:menth@informatik.uni-wuerzburg.de] | >>> | >>>>>>>> Sent: 20 February 2008 10:50 | >>>>>>>> To: Moncaster,T,Toby,CXR9 R | >>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; | >>>>>>>> | >>>> khchan@nortel.com; | >>>> | >>>>>>>> babiarz@nortel.com; sob@harvard.edu; | >>>>>>>> | >>>> steven.blake@ericsson.com; | >>>> | >>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R | >>>>>>>> Subject: Re: FW: RE: PCN encoding option | >>>>>>>> | >>>>>>>> Hi Toby, | >>>>>>>> | >>>>>>>> as I understand the proposal, the motivation is to | >>>>>>>> | >>>> avoid 01/10 | >>>> | >>>>>>>> codepoints as it is not good if they leak out of the | >>>>>>>> | >>>>> network since | >>>>> | >>>>>>> 01/10 | >>>>>>> | >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. | >>>>>>>> | >>>>>>> However, there is | >>>>>>> | >>>>>>>> the same problem with 11 marking, i.e. 11-packets | >>>>>>>> | >> may not be | >> | >>>>> dropped | >>>>> | >>>>>>> by | >>>>>>> | >>>>>>>> ECN nodes outside the PCN domain although endpoints | >>>>>>>> | >>>> are not ECN | >>>> | >>>>>>> capable. | >>>>>>> | >>>>>>>> Even if 11-packets trigger flow termination, it is not | >>>>>>>> | >>>>>>> guaranteed that | >>>>>>> | >>>>>>>> exactly the marked flow going over an overloaded | >>>>>>>> | >> ECN node is | >> | >>>>>>> terminated. | >>>>>>> | >>>>>>>> Just want to say that this solution wants to solve a | >>>>>>>> | >>>>> problem that | >>>>> | >>>>>>> exists | >>>>>>> | >>>>>>>> only in case of misconfiguration (leaking packets), but | >>>>>>>> | >>>>>>> does not fully | >>>>>>> | >>>>>>>> achieve that objective. Therefore, I feel that | >>>>>>>> | >>>> spending two DSCP | >>>> | >>>>>>> values | >>>>>>> | >>>>>>>> is quite expensive. | >>>>>>>> | >>>>>>>> Regards, | >>>>>>>> | >>>>>>>> Michael | >>>>>>>> | >>>>>>>> toby.moncaster@bt.com wrote: | >>>>>>>> | >>>>>>>>> All, | >>>>>>>>> | >>>>>>>>> Phil and I have just been discussing the encoding draft | >>>>>>>>> | >>>>>>> and feel we | >>>>>>> may | >>>>>>> | >>>>>>>>> have lit upon a neat solution that seems to have | >>>>>>>>> | >>>> lots of pros | >>>> | >>>>> and | >>>>> | >>>>>>> few | >>>>>>> | >>>>>>>>> cons... In order to get a better feeling for this | >>>>>>>>> | >>>>>>> proposal I will go | >>>>>>> | >>>>>>>>> through the simplified version without Affected | >>>>>>>>> | >>>> marking first: | >>>> | >>>>>>>>> PCN Meaning ECN DSCP | >>>>>>>>> | >>>>>>>>> PCN capable 00 PCN 1 | >>>>>>>>> Admission Mark 11 PCN 1 | >>>>>>>>> Termination Mark 11/00 PCN 2 | >>>>>>>>> | >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with | >>>>>>>>> | >>> the same PCN | >>> | >>>>>>> behaviour | >>>>>>> | >>>>>>>>> aggregate. | >>>>>>>>> | >>>>>>>>> Pros: | >>>>>>>>> o Termination marking and admission marking are | >>>>>>>>> | >>>> independent, | >>>> | >>>>> eg | >>>>> | >>>>>>>>> termination marking can be done after a packet has been | >>>>>>>>> | >>>>> admission | >>>>> | >>>>>>>>> marked. Therefore a router can write AM or TM without | >>>>>>>>> | >>>>>>> having to read | >>>>>>> the | >>>>>>> | >>>>>>>>> packet's PCN marking first, which is easier to | >>>>>>>>> | >>>>> implement. (Note: | >>>>> | >>>>>>>>> Over-writing a TM with AM is not allowed for | >>>>>>>>> | >> 3SM & CL, see | >> | >>>>>>>>> draft-charny-pcn-comparison.) | >>>>>>>>> | >>>>>>>>> o This scheme avoids giving semantics to ECT(0) and | >>>>>>>>> | >>>>>>> ECT(1). This is | >>>>>>> | >>>>>>>>> safest option if packets leak outside the PCN | >>>>>>>>> | >>> region, due to | >>> | >>>>> some | >>>>> | >>>>>>> fort | >>>>>>> | >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant | >>>>>>>>> | >>>>>>> for a single | >>>>>>> | >>>>>>>>> domain deployment of PCN). | >>>>>>>>> | >>>>>>>>> o It leaves open the possibility of using ECT(0) and | >>>>>>>>> | >>>>>>> ECT(1) in some | >>>>>>> | >>>>>>>>> mysterious way in a future end-to-end PCN deployment | >>>>>>>>> | >>>>>>>>> o For a router to classify a packet as PCN, it | >>>>>>>>> | >>>>> simply reads its | >>>>> | >>>>>>> DSCP. | >>>>>>> | >>>>>>>>> This is probably easier than checking both its | >>>>>>>>> | >> DSCP & ECN | >> | >>>>> fields. | >>>>> | >>>>>>>>> o Incremental deployment steps are possible [1] | >>>>>>>>> | >>>>> could deploy SM | >>>>> | >>>>>>>>> initially and later AM/TM. Just add the second | >>>>>>>>> | >>>>>>> DSCP. | >>>>>>> | >>>>>>>>> If a router isn't upgraded at the same time nothing | >>>>>>>>> | >>>>> too horrific | >>>>> | >>>>>>>>> happens. | >>>>>>>>> [2] could just deploy admission control & add | >>>>>>>>> | >>>>> termination later, | >>>>> | >>>>>>> just by | >>>>>>> | >>>>>>>>> adding a new DSCP; there is no need to change the | >>>>>>>>> | >>>>>>> encoding and check | >>>>>>> for | >>>>>>> | >>>>>>>>> backwards compatibility? Vice-versa is also ok? | >>>>>>>>> | >>>>>>>>> Cons: | >>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. | >>>>>>>>> | >>>>> (Although | >>>>> | >>>>>>>>> possibly it's OK to use the same DSCP for TM for | >>>>>>>>> | >>>> all PCN BAs?) | >>>> | >>>>>>>>> o If a packet (in a PCN flow) arrives at the | >>>>>>>>> | >> egress with | >> | >>>>>>> its ECN = | >>>>>>> 11 | >>>>>>> | >>>>>>>>> and it really is required to preserve this info | >>>>>>>>> | >> across the | >> | >>>>>>> PCN-domain, | >>>>>>> | >>>>>>>>> then some complexity is needed at the PCN-boundary-nodes | >>>>>>>>> | >>>>>>> (tunnelling) | >>>>>>> | >>>>>>>>> o If the PCN-domain is operating multipath routing | >>>>>>>>> | >>>>>>> (ECMP) that uses | >>>>>>> the | >>>>>>> | >>>>>>>>> DSCP to select routes, then there may be mis-ordering | >>>>>>>>> | >>>>> of packets | >>>>> | >>>>>>> within | >>>>>>> | >>>>>>>>> a flow. This may be OK as (1) no-one has yet said | >>>>>>>>> | >>>> they know of | >>>> | >>>>> an | >>>>> | >>>>>>> ECMP | >>>>>>> | >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of | >>>>>>>>> | >>>>>>> mis-ordering | >>>>>>> when | >>>>>>> | >>>>>>>>> there is termination marking may be acceptable | >>>>>>>>> | >>>>>>>>> If Affected marking is needed then the scheme can be | >>>>>>>>> | >>>>> modified as | >>>>> | >>>>>>>>> follows: | >>>>>>>>> | >>>>>>>>> PCN Meaning ECN DSCP | >>>>>>>>> | >>>>>>>>> PCN capable 00 PCN 1 | >>>>>>>>> Admission Mark 11 PCN 1 | >>>>>>>>> Termination Mark 11 PCN 2 | >>>>>>>>> Affected Mark 00 PCN 2 | >>>>>>>>> | >>>>>>>>> The pros for this scheme are broadly similar to | >>>>>>>>> | >> the above. | >> | >>>>> However | >>>>> | >>>>>>> there | >>>>>>> | >>>>>>>>> is a new con which may or may not matter: If a packet is | >>>>>>>>> | >>>>> affected | >>>>> | >>>>>>> marked | >>>>>>> | >>>>>>>>> and a later node is doing admission marking then it will | >>>>>>>>> | >>>>>>> reset the | >>>>>>> | >>>>>>>>> affected mark to a termination mark. Work would | >>>>>>>>> | >> be needed | >> | >>>>>>> to see if | >>>>>>> this | >>>>>>> | >>>>>>>>> skews the results and causes significant | >>>>>>>>> | >>> over-termination or | >>> | >>>>> not. | >>>>> | >>>>>>>>> Please could people look through this scheme and | >>>>>>>>> | >>>>> highlight any | >>>>> | >>>>>>>>> additional concerns that they may have (and extra | >>>>>>>>> | >>>>> benefits too). | >>>>> I | >>>>> | >>>>>>> would | >>>>>>> | >>>>>>>>> like to get as many opinions as possible. | >>>>>>>>> | >>>>>>>>> What I want to avoid is people just emailing back with | >>>>>>>>> | >>>>>>> "why not try | >>>>>>> this | >>>>>>> | >>>>>>>>> scheme instead". Currently we seem to have a plethora of | >>>>>>>>> | >>>>> possible | >>>>> | >>>>>>>>> schemes on the table and people need to start putting | >>>>>>>>> | >>>>> down much | >>>>> | >>>>>>> clearer | >>>>>>> | >>>>>>>>> pros and cons for the schemes they support... | >>>>>>>>> | >> So it could | >> | >>>>>>> be good to | >>>>>>> | >>>>>>>>> have a similar "one page" email about a specific | >>>>>>>>> | >>> scheme that | >>> | >>>>> only | >>>>> | >>>>>>> uses | >>>>>>> | >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. | >>>>>>>>> | >>>>>>>>> Toby | >>>>>>>>> | >>>>>>>>> | >>> | ____________________________________________________________________ | >>> | >>>>>>>>> Toby Moncaster, | >>>>>>>>> | >> Networks Research | >> | >>>>>>> Centre, BT | >>>>>>> | >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 | >>>>>>>>> | >>> 1473 648734 | >>> | >>>>>>>> -- | >>>>>>>> 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 | >>>>>>> http://www.ietf.org/mailman/listinfo/pcn | >>>>>>> | >>>>>>> | >>>>> _______________________________________________ | >>>>> PCN mailing list | >>>>> PCN@ietf.org | >>>>> http://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 | | _______________________________________________ | PCN mailing list | PCN@ietf.org | http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 01:47:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C8C28C235; Fri, 22 Feb 2008 01:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, 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 SRLPIEhWGJQV; Fri, 22 Feb 2008 01:47:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571583A6BD5; Fri, 22 Feb 2008 01:47:51 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440603A6BBF for ; Fri, 22 Feb 2008 01:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAMWEf4U+Sa8 for ; Fri, 22 Feb 2008 01:47:48 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 52A293A6BC0 for ; Fri, 22 Feb 2008 01:47:47 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E08E20EF0; Fri, 22 Feb 2008 10:46:49 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-54-47be9a09be15 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F364821AE5; Fri, 22 Feb 2008 10:46:48 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 10:46:48 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 10:46:47 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> In-Reply-To: <47BE9231.2010602@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Ach1M1XAo90jM546QBqcZZfyghqtugAAsXvQ References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 22 Feb 2008 09:46:48.0338 (UTC) FILETIME=[D7BFC720:01C87537] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi See inline /Ingemar > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: den 22 februari 2008 10:13 > To: Ingemar Johansson S > Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > Subject: Re: [PCN] FW: RE: PCN encoding option > > Hi Ingemar, > > this solution essentially spends a DSCP to save 11-marking > through the PCN domain and allow them to be PCN-marked. This > is a rather high price, in particular because the PCN packets > need to be remarked to 00. This has the consequence that ECN > capability is lost for the rest of the path. Not sure that I agree, yes the ECT(0), ECT(1) codepoints are lost and there goes also the ECN nonce and the "inband" ECN capability signaling. A router outside the PCN domain wont be able to set ECN-CE. However if the ECN capability is negotiated out of band for the wireless endpoints and the up and downlink wireless nodes, these will be ECN-CE capable but without the nonce capability. > Therefore, I opt for one of the two versions > 1) discard 11-marked PCN packets before entering the PCN domain OR > 2) let them go through the PCN domain, take them into account > for metering, but do not remark them. > The first option loses ECN capability for PCN traffic, the > second option keeps it on the subpath before entering the PCN domain. Not sure I follow here. What would option 2 look like? My interpretation: Packets with DSCP=EF enters the PCN domain, at ingress they are remarked as DSCP=PCN unless ECN="11", in which case DSCP=EF. What about ECN="01" or "01" will these also be kept as DSCP=EF or will the ECN bits be set to "00". Please explain. > > Regards, > > Michael > > Ingemar Johansson S wrote: > > Hi > > > > Answers inline > > > > > >> -----Original Message----- > >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > >> Sent: den 21 februari 2008 15:34 > >> To: Ingemar Johansson S; karagian@cs.utwente.nl; > >> philip.eardley@bt.com > >> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >> menth@informatik.uni-wuerzburg.de > >> Subject: RE: [PCN] FW: RE: PCN encoding option > >> > >> Hi Ingemar, > >> > >> This is exactly the sort of thing Phil and I were hoping > to trigger > >> people to write in response to our email. We are hoping to > settle on > >> what are the real options people support for the encoding and why > >> they support them... > >> > >> Just one quick observation - if we have to leave 11 > unchanged across > >> the PCN domain this will mean that such packets can't be > PCN marked > >> and thus they should not form part of any PCN aggregate (in my > >> opinion)... > >> > > > > Realized that this is one (big) problem, thanks for > pointing out this > > issue. > > > > The next alternative is then > > PCN Meaning ECN DSCP > > ============================= > > PCN capable 00 PCN 1 > > Admission Mark 01 PCN 1 > > Termination Mark 10 PCN 1 > > > > PCN capable+ECN CE 00 PCN 2 > > AM+ECN CE 01 PCN 2 > > TM+ECN CE 10 PCN 2 > > > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN > egress PCN > > 2 is mapped back to the ECN bits as ECN-CE "11". > > > > AfM can also be included in the schema > > > > I know this does cost an extra DSCP codepoint and it completely > > disregards the leakage issue, also it possible that this > alternative > > or something similar is given in the PCN encoding draft but I don't > > think so as this alternative does not preserve the end to end ECN > > semantics to 100%, rather it assumes that negotiation of the use of > > ECN is done out of band at session setup. > > > > /Ingemar > > > > > > > >> Toby > >> > >> > >>> -----Original Message----- > >>> From: Ingemar Johansson S > [mailto:ingemar.s.johansson@ericsson.com] > >>> Sent: 21 February 2008 13:47 > >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > >>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > >>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > >>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>> > >>> Hi > >>> > >>> Putting the issues with "leakage" aside (I cannot tell > how serious > >>> this problem really is). > >>> > >>> I would prefer to sacrifice the end to end ECN semantics for the > >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The > >>> reason is simply that from a realtime communication > >>> > >> scenario with out > >> > >>> of band signaling it is always possible to negotiate the > >>> > >> use of ECN CE > >> > >>> mark in wireless nodes by means of eg. SIP signaling. > Also, atleast > >>> for RTP/UDP I see little use for ECN nonce like it is done > >>> > >> with TCP as > >> > >>> this is more or less an anti-cheat feature. > >>> > >>> > >>> One would then end up with a PCN encoding schema like (I beleve > >>> option 5 in figure 1 in the PCN encoding draft) is the closest. > >>> > >>> PCN Meaning ECN DSCP > >>> ============================= > >>> PCN capable 00 PCN 1 > >>> Admission Mark 01 PCN 1 > >>> Termination Mark 10 PCN 1 > >>> > >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be > >>> > >> set to "00", > >> > >>> likewise at PCN egress. ECN CE is however left untouched. > >>> > >> This has the > >> > >>> effect that routers will be able to set ECN-CE on packets > >>> > >> before they > >> > >>> enter the first PCN domain, after exit from the PCN > domain routers > >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). > >>> Wireless nodes > >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can > >>> > >> however set > >> > >>> ECN CE as this is can be managed by out of band signaling. > >>> > >>> Besides this I would prefer a solution that maintains end to end > >>> semantics regardless of DSCP value. If one consider DCCP we > >>> > >> don't know > >> > >>> today if it will be a best effort traffic alternatiive or > if there > >>> is a benefit with it even with QoS and DCCP can use ECN nonce. > >>> > >>> /Ingemar > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>> Sent: den 21 februari 2008 11:07 > >>>> To: philip.eardley@bt.com; Ingemar Johansson S > >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>> > >>>> > >>>> Hi Phil, Hi all > >>>> > >>>> In order to make a selection of one single (or two) options, I > >>>> think that the PCN WG should get the possibility to > study all the > >>>> possible and PCN relevant encoding options. > >>>> > >>>> In my opinion the goal of the encoding draft is to provide this > >>>> information to the PCN-WG. > >>>> Based on this information the PCN WG can discuss and > decide which > >>>> of the options should be used. > >>>> > >>>> The below text is copied from the current version of the > encoding > >>>> draft! > >>>> Four options are described! > >>>> Please note that the encoding draft should list all relevant > >>>> options with advantages and disadvantages. > >>>> > >>>> Phil and Ingemar, if you can add advantages, > disadvantages to the > >>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the > >>>> encoding draft, please do. > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> > >>>> 3.2. Encoding Using DSCP Field > >>>> > >>>> In this type of encoding and transport method the > >>>> > >> congestion and > >> > >>>> precongestion information is encoded into the 6 DSCP > >>>> > >>> bits that are > >>> > >>>> transported in the IP header of the data packets. > >>>> > >> Four possible > >> > >>>> alternatives can be distinguished, as can be seen in > >>>> > >>> Figure 3, with > >>> > >>>> details provided by > draft-westberg-pcn-load-control-02.txt [4]. > >>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 > >>>> > >>> need three > >>> > >>>> additional DSCP values and Option 10 needs four > additional DSCP > >>>> values. Note that all additional and experimental DSCP > >>>> > >>> values are > >>> > >>>> representing and are associated with the same PHB. > >>>> > >> The 1st, 2nd, > >> > >>>> 3rd, and 4th DSCP values are representing DSCP values that are > >>>> assigned by IANA as DSCP experimental values, see RFC > 2211 [9]. > >>>> > >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------- > >>>> --------- > >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 Add > >>>> |DSCP 4 > >>>> || > >>>> ===========++==========+===========+===========+===========+== > >>>> =========| > >>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | > >>>> NA | > >>>> |-----------++----------+-----------+-----------+-----------+- > >>>> ----------| > >>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | > >>>> NA | > >>>> |-----------++----------+-----------+-----------+-----------+- > >>>> ----------| > >>>> | Option 8 || Not-PCN | PCN | AM | TM | > >>>> NA | > >>>> |-----------++----------+-----------+-----------+-----------+- > >>>> ----------| > >>>> | Option 9 || Not-PCN | PCN | AM | TM | > >>>> AfM | > >>>> > >>>> -------------------------------------------------------------- > >>>> --------- > >>>> > >>>> Notes: Not-PCN means the packet is not PCN capable. > >>>> > >>>> Figure 2: Encoding of PCN Information Using DSCP Field > >>>> > >>>> 3.2.1. Benefits of Using DSCP Field > >>>> > >>>> The main benefit of using the DSCP field is that it is not > >>>> affecting > >>>> the end-to-end ECN semantics and therefore the issues > >>>> > >>> and concerns > >>> > >>>> raised in RFC 4774 [22] are not applicable for this encoding > >>>> scheme. > >>>> Another benefit is related to the fact that all 4 > DSCP encoding > >>>> options depicted in Figure 2 can support the PCN capable not > >>>> congested (PCN) indication, the admission control > (AM) and flow > >>>> termination (TM) encoding states. In addition Option 8 > >>>> > >>> and 10 can > >>> > >>>> support the ECMP solution. > >>>> > >>>> 3.2.2. Drawbacks of Using DSCP Field > >>>> > >>>> This type of encoding needs to use per PHB, in addition to the > >>>> original DSCP and depending on the encoding option used, > >>>> > >>> one, two, > >>> > >>>> three, or four DSCP values, respectively. These > >>>> > >> additional DSCP > >> > >>>> values can be taken from the DSCP values that are not > >>>> > >> defined by > >> > >>>> standards action, see RFC 2211 [9]. Note that all the > >>>> > >> additional > >> > >>>> DSCP values are representing and are associated with one > >>>> > >>> PHB. The > >>> > >>>> value of this DSCP/PHB can either follow a standards > action or > >>>> use a > >>>> value that is applied for experimental or local use. It is > >>>> important > >>>> to note that the number of the DSCP values used for local or > >>>> experimental use is restricted and therefore the number of > >>>> different > >>>> PHBs supported in the PCN domain will also be restricted. > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > >>>>> > >>>> Behalf Of > >>>> > >>>>> philip.eardley@bt.com > >>>>> Sent: donderdag 21 februari 2008 10:24 > >>>>> To: ingemar.s.johansson@ericsson.com; > >>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>> > >>>>> Ingemar > >>>>> > >>>>> Re > >>>>> > >>>>> > >>>>>> consider the end to end ECN usecases > >>>>>> > >>>>> I believe that the emails below about Toby's encoding > >>>>> > >> proposal do > >> > >>>>> indeed already consider ECN. Would appreciate it if you > >>>>> > >> could add > >> > >>>>> further text to it to better capture the (pros and) cons. > >>>>> > >>>>> > >>>>>> more DSCP codepoints > >>>>>> > >>>>> I think you may be proposing an encoding that uses all dscp > >>>>> > >>>> codepoints > >>>> > >>>>> (as has Georgios). That's fine - but a "1 pager" > >>>>> setting out this option with its pros and cons (ie > >>>>> > >>> similar to what > >>> > >>>>> toby has done below) is needed I think! At the moment we > >>>>> > >>>> have lots of > >>>> > >>>>> options on the table - in order to reach a decision, I > >>>>> > >>>> think we really > >>>> > >>>>> need very few options but with their pros and cons better > >>>>> > >>> laid out. > >>> > >>>>> I haven't managed to get to your draft yet, sorry (next week > >>>>> hopefully) > >>>>> - > >>>>> Thanks > >>>>> Phil > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ingemar Johansson S > >>>>>> > >>>> [mailto:ingemar.s.johansson@ericsson.com] > >>>> > >>>>>> Sent: 21 February 2008 06:43 > >>>>>> To: Eardley,PL,Philip,CXR9 R; > >>>>>> > >> menth@informatik.uni-wuerzburg.de; > >> > >>>>>> Moncaster,T,Toby,CXR9 R > >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>> > >>>>>> Hi > >>>>>> > >>>>>> In this discussion it may be well worth the effort to > >>>>>> > >>>>> consider the end > >>>>> > >>>>>> to end ECN usecases that we foresee when considering > >>>>>> > >>> various PCN > >>> > >>>>>> encoding options. > >>>>>> Please have a look at > >>>>>> > >>>>>> > >> > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > >> > >>>>>> for a discussion of the use cases and a motivation to why > >>>>>> > >>>> end to end > >>>> > >>>>> ECN > >>>>> > >>>>>> should be maintained even across PCN nodes even for non > >>>>>> > >>>> DF traffic. > >>>> > >>>>>> That said I realize that there is some cost associated to > >>>>>> > >>>>> the use of > >>>>> > >>>>>> DSCP codepoints, this cost must however be weighted against > >>>>>> > >>>>> the risk > >>>>> > >>>>>> that other functionality like end to end ECN semantics is > >>>>>> > >>>> probably > >>>> > >>>>>> broken if a PCN encoding option "fiddles" with the ECN > >>>>>> > >>> bits. It is > >>> > >>>>> easy > >>>>> > >>>>>> to see that if one wish to maintain support for end to > >>>>>> > >>>> end ECN (not > >>>> > >>>>> only > >>>>> > >>>>>> in DF class) it simply costs more DSCP codepoints. > >>>>>> I am not explicitly saying don't do this or that but I wish > >>>>>> > >>>>> to avoid a > >>>>> > >>>>>> situation where one technique has to be avoided in favor of > >>>>>> > >>>>> the other > >>>>> as > >>>>> > >>>>>> it may in the end prevent deployment of both. If one can > >>>>>> > >>>>> yank the two > >>>>> > >>>>>> together so much the better even though the cost e.g in > >>>>>> > >>> DSCP code > >>> > >>>>> points > >>>>> > >>>>>> is regarded as higher. > >>>>>> > >>>>>> Regards > >>>>>> Ingemar > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > >>>>>>> > >>>>> On Behalf > >>>>> > >>>>>>> Of philip.eardley@bt.com > >>>>>>> Sent: den 20 februari 2008 17:44 > >>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>>>> > >>>>>>> Thanks Michael > >>>>>>> > >>>>>>> I agree with you that spending one DSCP value is quite > >>>>>>> > >>>> expensive > >>>> > >>>>>>> (not two, as one is spent anyway). I think the only way > >>>>>>> > >>>> of really > >>>> > >>>>>>> assessing this properly is for an alternative proposal > >>>>>>> > >>>> (with pros > >>>> > >>>>>>> and cons) that requires only one DSCP. > >>>>>>> Then we can see where the consensus for the best > >>>>>>> > >> (/least bad) > >> > >>>>>>> encoding lies. Personally I have no axe to grind for > >>>>>>> > >>> or against > >>> > >>>>>>> either - I'm not yet convinced that the proposal below is > >>>>>>> > >>>>> definitely > >>>>> > >>>>>>> the way to go, until compared it in detail with other > >>>>>>> > >>> proposals. > >>> > >>>>>>> So I think it would be really useful to have a "1 > >>>>>>> > >> pager" for > >> > >>>>>>> alternative > >>>>>>> proposal(s) before the ietf, as I think this would make > >>>>>>> > >>>>> Philadelphia > >>>>> > >>>>>>> discussions more productive. > >>>>>>> > >>>>>>> > >>>>>>> You're correct about one of the motivations > >>>>>>> > >>>> (advantages) for this > >>>> > >>>>>>> proposal (although I don't think the issues are exactly > >>>>>>> > >>>>> the same for > >>>>> > >>>>>>> 11 leakage as 01/10 leakage). > >>>>>>> > >>>>>>> Consider the case where 11 leaks out of the PCN > >>>>>>> > >>> domain. If the > >>> > >>>>>>> endpoints are ECN capable, then the ECN source slows > >>>>>>> > >>>> down (seems > >>>> > >>>>>>> reasonable). If they're not capable, then the impact > >>>>>>> > >>>> outside the > >>>> > >>>>>>> domain isn't any different to what would happen without > >>>>>>> > >>>>> PCN-domain. > >>>>> > >>>>>>> Consider the case where ECN-11 leaks into the PCN domain. > >>>>>>> Then this will lead to either flow admission or > >>>>>>> > >>>>> termination in the > >>>>> > >>>>>>> PCN-domain. These are both safe, in that the reaction is > >>>>>>> > >>>>> (I believe) > >>>>> > >>>>>>> at least as severe as would happen in an all ECN world. > >>>>>>> You mention that this might not terminate the ECN-11 flow > >>>>>>> specifically (some other flow might get terminated instead). > >>>>>>> I think this is true, though it also implies that [1] > >>>>>>> > >>>>> end-to-end ECN > >>>>> > >>>>>>> & PCN on the same flow really is useful, [2] the > >>>>>>> > >> mechanism (eg > >> > >>>>>>> tunnelling) to carry ECN-marking transparently across the > >>>>>>> > >>>>> PCN-domain > >>>>> > >>>>>>> has also failed, [3] the flows which are terminated > >>>>>>> > >>> aren't other > >>> > >>>>>>> ECN-11 flows that are also getting in due to the same > >>>>>>> misconfiguration. > >>>>>>> > >>>>>>> Best wishes > >>>>>>> Phil > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Michael Menth > >>>>>>>> > >>> [mailto:menth@informatik.uni-wuerzburg.de] > >>> > >>>>>>>> Sent: 20 February 2008 10:50 > >>>>>>>> To: Moncaster,T,Toby,CXR9 R > >>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > >>>>>>>> > >>>> khchan@nortel.com; > >>>> > >>>>>>>> babiarz@nortel.com; sob@harvard.edu; > >>>>>>>> > >>>> steven.blake@ericsson.com; > >>>> > >>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > >>>>>>>> Subject: Re: FW: RE: PCN encoding option > >>>>>>>> > >>>>>>>> Hi Toby, > >>>>>>>> > >>>>>>>> as I understand the proposal, the motivation is to > >>>>>>>> > >>>> avoid 01/10 > >>>> > >>>>>>>> codepoints as it is not good if they leak out of the > >>>>>>>> > >>>>> network since > >>>>> > >>>>>>> 01/10 > >>>>>>> > >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. > >>>>>>>> > >>>>>>> However, there is > >>>>>>> > >>>>>>>> the same problem with 11 marking, i.e. 11-packets > >>>>>>>> > >> may not be > >> > >>>>> dropped > >>>>> > >>>>>>> by > >>>>>>> > >>>>>>>> ECN nodes outside the PCN domain although endpoints > >>>>>>>> > >>>> are not ECN > >>>> > >>>>>>> capable. > >>>>>>> > >>>>>>>> Even if 11-packets trigger flow termination, it is not > >>>>>>>> > >>>>>>> guaranteed that > >>>>>>> > >>>>>>>> exactly the marked flow going over an overloaded > >>>>>>>> > >> ECN node is > >> > >>>>>>> terminated. > >>>>>>> > >>>>>>>> Just want to say that this solution wants to solve a > >>>>>>>> > >>>>> problem that > >>>>> > >>>>>>> exists > >>>>>>> > >>>>>>>> only in case of misconfiguration (leaking packets), but > >>>>>>>> > >>>>>>> does not fully > >>>>>>> > >>>>>>>> achieve that objective. Therefore, I feel that > >>>>>>>> > >>>> spending two DSCP > >>>> > >>>>>>> values > >>>>>>> > >>>>>>>> is quite expensive. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Michael > >>>>>>>> > >>>>>>>> toby.moncaster@bt.com wrote: > >>>>>>>> > >>>>>>>>> All, > >>>>>>>>> > >>>>>>>>> Phil and I have just been discussing the encoding draft > >>>>>>>>> > >>>>>>> and feel we > >>>>>>> may > >>>>>>> > >>>>>>>>> have lit upon a neat solution that seems to have > >>>>>>>>> > >>>> lots of pros > >>>> > >>>>> and > >>>>> > >>>>>>> few > >>>>>>> > >>>>>>>>> cons... In order to get a better feeling for this > >>>>>>>>> > >>>>>>> proposal I will go > >>>>>>> > >>>>>>>>> through the simplified version without Affected > >>>>>>>>> > >>>> marking first: > >>>> > >>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>> > >>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>> Termination Mark 11/00 PCN 2 > >>>>>>>>> > >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with > >>>>>>>>> > >>> the same PCN > >>> > >>>>>>> behaviour > >>>>>>> > >>>>>>>>> aggregate. > >>>>>>>>> > >>>>>>>>> Pros: > >>>>>>>>> o Termination marking and admission marking are > >>>>>>>>> > >>>> independent, > >>>> > >>>>> eg > >>>>> > >>>>>>>>> termination marking can be done after a packet has been > >>>>>>>>> > >>>>> admission > >>>>> > >>>>>>>>> marked. Therefore a router can write AM or TM without > >>>>>>>>> > >>>>>>> having to read > >>>>>>> the > >>>>>>> > >>>>>>>>> packet's PCN marking first, which is easier to > >>>>>>>>> > >>>>> implement. (Note: > >>>>> > >>>>>>>>> Over-writing a TM with AM is not allowed for > >>>>>>>>> > >> 3SM & CL, see > >> > >>>>>>>>> draft-charny-pcn-comparison.) > >>>>>>>>> > >>>>>>>>> o This scheme avoids giving semantics to ECT(0) and > >>>>>>>>> > >>>>>>> ECT(1). This is > >>>>>>> > >>>>>>>>> safest option if packets leak outside the PCN > >>>>>>>>> > >>> region, due to > >>> > >>>>> some > >>>>> > >>>>>>> fort > >>>>>>> > >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant > >>>>>>>>> > >>>>>>> for a single > >>>>>>> > >>>>>>>>> domain deployment of PCN). > >>>>>>>>> > >>>>>>>>> o It leaves open the possibility of using ECT(0) and > >>>>>>>>> > >>>>>>> ECT(1) in some > >>>>>>> > >>>>>>>>> mysterious way in a future end-to-end PCN deployment > >>>>>>>>> > >>>>>>>>> o For a router to classify a packet as PCN, it > >>>>>>>>> > >>>>> simply reads its > >>>>> > >>>>>>> DSCP. > >>>>>>> > >>>>>>>>> This is probably easier than checking both its > >>>>>>>>> > >> DSCP & ECN > >> > >>>>> fields. > >>>>> > >>>>>>>>> o Incremental deployment steps are possible [1] > >>>>>>>>> > >>>>> could deploy SM > >>>>> > >>>>>>>>> initially and later AM/TM. Just add the second > >>>>>>>>> > >>>>>>> DSCP. > >>>>>>> > >>>>>>>>> If a router isn't upgraded at the same time nothing > >>>>>>>>> > >>>>> too horrific > >>>>> > >>>>>>>>> happens. > >>>>>>>>> [2] could just deploy admission control & add > >>>>>>>>> > >>>>> termination later, > >>>>> > >>>>>>> just by > >>>>>>> > >>>>>>>>> adding a new DSCP; there is no need to change the > >>>>>>>>> > >>>>>>> encoding and check > >>>>>>> for > >>>>>>> > >>>>>>>>> backwards compatibility? Vice-versa is also ok? > >>>>>>>>> > >>>>>>>>> Cons: > >>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. > >>>>>>>>> > >>>>> (Although > >>>>> > >>>>>>>>> possibly it's OK to use the same DSCP for TM for > >>>>>>>>> > >>>> all PCN BAs?) > >>>> > >>>>>>>>> o If a packet (in a PCN flow) arrives at the > >>>>>>>>> > >> egress with > >> > >>>>>>> its ECN = > >>>>>>> 11 > >>>>>>> > >>>>>>>>> and it really is required to preserve this info > >>>>>>>>> > >> across the > >> > >>>>>>> PCN-domain, > >>>>>>> > >>>>>>>>> then some complexity is needed at the PCN-boundary-nodes > >>>>>>>>> > >>>>>>> (tunnelling) > >>>>>>> > >>>>>>>>> o If the PCN-domain is operating multipath routing > >>>>>>>>> > >>>>>>> (ECMP) that uses > >>>>>>> the > >>>>>>> > >>>>>>>>> DSCP to select routes, then there may be mis-ordering > >>>>>>>>> > >>>>> of packets > >>>>> > >>>>>>> within > >>>>>>> > >>>>>>>>> a flow. This may be OK as (1) no-one has yet said > >>>>>>>>> > >>>> they know of > >>>> > >>>>> an > >>>>> > >>>>>>> ECMP > >>>>>>> > >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of > >>>>>>>>> > >>>>>>> mis-ordering > >>>>>>> when > >>>>>>> > >>>>>>>>> there is termination marking may be acceptable > >>>>>>>>> > >>>>>>>>> If Affected marking is needed then the scheme can be > >>>>>>>>> > >>>>> modified as > >>>>> > >>>>>>>>> follows: > >>>>>>>>> > >>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>> > >>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>> Termination Mark 11 PCN 2 > >>>>>>>>> Affected Mark 00 PCN 2 > >>>>>>>>> > >>>>>>>>> The pros for this scheme are broadly similar to > >>>>>>>>> > >> the above. > >> > >>>>> However > >>>>> > >>>>>>> there > >>>>>>> > >>>>>>>>> is a new con which may or may not matter: If a packet is > >>>>>>>>> > >>>>> affected > >>>>> > >>>>>>> marked > >>>>>>> > >>>>>>>>> and a later node is doing admission marking then it will > >>>>>>>>> > >>>>>>> reset the > >>>>>>> > >>>>>>>>> affected mark to a termination mark. Work would > >>>>>>>>> > >> be needed > >> > >>>>>>> to see if > >>>>>>> this > >>>>>>> > >>>>>>>>> skews the results and causes significant > >>>>>>>>> > >>> over-termination or > >>> > >>>>> not. > >>>>> > >>>>>>>>> Please could people look through this scheme and > >>>>>>>>> > >>>>> highlight any > >>>>> > >>>>>>>>> additional concerns that they may have (and extra > >>>>>>>>> > >>>>> benefits too). > >>>>> I > >>>>> > >>>>>>> would > >>>>>>> > >>>>>>>>> like to get as many opinions as possible. > >>>>>>>>> > >>>>>>>>> What I want to avoid is people just emailing back with > >>>>>>>>> > >>>>>>> "why not try > >>>>>>> this > >>>>>>> > >>>>>>>>> scheme instead". Currently we seem to have a plethora of > >>>>>>>>> > >>>>> possible > >>>>> > >>>>>>>>> schemes on the table and people need to start putting > >>>>>>>>> > >>>>> down much > >>>>> > >>>>>>> clearer > >>>>>>> > >>>>>>>>> pros and cons for the schemes they support... > >>>>>>>>> > >> So it could > >> > >>>>>>> be good to > >>>>>>> > >>>>>>>>> have a similar "one page" email about a specific > >>>>>>>>> > >>> scheme that > >>> > >>>>> only > >>>>> > >>>>>>> uses > >>>>>>> > >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. > >>>>>>>>> > >>>>>>>>> Toby > >>>>>>>>> > >>>>>>>>> > >>> > ____________________________________________________________________ > >>> > >>>>>>>>> Toby Moncaster, > >>>>>>>>> > >> Networks Research > >> > >>>>>>> Centre, BT > >>>>>>> > >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > >>>>>>>>> > >>> 1473 648734 > >>> > >>>>>>>> -- > >>>>>>>> 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 > >>>>>>> http://www.ietf.org/mailman/listinfo/pcn > >>>>>>> > >>>>>>> > >>>>> _______________________________________________ > >>>>> PCN mailing list > >>>>> PCN@ietf.org > >>>>> http://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 > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 02:16:46 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E723428CAEE; Fri, 22 Feb 2008 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, 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 8jlMWVDHe6W6; Fri, 22 Feb 2008 02:16:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C3528C254; Fri, 22 Feb 2008 02:16:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310173A6C64 for ; Fri, 22 Feb 2008 02:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZOwxoAZk1l5 for ; Fri, 22 Feb 2008 02:16:39 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id D9EBC3A6BBA for ; Fri, 22 Feb 2008 02:16:38 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 10:16:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 10:16:46 -0000 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option thread-index: Ach1M1XAo90jM546QBqcZZfyghqtugAAsXvQAAFPz/A= From: To: , X-OriginalArrivalTime: 22 Feb 2008 10:16:34.0067 (UTC) FILETIME=[00206630:01C8753C] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Surely option 2 also opens up a bit of a DoS issue doesn't it? What happens if a malicious router or sender chooses to inject spurious CE marks? Won't this completely distort all the PCN metering? Also there is the added issue of not knowing how frequently a wireless router might be sending CE marks anyway. These are in addition to the problems being expressed below by Ingemar. Overall I still favour some approach of tunnelling the ECN mark (which Ingemar's revised solution sort of did). There still remains an issue with the discarding of ECT(0) and ECT(1) which brings it in conflict with RFC4774. Toby > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 22 February 2008 09:47 > To: menth@informatik.uni-wuerzburg.de > Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; > Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi > > See inline > > /Ingemar > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: den 22 februari 2008 10:13 > > To: Ingemar Johansson S > > Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > > philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > Hi Ingemar, > > > > this solution essentially spends a DSCP to save 11-marking > > through the PCN domain and allow them to be PCN-marked. This > > is a rather high price, in particular because the PCN packets > > need to be remarked to 00. This has the consequence that ECN > > capability is lost for the rest of the path. > Not sure that I agree, yes the ECT(0), ECT(1) codepoints are lost and > there goes also the ECN nonce and the "inband" ECN capability > signaling. > A router outside the PCN domain wont be able to set ECN-CE. However if > the ECN capability is negotiated out of band for the wireless > endpoints > and the up and downlink wireless nodes, these will be ECN-CE > capable but > without the nonce capability. > > > Therefore, I opt for one of the two versions > > 1) discard 11-marked PCN packets before entering the PCN domain OR > > 2) let them go through the PCN domain, take them into account > > for metering, but do not remark them. > > The first option loses ECN capability for PCN traffic, the > > second option keeps it on the subpath before entering the > PCN domain. > Not sure I follow here. What would option 2 look like? > My interpretation: Packets with DSCP=EF enters the PCN domain, at > ingress they are remarked as DSCP=PCN unless ECN="11", in which case > DSCP=EF. What about ECN="01" or "01" will these also be kept > as DSCP=EF > or will the ECN bits be set to "00". > Please explain. > > > > > > > Regards, > > > > Michael > > > > Ingemar Johansson S wrote: > > > Hi > > > > > > Answers inline > > > > > > > > >> -----Original Message----- > > >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > > >> Sent: den 21 februari 2008 15:34 > > >> To: Ingemar Johansson S; karagian@cs.utwente.nl; > > >> philip.eardley@bt.com > > >> Cc: pcn@ietf.org; bob.briscoe@bt.com; > > >> menth@informatik.uni-wuerzburg.de > > >> Subject: RE: [PCN] FW: RE: PCN encoding option > > >> > > >> Hi Ingemar, > > >> > > >> This is exactly the sort of thing Phil and I were hoping > > to trigger > > >> people to write in response to our email. We are hoping to > > settle on > > >> what are the real options people support for the > encoding and why > > >> they support them... > > >> > > >> Just one quick observation - if we have to leave 11 > > unchanged across > > >> the PCN domain this will mean that such packets can't be > > PCN marked > > >> and thus they should not form part of any PCN aggregate (in my > > >> opinion)... > > >> > > > > > > Realized that this is one (big) problem, thanks for > > pointing out this > > > issue. > > > > > > The next alternative is then > > > PCN Meaning ECN DSCP > > > ============================= > > > PCN capable 00 PCN 1 > > > Admission Mark 01 PCN 1 > > > Termination Mark 10 PCN 1 > > > > > > PCN capable+ECN CE 00 PCN 2 > > > AM+ECN CE 01 PCN 2 > > > TM+ECN CE 10 PCN 2 > > > > > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN > > egress PCN > > > 2 is mapped back to the ECN bits as ECN-CE "11". > > > > > > AfM can also be included in the schema > > > > > > I know this does cost an extra DSCP codepoint and it completely > > > disregards the leakage issue, also it possible that this > > alternative > > > or something similar is given in the PCN encoding draft > but I don't > > > think so as this alternative does not preserve the end to end ECN > > > semantics to 100%, rather it assumes that negotiation of > the use of > > > ECN is done out of band at session setup. > > > > > > /Ingemar > > > > > > > > > > > >> Toby > > >> > > >> > > >>> -----Original Message----- > > >>> From: Ingemar Johansson S > > [mailto:ingemar.s.johansson@ericsson.com] > > >>> Sent: 21 February 2008 13:47 > > >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > > >>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > > >>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > > >>> Subject: RE: [PCN] FW: RE: PCN encoding option > > >>> > > >>> Hi > > >>> > > >>> Putting the issues with "leakage" aside (I cannot tell > > how serious > > >>> this problem really is). > > >>> > > >>> I would prefer to sacrifice the end to end ECN semantics for the > > >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE > codepoint. The > > >>> reason is simply that from a realtime communication > > >>> > > >> scenario with out > > >> > > >>> of band signaling it is always possible to negotiate the > > >>> > > >> use of ECN CE > > >> > > >>> mark in wireless nodes by means of eg. SIP signaling. > > Also, atleast > > >>> for RTP/UDP I see little use for ECN nonce like it is done > > >>> > > >> with TCP as > > >> > > >>> this is more or less an anti-cheat feature. > > >>> > > >>> > > >>> One would then end up with a PCN encoding schema like (I beleve > > >>> option 5 in figure 1 in the PCN encoding draft) is the closest. > > >>> > > >>> PCN Meaning ECN DSCP > > >>> ============================= > > >>> PCN capable 00 PCN 1 > > >>> Admission Mark 01 PCN 1 > > >>> Termination Mark 10 PCN 1 > > >>> > > >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be > > >>> > > >> set to "00", > > >> > > >>> likewise at PCN egress. ECN CE is however left untouched. > > >>> > > >> This has the > > >> > > >>> effect that routers will be able to set ECN-CE on packets > > >>> > > >> before they > > >> > > >>> enter the first PCN domain, after exit from the PCN > > domain routers > > >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). > > >>> Wireless nodes > > >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can > > >>> > > >> however set > > >> > > >>> ECN CE as this is can be managed by out of band signaling. > > >>> > > >>> Besides this I would prefer a solution that maintains > end to end > > >>> semantics regardless of DSCP value. If one consider DCCP we > > >>> > > >> don't know > > >> > > >>> today if it will be a best effort traffic alternatiive or > > if there > > >>> is a benefit with it even with QoS and DCCP can use ECN nonce. > > >>> > > >>> /Ingemar > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>>> Sent: den 21 februari 2008 11:07 > > >>>> To: philip.eardley@bt.com; Ingemar Johansson S > > >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > > >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > >>>> Subject: RE: [PCN] FW: RE: PCN encoding option > > >>>> > > >>>> > > >>>> Hi Phil, Hi all > > >>>> > > >>>> In order to make a selection of one single (or two) options, I > > >>>> think that the PCN WG should get the possibility to > > study all the > > >>>> possible and PCN relevant encoding options. > > >>>> > > >>>> In my opinion the goal of the encoding draft is to > provide this > > >>>> information to the PCN-WG. > > >>>> Based on this information the PCN WG can discuss and > > decide which > > >>>> of the options should be used. > > >>>> > > >>>> The below text is copied from the current version of the > > encoding > > >>>> draft! > > >>>> Four options are described! > > >>>> Please note that the encoding draft should list all relevant > > >>>> options with advantages and disadvantages. > > >>>> > > >>>> Phil and Ingemar, if you can add advantages, > > disadvantages to the > > >>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the > > >>>> encoding draft, please do. > > >>>> > > >>>> Best regards, > > >>>> Georgios > > >>>> > > >>>> > > >>>> > > >>>> 3.2. Encoding Using DSCP Field > > >>>> > > >>>> In this type of encoding and transport method the > > >>>> > > >> congestion and > > >> > > >>>> precongestion information is encoded into the 6 DSCP > > >>>> > > >>> bits that are > > >>> > > >>>> transported in the IP header of the data packets. > > >>>> > > >> Four possible > > >> > > >>>> alternatives can be distinguished, as can be seen in > > >>>> > > >>> Figure 3, with > > >>> > > >>>> details provided by > > draft-westberg-pcn-load-control-02.txt [4]. > > >>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 > > >>>> > > >>> need three > > >>> > > >>>> additional DSCP values and Option 10 needs four > > additional DSCP > > >>>> values. Note that all additional and experimental DSCP > > >>>> > > >>> values are > > >>> > > >>>> representing and are associated with the same PHB. > > >>>> > > >> The 1st, 2nd, > > >> > > >>>> 3rd, and 4th DSCP values are representing DSCP > values that are > > >>>> assigned by IANA as DSCP experimental values, see RFC > > 2211 [9]. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> -------------------------------------------------------------- > > >>>> --------- > > >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add > DSCP 3 Add > > >>>> |DSCP 4 > > >>>> || > > >>>> ===========++==========+===========+===========+===========+== > > >>>> =========| > > >>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | > > >>>> NA | > > >>>> |-----------++----------+-----------+-----------+-----------+- > > >>>> ----------| > > >>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | > > >>>> NA | > > >>>> |-----------++----------+-----------+-----------+-----------+- > > >>>> ----------| > > >>>> | Option 8 || Not-PCN | PCN | AM | TM | > > >>>> NA | > > >>>> |-----------++----------+-----------+-----------+-----------+- > > >>>> ----------| > > >>>> | Option 9 || Not-PCN | PCN | AM | TM | > > >>>> AfM | > > >>>> > > >>>> -------------------------------------------------------------- > > >>>> --------- > > >>>> > > >>>> Notes: Not-PCN means the packet is not PCN capable. > > >>>> > > >>>> Figure 2: Encoding of PCN Information Using > DSCP Field > > >>>> > > >>>> 3.2.1. Benefits of Using DSCP Field > > >>>> > > >>>> The main benefit of using the DSCP field is that it is not > > >>>> affecting > > >>>> the end-to-end ECN semantics and therefore the issues > > >>>> > > >>> and concerns > > >>> > > >>>> raised in RFC 4774 [22] are not applicable for this > encoding > > >>>> scheme. > > >>>> Another benefit is related to the fact that all 4 > > DSCP encoding > > >>>> options depicted in Figure 2 can support the PCN capable not > > >>>> congested (PCN) indication, the admission control > > (AM) and flow > > >>>> termination (TM) encoding states. In addition Option 8 > > >>>> > > >>> and 10 can > > >>> > > >>>> support the ECMP solution. > > >>>> > > >>>> 3.2.2. Drawbacks of Using DSCP Field > > >>>> > > >>>> This type of encoding needs to use per PHB, in > addition to the > > >>>> original DSCP and depending on the encoding option used, > > >>>> > > >>> one, two, > > >>> > > >>>> three, or four DSCP values, respectively. These > > >>>> > > >> additional DSCP > > >> > > >>>> values can be taken from the DSCP values that are not > > >>>> > > >> defined by > > >> > > >>>> standards action, see RFC 2211 [9]. Note that all the > > >>>> > > >> additional > > >> > > >>>> DSCP values are representing and are associated with one > > >>>> > > >>> PHB. The > > >>> > > >>>> value of this DSCP/PHB can either follow a standards > > action or > > >>>> use a > > >>>> value that is applied for experimental or local use. It is > > >>>> important > > >>>> to note that the number of the DSCP values used for local or > > >>>> experimental use is restricted and therefore the number of > > >>>> different > > >>>> PHBs supported in the PCN domain will also be restricted. > > >>>> > > >>>> Best regards, > > >>>> Georgios > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > >>>>> > > >>>> Behalf Of > > >>>> > > >>>>> philip.eardley@bt.com > > >>>>> Sent: donderdag 21 februari 2008 10:24 > > >>>>> To: ingemar.s.johansson@ericsson.com; > > >>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > > >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > > >>>>> > > >>>>> Ingemar > > >>>>> > > >>>>> Re > > >>>>> > > >>>>> > > >>>>>> consider the end to end ECN usecases > > >>>>>> > > >>>>> I believe that the emails below about Toby's encoding > > >>>>> > > >> proposal do > > >> > > >>>>> indeed already consider ECN. Would appreciate it if you > > >>>>> > > >> could add > > >> > > >>>>> further text to it to better capture the (pros and) cons. > > >>>>> > > >>>>> > > >>>>>> more DSCP codepoints > > >>>>>> > > >>>>> I think you may be proposing an encoding that uses all dscp > > >>>>> > > >>>> codepoints > > >>>> > > >>>>> (as has Georgios). That's fine - but a "1 pager" > > >>>>> setting out this option with its pros and cons (ie > > >>>>> > > >>> similar to what > > >>> > > >>>>> toby has done below) is needed I think! At the moment we > > >>>>> > > >>>> have lots of > > >>>> > > >>>>> options on the table - in order to reach a decision, I > > >>>>> > > >>>> think we really > > >>>> > > >>>>> need very few options but with their pros and cons better > > >>>>> > > >>> laid out. > > >>> > > >>>>> I haven't managed to get to your draft yet, sorry (next week > > >>>>> hopefully) > > >>>>> - > > >>>>> Thanks > > >>>>> Phil > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Ingemar Johansson S > > >>>>>> > > >>>> [mailto:ingemar.s.johansson@ericsson.com] > > >>>> > > >>>>>> Sent: 21 February 2008 06:43 > > >>>>>> To: Eardley,PL,Philip,CXR9 R; > > >>>>>> > > >> menth@informatik.uni-wuerzburg.de; > > >> > > >>>>>> Moncaster,T,Toby,CXR9 R > > >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > > >>>>>> > > >>>>>> Hi > > >>>>>> > > >>>>>> In this discussion it may be well worth the effort to > > >>>>>> > > >>>>> consider the end > > >>>>> > > >>>>>> to end ECN usecases that we foresee when considering > > >>>>>> > > >>> various PCN > > >>> > > >>>>>> encoding options. > > >>>>>> Please have a look at > > >>>>>> > > >>>>>> > > >> > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > >> > > >>>>>> for a discussion of the use cases and a motivation to why > > >>>>>> > > >>>> end to end > > >>>> > > >>>>> ECN > > >>>>> > > >>>>>> should be maintained even across PCN nodes even for non > > >>>>>> > > >>>> DF traffic. > > >>>> > > >>>>>> That said I realize that there is some cost associated to > > >>>>>> > > >>>>> the use of > > >>>>> > > >>>>>> DSCP codepoints, this cost must however be weighted against > > >>>>>> > > >>>>> the risk > > >>>>> > > >>>>>> that other functionality like end to end ECN semantics is > > >>>>>> > > >>>> probably > > >>>> > > >>>>>> broken if a PCN encoding option "fiddles" with the ECN > > >>>>>> > > >>> bits. It is > > >>> > > >>>>> easy > > >>>>> > > >>>>>> to see that if one wish to maintain support for end to > > >>>>>> > > >>>> end ECN (not > > >>>> > > >>>>> only > > >>>>> > > >>>>>> in DF class) it simply costs more DSCP codepoints. > > >>>>>> I am not explicitly saying don't do this or that but I wish > > >>>>>> > > >>>>> to avoid a > > >>>>> > > >>>>>> situation where one technique has to be avoided in favor of > > >>>>>> > > >>>>> the other > > >>>>> as > > >>>>> > > >>>>>> it may in the end prevent deployment of both. If one can > > >>>>>> > > >>>>> yank the two > > >>>>> > > >>>>>> together so much the better even though the cost e.g in > > >>>>>> > > >>> DSCP code > > >>> > > >>>>> points > > >>>>> > > >>>>>> is regarded as higher. > > >>>>>> > > >>>>>> Regards > > >>>>>> Ingemar > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > >>>>>>> > > >>>>> On Behalf > > >>>>> > > >>>>>>> Of philip.eardley@bt.com > > >>>>>>> Sent: den 20 februari 2008 17:44 > > >>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > > >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > > >>>>>>> > > >>>>>>> Thanks Michael > > >>>>>>> > > >>>>>>> I agree with you that spending one DSCP value is quite > > >>>>>>> > > >>>> expensive > > >>>> > > >>>>>>> (not two, as one is spent anyway). I think the only way > > >>>>>>> > > >>>> of really > > >>>> > > >>>>>>> assessing this properly is for an alternative proposal > > >>>>>>> > > >>>> (with pros > > >>>> > > >>>>>>> and cons) that requires only one DSCP. > > >>>>>>> Then we can see where the consensus for the best > > >>>>>>> > > >> (/least bad) > > >> > > >>>>>>> encoding lies. Personally I have no axe to grind for > > >>>>>>> > > >>> or against > > >>> > > >>>>>>> either - I'm not yet convinced that the proposal below is > > >>>>>>> > > >>>>> definitely > > >>>>> > > >>>>>>> the way to go, until compared it in detail with other > > >>>>>>> > > >>> proposals. > > >>> > > >>>>>>> So I think it would be really useful to have a "1 > > >>>>>>> > > >> pager" for > > >> > > >>>>>>> alternative > > >>>>>>> proposal(s) before the ietf, as I think this would make > > >>>>>>> > > >>>>> Philadelphia > > >>>>> > > >>>>>>> discussions more productive. > > >>>>>>> > > >>>>>>> > > >>>>>>> You're correct about one of the motivations > > >>>>>>> > > >>>> (advantages) for this > > >>>> > > >>>>>>> proposal (although I don't think the issues are exactly > > >>>>>>> > > >>>>> the same for > > >>>>> > > >>>>>>> 11 leakage as 01/10 leakage). > > >>>>>>> > > >>>>>>> Consider the case where 11 leaks out of the PCN > > >>>>>>> > > >>> domain. If the > > >>> > > >>>>>>> endpoints are ECN capable, then the ECN source slows > > >>>>>>> > > >>>> down (seems > > >>>> > > >>>>>>> reasonable). If they're not capable, then the impact > > >>>>>>> > > >>>> outside the > > >>>> > > >>>>>>> domain isn't any different to what would happen without > > >>>>>>> > > >>>>> PCN-domain. > > >>>>> > > >>>>>>> Consider the case where ECN-11 leaks into the PCN domain. > > >>>>>>> Then this will lead to either flow admission or > > >>>>>>> > > >>>>> termination in the > > >>>>> > > >>>>>>> PCN-domain. These are both safe, in that the reaction is > > >>>>>>> > > >>>>> (I believe) > > >>>>> > > >>>>>>> at least as severe as would happen in an all ECN world. > > >>>>>>> You mention that this might not terminate the ECN-11 flow > > >>>>>>> specifically (some other flow might get terminated instead). > > >>>>>>> I think this is true, though it also implies that [1] > > >>>>>>> > > >>>>> end-to-end ECN > > >>>>> > > >>>>>>> & PCN on the same flow really is useful, [2] the > > >>>>>>> > > >> mechanism (eg > > >> > > >>>>>>> tunnelling) to carry ECN-marking transparently across the > > >>>>>>> > > >>>>> PCN-domain > > >>>>> > > >>>>>>> has also failed, [3] the flows which are terminated > > >>>>>>> > > >>> aren't other > > >>> > > >>>>>>> ECN-11 flows that are also getting in due to the same > > >>>>>>> misconfiguration. > > >>>>>>> > > >>>>>>> Best wishes > > >>>>>>> Phil > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Michael Menth > > >>>>>>>> > > >>> [mailto:menth@informatik.uni-wuerzburg.de] > > >>> > > >>>>>>>> Sent: 20 February 2008 10:50 > > >>>>>>>> To: Moncaster,T,Toby,CXR9 R > > >>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > > >>>>>>>> > > >>>> khchan@nortel.com; > > >>>> > > >>>>>>>> babiarz@nortel.com; sob@harvard.edu; > > >>>>>>>> > > >>>> steven.blake@ericsson.com; > > >>>> > > >>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > >>>>>>>> Subject: Re: FW: RE: PCN encoding option > > >>>>>>>> > > >>>>>>>> Hi Toby, > > >>>>>>>> > > >>>>>>>> as I understand the proposal, the motivation is to > > >>>>>>>> > > >>>> avoid 01/10 > > >>>> > > >>>>>>>> codepoints as it is not good if they leak out of the > > >>>>>>>> > > >>>>> network since > > >>>>> > > >>>>>>> 01/10 > > >>>>>>> > > >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > >>>>>>>> > > >>>>>>> However, there is > > >>>>>>> > > >>>>>>>> the same problem with 11 marking, i.e. 11-packets > > >>>>>>>> > > >> may not be > > >> > > >>>>> dropped > > >>>>> > > >>>>>>> by > > >>>>>>> > > >>>>>>>> ECN nodes outside the PCN domain although endpoints > > >>>>>>>> > > >>>> are not ECN > > >>>> > > >>>>>>> capable. > > >>>>>>> > > >>>>>>>> Even if 11-packets trigger flow termination, it is not > > >>>>>>>> > > >>>>>>> guaranteed that > > >>>>>>> > > >>>>>>>> exactly the marked flow going over an overloaded > > >>>>>>>> > > >> ECN node is > > >> > > >>>>>>> terminated. > > >>>>>>> > > >>>>>>>> Just want to say that this solution wants to solve a > > >>>>>>>> > > >>>>> problem that > > >>>>> > > >>>>>>> exists > > >>>>>>> > > >>>>>>>> only in case of misconfiguration (leaking packets), but > > >>>>>>>> > > >>>>>>> does not fully > > >>>>>>> > > >>>>>>>> achieve that objective. Therefore, I feel that > > >>>>>>>> > > >>>> spending two DSCP > > >>>> > > >>>>>>> values > > >>>>>>> > > >>>>>>>> is quite expensive. > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> Michael > > >>>>>>>> > > >>>>>>>> toby.moncaster@bt.com wrote: > > >>>>>>>> > > >>>>>>>>> All, > > >>>>>>>>> > > >>>>>>>>> Phil and I have just been discussing the encoding draft > > >>>>>>>>> > > >>>>>>> and feel we > > >>>>>>> may > > >>>>>>> > > >>>>>>>>> have lit upon a neat solution that seems to have > > >>>>>>>>> > > >>>> lots of pros > > >>>> > > >>>>> and > > >>>>> > > >>>>>>> few > > >>>>>>> > > >>>>>>>>> cons... In order to get a better feeling for this > > >>>>>>>>> > > >>>>>>> proposal I will go > > >>>>>>> > > >>>>>>>>> through the simplified version without Affected > > >>>>>>>>> > > >>>> marking first: > > >>>> > > >>>>>>>>> PCN Meaning ECN DSCP > > >>>>>>>>> > > >>>>>>>>> PCN capable 00 PCN 1 > > >>>>>>>>> Admission Mark 11 PCN 1 > > >>>>>>>>> Termination Mark 11/00 PCN 2 > > >>>>>>>>> > > >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with > > >>>>>>>>> > > >>> the same PCN > > >>> > > >>>>>>> behaviour > > >>>>>>> > > >>>>>>>>> aggregate. > > >>>>>>>>> > > >>>>>>>>> Pros: > > >>>>>>>>> o Termination marking and admission marking are > > >>>>>>>>> > > >>>> independent, > > >>>> > > >>>>> eg > > >>>>> > > >>>>>>>>> termination marking can be done after a packet has been > > >>>>>>>>> > > >>>>> admission > > >>>>> > > >>>>>>>>> marked. Therefore a router can write AM or TM without > > >>>>>>>>> > > >>>>>>> having to read > > >>>>>>> the > > >>>>>>> > > >>>>>>>>> packet's PCN marking first, which is easier to > > >>>>>>>>> > > >>>>> implement. (Note: > > >>>>> > > >>>>>>>>> Over-writing a TM with AM is not allowed for > > >>>>>>>>> > > >> 3SM & CL, see > > >> > > >>>>>>>>> draft-charny-pcn-comparison.) > > >>>>>>>>> > > >>>>>>>>> o This scheme avoids giving semantics to ECT(0) and > > >>>>>>>>> > > >>>>>>> ECT(1). This is > > >>>>>>> > > >>>>>>>>> safest option if packets leak outside the PCN > > >>>>>>>>> > > >>> region, due to > > >>> > > >>>>> some > > >>>>> > > >>>>>>> fort > > >>>>>>> > > >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant > > >>>>>>>>> > > >>>>>>> for a single > > >>>>>>> > > >>>>>>>>> domain deployment of PCN). > > >>>>>>>>> > > >>>>>>>>> o It leaves open the possibility of using ECT(0) and > > >>>>>>>>> > > >>>>>>> ECT(1) in some > > >>>>>>> > > >>>>>>>>> mysterious way in a future end-to-end PCN deployment > > >>>>>>>>> > > >>>>>>>>> o For a router to classify a packet as PCN, it > > >>>>>>>>> > > >>>>> simply reads its > > >>>>> > > >>>>>>> DSCP. > > >>>>>>> > > >>>>>>>>> This is probably easier than checking both its > > >>>>>>>>> > > >> DSCP & ECN > > >> > > >>>>> fields. > > >>>>> > > >>>>>>>>> o Incremental deployment steps are possible [1] > > >>>>>>>>> > > >>>>> could deploy SM > > >>>>> > > >>>>>>>>> initially and later AM/TM. Just add the second > > >>>>>>>>> > > >>>>>>> DSCP. > > >>>>>>> > > >>>>>>>>> If a router isn't upgraded at the same time nothing > > >>>>>>>>> > > >>>>> too horrific > > >>>>> > > >>>>>>>>> happens. > > >>>>>>>>> [2] could just deploy admission control & add > > >>>>>>>>> > > >>>>> termination later, > > >>>>> > > >>>>>>> just by > > >>>>>>> > > >>>>>>>>> adding a new DSCP; there is no need to change the > > >>>>>>>>> > > >>>>>>> encoding and check > > >>>>>>> for > > >>>>>>> > > >>>>>>>>> backwards compatibility? Vice-versa is also ok? > > >>>>>>>>> > > >>>>>>>>> Cons: > > >>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. > > >>>>>>>>> > > >>>>> (Although > > >>>>> > > >>>>>>>>> possibly it's OK to use the same DSCP for TM for > > >>>>>>>>> > > >>>> all PCN BAs?) > > >>>> > > >>>>>>>>> o If a packet (in a PCN flow) arrives at the > > >>>>>>>>> > > >> egress with > > >> > > >>>>>>> its ECN = > > >>>>>>> 11 > > >>>>>>> > > >>>>>>>>> and it really is required to preserve this info > > >>>>>>>>> > > >> across the > > >> > > >>>>>>> PCN-domain, > > >>>>>>> > > >>>>>>>>> then some complexity is needed at the PCN-boundary-nodes > > >>>>>>>>> > > >>>>>>> (tunnelling) > > >>>>>>> > > >>>>>>>>> o If the PCN-domain is operating multipath routing > > >>>>>>>>> > > >>>>>>> (ECMP) that uses > > >>>>>>> the > > >>>>>>> > > >>>>>>>>> DSCP to select routes, then there may be mis-ordering > > >>>>>>>>> > > >>>>> of packets > > >>>>> > > >>>>>>> within > > >>>>>>> > > >>>>>>>>> a flow. This may be OK as (1) no-one has yet said > > >>>>>>>>> > > >>>> they know of > > >>>> > > >>>>> an > > >>>>> > > >>>>>>> ECMP > > >>>>>>> > > >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of > > >>>>>>>>> > > >>>>>>> mis-ordering > > >>>>>>> when > > >>>>>>> > > >>>>>>>>> there is termination marking may be acceptable > > >>>>>>>>> > > >>>>>>>>> If Affected marking is needed then the scheme can be > > >>>>>>>>> > > >>>>> modified as > > >>>>> > > >>>>>>>>> follows: > > >>>>>>>>> > > >>>>>>>>> PCN Meaning ECN DSCP > > >>>>>>>>> > > >>>>>>>>> PCN capable 00 PCN 1 > > >>>>>>>>> Admission Mark 11 PCN 1 > > >>>>>>>>> Termination Mark 11 PCN 2 > > >>>>>>>>> Affected Mark 00 PCN 2 > > >>>>>>>>> > > >>>>>>>>> The pros for this scheme are broadly similar to > > >>>>>>>>> > > >> the above. > > >> > > >>>>> However > > >>>>> > > >>>>>>> there > > >>>>>>> > > >>>>>>>>> is a new con which may or may not matter: If a packet is > > >>>>>>>>> > > >>>>> affected > > >>>>> > > >>>>>>> marked > > >>>>>>> > > >>>>>>>>> and a later node is doing admission marking then it will > > >>>>>>>>> > > >>>>>>> reset the > > >>>>>>> > > >>>>>>>>> affected mark to a termination mark. Work would > > >>>>>>>>> > > >> be needed > > >> > > >>>>>>> to see if > > >>>>>>> this > > >>>>>>> > > >>>>>>>>> skews the results and causes significant > > >>>>>>>>> > > >>> over-termination or > > >>> > > >>>>> not. > > >>>>> > > >>>>>>>>> Please could people look through this scheme and > > >>>>>>>>> > > >>>>> highlight any > > >>>>> > > >>>>>>>>> additional concerns that they may have (and extra > > >>>>>>>>> > > >>>>> benefits too). > > >>>>> I > > >>>>> > > >>>>>>> would > > >>>>>>> > > >>>>>>>>> like to get as many opinions as possible. > > >>>>>>>>> > > >>>>>>>>> What I want to avoid is people just emailing back with > > >>>>>>>>> > > >>>>>>> "why not try > > >>>>>>> this > > >>>>>>> > > >>>>>>>>> scheme instead". Currently we seem to have a plethora of > > >>>>>>>>> > > >>>>> possible > > >>>>> > > >>>>>>>>> schemes on the table and people need to start putting > > >>>>>>>>> > > >>>>> down much > > >>>>> > > >>>>>>> clearer > > >>>>>>> > > >>>>>>>>> pros and cons for the schemes they support... > > >>>>>>>>> > > >> So it could > > >> > > >>>>>>> be good to > > >>>>>>> > > >>>>>>>>> have a similar "one page" email about a specific > > >>>>>>>>> > > >>> scheme that > > >>> > > >>>>> only > > >>>>> > > >>>>>>> uses > > >>>>>>> > > >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. > > >>>>>>>>> > > >>>>>>>>> Toby > > >>>>>>>>> > > >>>>>>>>> > > >>> > > ____________________________________________________________________ > > >>> > > >>>>>>>>> Toby Moncaster, > > >>>>>>>>> > > >> Networks Research > > >> > > >>>>>>> Centre, BT > > >>>>>>> > > >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > > >>>>>>>>> > > >>> 1473 648734 > > >>> > > >>>>>>>> -- > > >>>>>>>> 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 > > >>>>>>> http://www.ietf.org/mailman/listinfo/pcn > > >>>>>>> > > >>>>>>> > > >>>>> _______________________________________________ > > >>>>> PCN mailing list > > >>>>> PCN@ietf.org > > >>>>> http://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 > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 02:49:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D7928C297; Fri, 22 Feb 2008 02:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.124 X-Spam-Level: ** X-Spam-Status: No, score=2.124 tagged_above=-999 required=5 tests=[AWL=-3.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 9w6N0UEpkJsA; Fri, 22 Feb 2008 02:49:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF0128C11E; Fri, 22 Feb 2008 02:49:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7694E3A67D7 for ; Fri, 22 Feb 2008 02:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M3pLntVn2fI for ; Fri, 22 Feb 2008 02:49:16 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D8C5E28C11E for ; Fri, 22 Feb 2008 02:49:15 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 22 Feb 2008 11:49:10 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 11:49:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 11:50:08 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8BDFC@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Ach1M1XAo90jM546QBqcZZfyghqtugAAsXvQAAFPz/AAANhJAA== References: <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 22 Feb 2008 10:49:09.0899 (UTC) FILETIME=[8DE4ADB0:01C87540] Cc: pcn@ietf.org Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby, you are right, there's a control issue with ECN once we talk about PCN to steer the behviour of network elements in the case of (pre) congestion. I'm not sure, wether PCN is supposed to work on that, but I also can't tell who is. If there's a fancy application eligible for PCN QoS transport sending ECN CE marks constantly or as you mention spurious, while absolutely not caring about ECN's original purpose, may it have an advantage then? Is it a requirement to reset ECN CE from 11 to 01/10 or even 00 at the User Network Interface? The bad provider (you've mentioned a server as executing an attack) is another topic. Maybe discard of 11 packets at the PCN ingress node, should their number not reduce a while after a (pre) congestion indication would be an option. Michael made a fair proposal for "good" users, and I support his idea. But we need to protect our mechanisms against malicious users too, that's correct. Regards, Ruediger | -----Original Message----- | From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] | Sent: Friday, February 22, 2008 11:17 AM | To: ingemar.s.johansson@ericsson.com; | menth@informatik.uni-wuerzburg.de | Cc: pcn@ietf.org; bob.briscoe@bt.com | Subject: Re: [PCN] FW: RE: PCN encoding option | | Surely option 2 also opens up a bit of a DoS issue doesn't | it? What happens if a malicious router or sender chooses to | inject spurious CE marks? Won't this completely distort all | the PCN metering? Also there is the added issue of not | knowing how frequently a wireless router might be sending CE | marks anyway. These are in addition to the problems being | expressed below by Ingemar. | | Overall I still favour some approach of tunnelling the ECN | mark (which Ingemar's revised solution sort of did). There | still remains an issue with the discarding of ECT(0) and | ECT(1) which brings it in conflict with RFC4774. | | Toby | | > -----Original Message----- | > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] | > Sent: 22 February 2008 09:47 | > To: menth@informatik.uni-wuerzburg.de | > Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; | > Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R | > Subject: RE: [PCN] FW: RE: PCN encoding option | > | > Hi | > | > See inline | > | > /Ingemar | > | > > -----Original Message----- | > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] | > > Sent: den 22 februari 2008 10:13 | > > To: Ingemar Johansson S | > > Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; | > > philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com | > > Subject: Re: [PCN] FW: RE: PCN encoding option | > > | > > Hi Ingemar, | > > | > > this solution essentially spends a DSCP to save | 11-marking through | > > the PCN domain and allow them to be PCN-marked. This is a rather | > > high price, in particular because the PCN packets need to be | > > remarked to 00. This has the consequence that ECN | capability is lost | > > for the rest of the path. | > Not sure that I agree, yes the ECT(0), ECT(1) codepoints | are lost and | > there goes also the ECN nonce and the "inband" ECN capability | > signaling. | > A router outside the PCN domain wont be able to set ECN-CE. | However if | > the ECN capability is negotiated out of band for the wireless | > endpoints and the up and downlink wireless nodes, these | will be ECN-CE | > capable but without the nonce capability. | > | > > Therefore, I opt for one of the two versions | > > 1) discard 11-marked PCN packets before entering the PCN domain OR | > > 2) let them go through the PCN domain, take them into account for | > > metering, but do not remark them. | > > The first option loses ECN capability for PCN traffic, the second | > > option keeps it on the subpath before entering the | > PCN domain. | > Not sure I follow here. What would option 2 look like? | > My interpretation: Packets with DSCP=EF enters the PCN domain, at | > ingress they are remarked as DSCP=PCN unless ECN="11", in | which case | > DSCP=EF. What about ECN="01" or "01" will these also be kept as | > DSCP=EF or will the ECN bits be set to "00". | > Please explain. | > | > | > | > > | > > Regards, | > > | > > Michael | > > | > > Ingemar Johansson S wrote: | > > > Hi | > > > | > > > Answers inline | > > > | > > > | > > >> -----Original Message----- | > > >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] | > > >> Sent: den 21 februari 2008 15:34 | > > >> To: Ingemar Johansson S; karagian@cs.utwente.nl; | > > >> philip.eardley@bt.com | > > >> Cc: pcn@ietf.org; bob.briscoe@bt.com; | > > >> menth@informatik.uni-wuerzburg.de | > > >> Subject: RE: [PCN] FW: RE: PCN encoding option | > > >> | > > >> Hi Ingemar, | > > >> | > > >> This is exactly the sort of thing Phil and I were hoping | > > to trigger | > > >> people to write in response to our email. We are hoping to | > > settle on | > > >> what are the real options people support for the | > encoding and why | > > >> they support them... | > > >> | > > >> Just one quick observation - if we have to leave 11 | > > unchanged across | > > >> the PCN domain this will mean that such packets can't be | > > PCN marked | > > >> and thus they should not form part of any PCN aggregate (in my | > > >> opinion)... | > > >> | > > > | > > > Realized that this is one (big) problem, thanks for | > > pointing out this | > > > issue. | > > > | > > > The next alternative is then | > > > PCN Meaning ECN DSCP | > > > ============================= | > > > PCN capable 00 PCN 1 | > > > Admission Mark 01 PCN 1 | > > > Termination Mark 10 PCN 1 | > > > | > > > PCN capable+ECN CE 00 PCN 2 | > > > AM+ECN CE 01 PCN 2 | > > > TM+ECN CE 10 PCN 2 | > > > | > > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN | > > egress PCN | > > > 2 is mapped back to the ECN bits as ECN-CE "11". | > > > | > > > AfM can also be included in the schema | > > > | > > > I know this does cost an extra DSCP codepoint and it completely | > > > disregards the leakage issue, also it possible that this | > > alternative | > > > or something similar is given in the PCN encoding draft | > but I don't | > > > think so as this alternative does not preserve the end | to end ECN | > > > semantics to 100%, rather it assumes that negotiation of | > the use of | > > > ECN is done out of band at session setup. | > > > | > > > /Ingemar | > > > | > > > | > > > | > > >> Toby | > > >> | > > >> | > > >>> -----Original Message----- | > > >>> From: Ingemar Johansson S | > > [mailto:ingemar.s.johansson@ericsson.com] | > > >>> Sent: 21 February 2008 13:47 | > > >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R | > > >>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; | > > >>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R | > > >>> Subject: RE: [PCN] FW: RE: PCN encoding option | > > >>> | > > >>> Hi | > > >>> | > > >>> Putting the issues with "leakage" aside (I cannot tell | > > how serious | > > >>> this problem really is). | > > >>> | > > >>> I would prefer to sacrifice the end to end ECN | semantics for the | > > >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE | > codepoint. The | > > >>> reason is simply that from a realtime communication | > > >>> | > > >> scenario with out | > > >> | > > >>> of band signaling it is always possible to negotiate the | > > >>> | > > >> use of ECN CE | > > >> | > > >>> mark in wireless nodes by means of eg. SIP signaling. | > > Also, atleast | > > >>> for RTP/UDP I see little use for ECN nonce like it is done | > > >>> | > > >> with TCP as | > > >> | > > >>> this is more or less an anti-cheat feature. | > > >>> | > > >>> | > > >>> One would then end up with a PCN encoding schema like | (I beleve | > > >>> option 5 in figure 1 in the PCN encoding draft) is | the closest. | > > >>> | > > >>> PCN Meaning ECN DSCP | > > >>> ============================= | > > >>> PCN capable 00 PCN 1 | > > >>> Admission Mark 01 PCN 1 | > > >>> Termination Mark 10 PCN 1 | > > >>> | > > >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be | > > >>> | > > >> set to "00", | > > >> | > > >>> likewise at PCN egress. ECN CE is however left untouched. | > > >>> | > > >> This has the | > > >> | > > >>> effect that routers will be able to set ECN-CE on packets | > > >>> | > > >> before they | > > >> | > > >>> enter the first PCN domain, after exit from the PCN | > > domain routers | > > >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). | > > >>> Wireless nodes | > > >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can | > > >>> | > > >> however set | > > >> | > > >>> ECN CE as this is can be managed by out of band signaling. | > > >>> | > > >>> Besides this I would prefer a solution that maintains | > end to end | > > >>> semantics regardless of DSCP value. If one consider DCCP we | > > >>> | > > >> don't know | > > >> | > > >>> today if it will be a best effort traffic alternatiive or | > > if there | > > >>> is a benefit with it even with QoS and DCCP can use ECN nonce. | > > >>> | > > >>> /Ingemar | > > >>> | > > >>> | > > >>> | > > >>>> -----Original Message----- | > > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > > >>>> Sent: den 21 februari 2008 11:07 | > > >>>> To: philip.eardley@bt.com; Ingemar Johansson S | > > >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; | > > >>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | > > >>>> Subject: RE: [PCN] FW: RE: PCN encoding option | > > >>>> | > > >>>> | > > >>>> Hi Phil, Hi all | > > >>>> | > > >>>> In order to make a selection of one single (or two) | options, I | > > >>>> think that the PCN WG should get the possibility to | > > study all the | > > >>>> possible and PCN relevant encoding options. | > > >>>> | > > >>>> In my opinion the goal of the encoding draft is to | > provide this | > > >>>> information to the PCN-WG. | > > >>>> Based on this information the PCN WG can discuss and | > > decide which | > > >>>> of the options should be used. | > > >>>> | > > >>>> The below text is copied from the current version of the | > > encoding | > > >>>> draft! | > > >>>> Four options are described! | > > >>>> Please note that the encoding draft should list all relevant | > > >>>> options with advantages and disadvantages. | > > >>>> | > > >>>> Phil and Ingemar, if you can add advantages, | > > disadvantages to the | > > >>>> ones already mentioned below in Section 3.2.1 and | 3.2.2 of the | > > >>>> encoding draft, please do. | > > >>>> | > > >>>> Best regards, | > > >>>> Georgios | > > >>>> | > > >>>> | > > >>>> | > > >>>> 3.2. Encoding Using DSCP Field | > > >>>> | > > >>>> In this type of encoding and transport method the | > > >>>> | > > >> congestion and | > > >> | > > >>>> precongestion information is encoded into the 6 DSCP | > > >>>> | > > >>> bits that are | > > >>> | > > >>>> transported in the IP header of the data packets. | > > >>>> | > > >> Four possible | > > >> | > > >>>> alternatives can be distinguished, as can be seen in | > > >>>> | > > >>> Figure 3, with | > > >>> | > > >>>> details provided by | > > draft-westberg-pcn-load-control-02.txt [4]. | > > >>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 | > > >>>> | > > >>> need three | > > >>> | > > >>>> additional DSCP values and Option 10 needs four | > > additional DSCP | > > >>>> values. Note that all additional and experimental DSCP | > > >>>> | > > >>> values are | > > >>> | > > >>>> representing and are associated with the same PHB. | > > >>>> | > > >> The 1st, 2nd, | > > >> | > > >>>> 3rd, and 4th DSCP values are representing DSCP | > values that are | > > >>>> assigned by IANA as DSCP experimental values, see RFC | > > 2211 [9]. | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>> | -------------------------------------------------------------- | > > >>>> --------- | > > >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add | > DSCP 3 Add | > > >>>> |DSCP 4 | > > >>>> || | > > >>>> | ===========++==========+===========+===========+===========+== | > > >>>> =========| | > > >>>> | Option 6 || Not-PCN | PCN | AM/TM | | NA | | > > >>>> NA | | > > >>>> | |-----------++----------+-----------+-----------+-----------+- | > > >>>> ----------| | > > >>>> | Option 7 || Not-PCN | PCN | AM/TM | | AfM | | > > >>>> NA | | > > >>>> | |-----------++----------+-----------+-----------+-----------+- | > > >>>> ----------| | > > >>>> | Option 8 || Not-PCN | PCN | AM | | TM | | > > >>>> NA | | > > >>>> | |-----------++----------+-----------+-----------+-----------+- | > > >>>> ----------| | > > >>>> | Option 9 || Not-PCN | PCN | AM | | TM | | > > >>>> AfM | | > > >>>> | > > >>>> | -------------------------------------------------------------- | > > >>>> --------- | > > >>>> | > > >>>> Notes: Not-PCN means the packet is not PCN capable. | > > >>>> | > > >>>> Figure 2: Encoding of PCN Information Using | > DSCP Field | > > >>>> | > > >>>> 3.2.1. Benefits of Using DSCP Field | > > >>>> | > > >>>> The main benefit of using the DSCP field is that | it is not | > > >>>> affecting | > > >>>> the end-to-end ECN semantics and therefore the issues | > > >>>> | > > >>> and concerns | > > >>> | > > >>>> raised in RFC 4774 [22] are not applicable for this | > encoding | > > >>>> scheme. | > > >>>> Another benefit is related to the fact that all 4 | > > DSCP encoding | > > >>>> options depicted in Figure 2 can support the PCN | capable not | > > >>>> congested (PCN) indication, the admission control | > > (AM) and flow | > > >>>> termination (TM) encoding states. In addition Option 8 | > > >>>> | > > >>> and 10 can | > > >>> | > > >>>> support the ECMP solution. | > > >>>> | > > >>>> 3.2.2. Drawbacks of Using DSCP Field | > > >>>> | > > >>>> This type of encoding needs to use per PHB, in | > addition to the | > > >>>> original DSCP and depending on the encoding option used, | > > >>>> | > > >>> one, two, | > > >>> | > > >>>> three, or four DSCP values, respectively. These | > > >>>> | > > >> additional DSCP | > > >> | > > >>>> values can be taken from the DSCP values that are not | > > >>>> | > > >> defined by | > > >> | > > >>>> standards action, see RFC 2211 [9]. Note that all the | > > >>>> | > > >> additional | > > >> | > > >>>> DSCP values are representing and are associated with one | > > >>>> | > > >>> PHB. The | > > >>> | > > >>>> value of this DSCP/PHB can either follow a standards | > > action or | > > >>>> use a | > > >>>> value that is applied for experimental or local | use. It is | > > >>>> important | > > >>>> to note that the number of the DSCP values used | for local or | > > >>>> experimental use is restricted and therefore the | number of | > > >>>> different | > > >>>> PHBs supported in the PCN domain will also be restricted. | > > >>>> | > > >>>> Best regards, | > > >>>> Georgios | > > >>>> | > > >>>> | > > >>>> | > > >>>>> -----Original Message----- | > > >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | > > >>>>> | > > >>>> Behalf Of | > > >>>> | > > >>>>> philip.eardley@bt.com | > > >>>>> Sent: donderdag 21 februari 2008 10:24 | > > >>>>> To: ingemar.s.johansson@ericsson.com; | > > >>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com | > > >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com | > > >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option | > > >>>>> | > > >>>>> Ingemar | > > >>>>> | > > >>>>> Re | > > >>>>> | > > >>>>> | > > >>>>>> consider the end to end ECN usecases | > > >>>>>> | > > >>>>> I believe that the emails below about Toby's encoding | > > >>>>> | > > >> proposal do | > > >> | > > >>>>> indeed already consider ECN. Would appreciate it if you | > > >>>>> | > > >> could add | > > >> | > > >>>>> further text to it to better capture the (pros and) cons. | > > >>>>> | > > >>>>> | > > >>>>>> more DSCP codepoints | > > >>>>>> | > > >>>>> I think you may be proposing an encoding that uses all dscp | > > >>>>> | > > >>>> codepoints | > > >>>> | > > >>>>> (as has Georgios). That's fine - but a "1 pager" | > > >>>>> setting out this option with its pros and cons (ie | > > >>>>> | > > >>> similar to what | > > >>> | > > >>>>> toby has done below) is needed I think! At the moment we | > > >>>>> | > > >>>> have lots of | > > >>>> | > > >>>>> options on the table - in order to reach a decision, I | > > >>>>> | > > >>>> think we really | > > >>>> | > > >>>>> need very few options but with their pros and cons better | > > >>>>> | > > >>> laid out. | > > >>> | > > >>>>> I haven't managed to get to your draft yet, sorry (next week | > > >>>>> hopefully) | > > >>>>> - | > > >>>>> Thanks | > > >>>>> Phil | > > >>>>> | > > >>>>> | > > >>>>> | > > >>>>>> -----Original Message----- | > > >>>>>> From: Ingemar Johansson S | > > >>>>>> | > > >>>> [mailto:ingemar.s.johansson@ericsson.com] | > > >>>> | > > >>>>>> Sent: 21 February 2008 06:43 | > > >>>>>> To: Eardley,PL,Philip,CXR9 R; | > > >>>>>> | > > >> menth@informatik.uni-wuerzburg.de; | > > >> | > > >>>>>> Moncaster,T,Toby,CXR9 R | > > >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R | > > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option | > > >>>>>> | > > >>>>>> Hi | > > >>>>>> | > > >>>>>> In this discussion it may be well worth the effort to | > > >>>>>> | > > >>>>> consider the end | > > >>>>> | > > >>>>>> to end ECN usecases that we foresee when considering | > > >>>>>> | > > >>> various PCN | > > >>> | > > >>>>>> encoding options. | > > >>>>>> Please have a look at | > > >>>>>> | > > >>>>>> | > > >> | > > | > | http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt | > > >> | > > >>>>>> for a discussion of the use cases and a motivation to why | > > >>>>>> | > > >>>> end to end | > > >>>> | > > >>>>> ECN | > > >>>>> | > > >>>>>> should be maintained even across PCN nodes even for non | > > >>>>>> | > > >>>> DF traffic. | > > >>>> | > > >>>>>> That said I realize that there is some cost associated to | > > >>>>>> | > > >>>>> the use of | > > >>>>> | > > >>>>>> DSCP codepoints, this cost must however be weighted against | > > >>>>>> | > > >>>>> the risk | > > >>>>> | > > >>>>>> that other functionality like end to end ECN semantics is | > > >>>>>> | > > >>>> probably | > > >>>> | > > >>>>>> broken if a PCN encoding option "fiddles" with the ECN | > > >>>>>> | > > >>> bits. It is | > > >>> | > > >>>>> easy | > > >>>>> | > > >>>>>> to see that if one wish to maintain support for end to | > > >>>>>> | > > >>>> end ECN (not | > > >>>> | > > >>>>> only | > > >>>>> | > > >>>>>> in DF class) it simply costs more DSCP codepoints. | > > >>>>>> I am not explicitly saying don't do this or that but I wish | > > >>>>>> | > > >>>>> to avoid a | > > >>>>> | > > >>>>>> situation where one technique has to be avoided in favor of | > > >>>>>> | > > >>>>> the other | > > >>>>> as | > > >>>>> | > > >>>>>> it may in the end prevent deployment of both. If one can | > > >>>>>> | > > >>>>> yank the two | > > >>>>> | > > >>>>>> together so much the better even though the cost e.g in | > > >>>>>> | > > >>> DSCP code | > > >>> | > > >>>>> points | > > >>>>> | > > >>>>>> is regarded as higher. | > > >>>>>> | > > >>>>>> Regards | > > >>>>>> Ingemar | > > >>>>>> | > > >>>>>> | > > >>>>>>> -----Original Message----- | > > >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] | > > >>>>>>> | > > >>>>> On Behalf | > > >>>>> | > > >>>>>>> Of philip.eardley@bt.com | > > >>>>>>> Sent: den 20 februari 2008 17:44 | > > >>>>>>> To: menth@informatik.uni-wuerzburg.de; | toby.moncaster@bt.com | > > >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com | > > >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option | > > >>>>>>> | > > >>>>>>> Thanks Michael | > > >>>>>>> | > > >>>>>>> I agree with you that spending one DSCP value is quite | > > >>>>>>> | > > >>>> expensive | > > >>>> | > > >>>>>>> (not two, as one is spent anyway). I think the only way | > > >>>>>>> | > > >>>> of really | > > >>>> | > > >>>>>>> assessing this properly is for an alternative proposal | > > >>>>>>> | > > >>>> (with pros | > > >>>> | > > >>>>>>> and cons) that requires only one DSCP. | > > >>>>>>> Then we can see where the consensus for the best | > > >>>>>>> | > > >> (/least bad) | > > >> | > > >>>>>>> encoding lies. Personally I have no axe to grind for | > > >>>>>>> | > > >>> or against | > > >>> | > > >>>>>>> either - I'm not yet convinced that the proposal below is | > > >>>>>>> | > > >>>>> definitely | > > >>>>> | > > >>>>>>> the way to go, until compared it in detail with other | > > >>>>>>> | > > >>> proposals. | > > >>> | > > >>>>>>> So I think it would be really useful to have a "1 | > > >>>>>>> | > > >> pager" for | > > >> | > > >>>>>>> alternative | > > >>>>>>> proposal(s) before the ietf, as I think this would make | > > >>>>>>> | > > >>>>> Philadelphia | > > >>>>> | > > >>>>>>> discussions more productive. | > > >>>>>>> | > > >>>>>>> | > > >>>>>>> You're correct about one of the motivations | > > >>>>>>> | > > >>>> (advantages) for this | > > >>>> | > > >>>>>>> proposal (although I don't think the issues are exactly | > > >>>>>>> | > > >>>>> the same for | > > >>>>> | > > >>>>>>> 11 leakage as 01/10 leakage). | > > >>>>>>> | > > >>>>>>> Consider the case where 11 leaks out of the PCN | > > >>>>>>> | > > >>> domain. If the | > > >>> | > > >>>>>>> endpoints are ECN capable, then the ECN source slows | > > >>>>>>> | > > >>>> down (seems | > > >>>> | > > >>>>>>> reasonable). If they're not capable, then the impact | > > >>>>>>> | > > >>>> outside the | > > >>>> | > > >>>>>>> domain isn't any different to what would happen without | > > >>>>>>> | > > >>>>> PCN-domain. | > > >>>>> | > > >>>>>>> Consider the case where ECN-11 leaks into the PCN domain. | > > >>>>>>> Then this will lead to either flow admission or | > > >>>>>>> | > > >>>>> termination in the | > > >>>>> | > > >>>>>>> PCN-domain. These are both safe, in that the reaction is | > > >>>>>>> | > > >>>>> (I believe) | > > >>>>> | > > >>>>>>> at least as severe as would happen in an all ECN world. | > > >>>>>>> You mention that this might not terminate the ECN-11 flow | > > >>>>>>> specifically (some other flow might get | terminated instead). | > > >>>>>>> I think this is true, though it also implies that [1] | > > >>>>>>> | > > >>>>> end-to-end ECN | > > >>>>> | > > >>>>>>> & PCN on the same flow really is useful, [2] the | > > >>>>>>> | > > >> mechanism (eg | > > >> | > > >>>>>>> tunnelling) to carry ECN-marking transparently across the | > > >>>>>>> | > > >>>>> PCN-domain | > > >>>>> | > > >>>>>>> has also failed, [3] the flows which are terminated | > > >>>>>>> | > > >>> aren't other | > > >>> | > > >>>>>>> ECN-11 flows that are also getting in due to the same | > > >>>>>>> misconfiguration. | > > >>>>>>> | > > >>>>>>> Best wishes | > > >>>>>>> Phil | > > >>>>>>> | > > >>>>>>>> -----Original Message----- | > > >>>>>>>> From: Michael Menth | > > >>>>>>>> | > > >>> [mailto:menth@informatik.uni-wuerzburg.de] | > > >>> | > > >>>>>>>> Sent: 20 February 2008 10:50 | > > >>>>>>>> To: Moncaster,T,Toby,CXR9 R | > > >>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; | > > >>>>>>>> | > > >>>> khchan@nortel.com; | > > >>>> | > > >>>>>>>> babiarz@nortel.com; sob@harvard.edu; | > > >>>>>>>> | > > >>>> steven.blake@ericsson.com; | > > >>>> | > > >>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R | > > >>>>>>>> Subject: Re: FW: RE: PCN encoding option | > > >>>>>>>> | > > >>>>>>>> Hi Toby, | > > >>>>>>>> | > > >>>>>>>> as I understand the proposal, the motivation is to | > > >>>>>>>> | > > >>>> avoid 01/10 | > > >>>> | > > >>>>>>>> codepoints as it is not good if they leak out of the | > > >>>>>>>> | > > >>>>> network since | > > >>>>> | > > >>>>>>> 01/10 | > > >>>>>>> | > > >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. | > > >>>>>>>> | > > >>>>>>> However, there is | > > >>>>>>> | > > >>>>>>>> the same problem with 11 marking, i.e. 11-packets | > > >>>>>>>> | > > >> may not be | > > >> | > > >>>>> dropped | > > >>>>> | > > >>>>>>> by | > > >>>>>>> | > > >>>>>>>> ECN nodes outside the PCN domain although endpoints | > > >>>>>>>> | > > >>>> are not ECN | > > >>>> | > > >>>>>>> capable. | > > >>>>>>> | > > >>>>>>>> Even if 11-packets trigger flow termination, it is not | > > >>>>>>>> | > > >>>>>>> guaranteed that | > > >>>>>>> | > > >>>>>>>> exactly the marked flow going over an overloaded | > > >>>>>>>> | > > >> ECN node is | > > >> | > > >>>>>>> terminated. | > > >>>>>>> | > > >>>>>>>> Just want to say that this solution wants to solve a | > > >>>>>>>> | > > >>>>> problem that | > > >>>>> | > > >>>>>>> exists | > > >>>>>>> | > > >>>>>>>> only in case of misconfiguration (leaking packets), but | > > >>>>>>>> | > > >>>>>>> does not fully | > > >>>>>>> | > > >>>>>>>> achieve that objective. Therefore, I feel that | > > >>>>>>>> | > > >>>> spending two DSCP | > > >>>> | > > >>>>>>> values | > > >>>>>>> | > > >>>>>>>> is quite expensive. | > > >>>>>>>> | > > >>>>>>>> Regards, | > > >>>>>>>> | > > >>>>>>>> Michael | > > >>>>>>>> | > > >>>>>>>> toby.moncaster@bt.com wrote: | > > >>>>>>>> | > > >>>>>>>>> All, | > > >>>>>>>>> | > > >>>>>>>>> Phil and I have just been discussing the encoding draft | > > >>>>>>>>> | > > >>>>>>> and feel we | > > >>>>>>> may | > > >>>>>>> | > > >>>>>>>>> have lit upon a neat solution that seems to have | > > >>>>>>>>> | > > >>>> lots of pros | > > >>>> | > > >>>>> and | > > >>>>> | > > >>>>>>> few | > > >>>>>>> | > > >>>>>>>>> cons... In order to get a better feeling for this | > > >>>>>>>>> | > > >>>>>>> proposal I will go | > > >>>>>>> | > > >>>>>>>>> through the simplified version without Affected | > > >>>>>>>>> | > > >>>> marking first: | > > >>>> | > > >>>>>>>>> PCN Meaning ECN DSCP | > > >>>>>>>>> | > > >>>>>>>>> PCN capable 00 PCN 1 | > > >>>>>>>>> Admission Mark 11 PCN 1 | > > >>>>>>>>> Termination Mark 11/00 PCN 2 | > > >>>>>>>>> | > > >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with | > > >>>>>>>>> | > > >>> the same PCN | > > >>> | > > >>>>>>> behaviour | > > >>>>>>> | > > >>>>>>>>> aggregate. | > > >>>>>>>>> | > > >>>>>>>>> Pros: | > > >>>>>>>>> o Termination marking and admission marking are | > > >>>>>>>>> | > > >>>> independent, | > > >>>> | > > >>>>> eg | > > >>>>> | > > >>>>>>>>> termination marking can be done after a packet has been | > > >>>>>>>>> | > > >>>>> admission | > > >>>>> | > > >>>>>>>>> marked. Therefore a router can write AM or TM without | > > >>>>>>>>> | > > >>>>>>> having to read | > > >>>>>>> the | > > >>>>>>> | > > >>>>>>>>> packet's PCN marking first, which is easier to | > > >>>>>>>>> | > > >>>>> implement. (Note: | > > >>>>> | > > >>>>>>>>> Over-writing a TM with AM is not allowed for | > > >>>>>>>>> | > > >> 3SM & CL, see | > > >> | > > >>>>>>>>> draft-charny-pcn-comparison.) | > > >>>>>>>>> | > > >>>>>>>>> o This scheme avoids giving semantics to ECT(0) and | > > >>>>>>>>> | > > >>>>>>> ECT(1). This is | > > >>>>>>> | > > >>>>>>>>> safest option if packets leak outside the PCN | > > >>>>>>>>> | > > >>> region, due to | > > >>> | > > >>>>> some | > > >>>>> | > > >>>>>>> fort | > > >>>>>>> | > > >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant | > > >>>>>>>>> | > > >>>>>>> for a single | > > >>>>>>> | > > >>>>>>>>> domain deployment of PCN). | > > >>>>>>>>> | > > >>>>>>>>> o It leaves open the possibility of using ECT(0) and | > > >>>>>>>>> | > > >>>>>>> ECT(1) in some | > > >>>>>>> | > > >>>>>>>>> mysterious way in a future end-to-end PCN deployment | > > >>>>>>>>> | > > >>>>>>>>> o For a router to classify a packet as PCN, it | > > >>>>>>>>> | > > >>>>> simply reads its | > > >>>>> | > > >>>>>>> DSCP. | > > >>>>>>> | > > >>>>>>>>> This is probably easier than checking both its | > > >>>>>>>>> | > > >> DSCP & ECN | > > >> | > > >>>>> fields. | > > >>>>> | > > >>>>>>>>> o Incremental deployment steps are possible [1] | > > >>>>>>>>> | > > >>>>> could deploy SM | > > >>>>> | > > >>>>>>>>> initially and later AM/TM. Just add the second | > > >>>>>>>>> | > > >>>>>>> DSCP. | > > >>>>>>> | > > >>>>>>>>> If a router isn't upgraded at the same time nothing | > > >>>>>>>>> | > > >>>>> too horrific | > > >>>>> | > > >>>>>>>>> happens. | > > >>>>>>>>> [2] could just deploy admission control & add | > > >>>>>>>>> | > > >>>>> termination later, | > > >>>>> | > > >>>>>>> just by | > > >>>>>>> | > > >>>>>>>>> adding a new DSCP; there is no need to change the | > > >>>>>>>>> | > > >>>>>>> encoding and check | > > >>>>>>> for | > > >>>>>>> | > > >>>>>>>>> backwards compatibility? Vice-versa is also ok? | > > >>>>>>>>> | > > >>>>>>>>> Cons: | > > >>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. | > > >>>>>>>>> | > > >>>>> (Although | > > >>>>> | > > >>>>>>>>> possibly it's OK to use the same DSCP for TM for | > > >>>>>>>>> | > > >>>> all PCN BAs?) | > > >>>> | > > >>>>>>>>> o If a packet (in a PCN flow) arrives at the | > > >>>>>>>>> | > > >> egress with | > > >> | > > >>>>>>> its ECN = | > > >>>>>>> 11 | > > >>>>>>> | > > >>>>>>>>> and it really is required to preserve this info | > > >>>>>>>>> | > > >> across the | > > >> | > > >>>>>>> PCN-domain, | > > >>>>>>> | > > >>>>>>>>> then some complexity is needed at the PCN-boundary-nodes | > > >>>>>>>>> | > > >>>>>>> (tunnelling) | > > >>>>>>> | > > >>>>>>>>> o If the PCN-domain is operating multipath routing | > > >>>>>>>>> | > > >>>>>>> (ECMP) that uses | > > >>>>>>> the | > > >>>>>>> | > > >>>>>>>>> DSCP to select routes, then there may be mis-ordering | > > >>>>>>>>> | > > >>>>> of packets | > > >>>>> | > > >>>>>>> within | > > >>>>>>> | > > >>>>>>>>> a flow. This may be OK as (1) no-one has yet said | > > >>>>>>>>> | > > >>>> they know of | > > >>>> | > > >>>>> an | > > >>>>> | > > >>>>>>> ECMP | > > >>>>>>> | > > >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of | > > >>>>>>>>> | > > >>>>>>> mis-ordering | > > >>>>>>> when | > > >>>>>>> | > > >>>>>>>>> there is termination marking may be acceptable | > > >>>>>>>>> | > > >>>>>>>>> If Affected marking is needed then the scheme can be | > > >>>>>>>>> | > > >>>>> modified as | > > >>>>> | > > >>>>>>>>> follows: | > > >>>>>>>>> | > > >>>>>>>>> PCN Meaning ECN DSCP | > > >>>>>>>>> | > > >>>>>>>>> PCN capable 00 PCN 1 | > > >>>>>>>>> Admission Mark 11 PCN 1 | > > >>>>>>>>> Termination Mark 11 PCN 2 | > > >>>>>>>>> Affected Mark 00 PCN 2 | > > >>>>>>>>> | > > >>>>>>>>> The pros for this scheme are broadly similar to | > > >>>>>>>>> | > > >> the above. | > > >> | > > >>>>> However | > > >>>>> | > > >>>>>>> there | > > >>>>>>> | > > >>>>>>>>> is a new con which may or may not matter: If a packet is | > > >>>>>>>>> | > > >>>>> affected | > > >>>>> | > > >>>>>>> marked | > > >>>>>>> | > > >>>>>>>>> and a later node is doing admission marking then it will | > > >>>>>>>>> | > > >>>>>>> reset the | > > >>>>>>> | > > >>>>>>>>> affected mark to a termination mark. Work would | > > >>>>>>>>> | > > >> be needed | > > >> | > > >>>>>>> to see if | > > >>>>>>> this | > > >>>>>>> | > > >>>>>>>>> skews the results and causes significant | > > >>>>>>>>> | > > >>> over-termination or | > > >>> | > > >>>>> not. | > > >>>>> | > > >>>>>>>>> Please could people look through this scheme and | > > >>>>>>>>> | > > >>>>> highlight any | > > >>>>> | > > >>>>>>>>> additional concerns that they may have (and extra | > > >>>>>>>>> | > > >>>>> benefits too). | > > >>>>> I | > > >>>>> | > > >>>>>>> would | > > >>>>>>> | > > >>>>>>>>> like to get as many opinions as possible. | > > >>>>>>>>> | > > >>>>>>>>> What I want to avoid is people just emailing back with | > > >>>>>>>>> | > > >>>>>>> "why not try | > > >>>>>>> this | > > >>>>>>> | > > >>>>>>>>> scheme instead". Currently we seem to have a plethora of | > > >>>>>>>>> | > > >>>>> possible | > > >>>>> | > > >>>>>>>>> schemes on the table and people need to start putting | > > >>>>>>>>> | > > >>>>> down much | > > >>>>> | > > >>>>>>> clearer | > > >>>>>>> | > > >>>>>>>>> pros and cons for the schemes they support... | > > >>>>>>>>> | > > >> So it could | > > >> | > > >>>>>>> be good to | > > >>>>>>> | > > >>>>>>>>> have a similar "one page" email about a specific | > > >>>>>>>>> | > > >>> scheme that | > > >>> | > > >>>>> only | > > >>>>> | > > >>>>>>> uses | > > >>>>>>> | > > >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. | > > >>>>>>>>> | > > >>>>>>>>> Toby | > > >>>>>>>>> | > > >>>>>>>>> | > > >>> | > > | ____________________________________________________________________ | > > >>> | > > >>>>>>>>> Toby Moncaster, | > > >>>>>>>>> | > > >> Networks Research | > > >> | > > >>>>>>> Centre, BT | > > >>>>>>> | > > >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 | > > >>>>>>>>> | > > >>> 1473 648734 | > > >>> | > > >>>>>>>> -- | > > >>>>>>>> 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 | > > >>>>>>> http://www.ietf.org/mailman/listinfo/pcn | > > >>>>>>> | > > >>>>>>> | > > >>>>> _______________________________________________ | > > >>>>> PCN mailing list | > > >>>>> PCN@ietf.org | > > >>>>> http://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 | > > | > > | > | _______________________________________________ | PCN mailing list | PCN@ietf.org | http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 03:00:10 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADEB28C224; Fri, 22 Feb 2008 03:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.745 X-Spam-Level: ** X-Spam-Status: No, score=2.745 tagged_above=-999 required=5 tests=[AWL=-2.718, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 if0em1BilTEb; Fri, 22 Feb 2008 03:00:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4401E3A6CA0; Fri, 22 Feb 2008 03:00:08 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6948028C16E for ; Fri, 22 Feb 2008 03:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLvwCiao0tc2 for ; Fri, 22 Feb 2008 03:00:04 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id EFA9B3A6CA0 for ; Fri, 22 Feb 2008 03:00:02 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 33D96198E0F; Fri, 22 Feb 2008 11:59:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 260F0198E09; Fri, 22 Feb 2008 11:59:58 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7866F198DFF; Fri, 22 Feb 2008 11:59:52 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1MAxqV12813; Fri, 22 Feb 2008 11:59:52 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 371AEC837A; Fri, 22 Feb 2008 11:59:52 +0100 (CET) Message-ID: <47BEAAE9.5040802@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 11:58:49 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, resetting 01- and 10-marked packets to 00-marking does not conflict with RFC4774, only interchanging them is bad: A requirement for compatibility with end-nodes using default ECN is that if a packet that *could* be using default semantics is marked with the ECN codepoint "00", this marking must not be changed to "01", "10", or "11" in the network. This prevents the packet from being represented incorrectly to a default-ECN router downstream as ECN-Capable. Similarly, if a packet that *could* be using default semantics is marked with the ECN codepoint "01", then this codepoint should not be changed to "10" in the network (and a "10" codepoint should not be changed to "01"). This requirement is necessary to avoid interference with the transport protocol's use of the ECN nonce [RFC3540]. Regards, Michael toby.moncaster@bt.com wrote: > Surely option 2 also opens up a bit of a DoS issue doesn't it? What > happens if a malicious router or sender chooses to inject spurious CE > marks? Won't this completely distort all the PCN metering? Also there is > the added issue of not knowing how frequently a wireless router might be > sending CE marks anyway. These are in addition to the problems being > expressed below by Ingemar. > > Overall I still favour some approach of tunnelling the ECN mark (which > Ingemar's revised solution sort of did). There still remains an issue > with the discarding of ECT(0) and ECT(1) which brings it in conflict > with RFC4774. > > Toby > > >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: 22 February 2008 09:47 >> To: menth@informatik.uni-wuerzburg.de >> Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; >> Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >> Subject: RE: [PCN] FW: RE: PCN encoding option >> >> Hi >> >> See inline >> >> /Ingemar >> >> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>> Sent: den 22 februari 2008 10:13 >>> To: Ingemar Johansson S >>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>> Subject: Re: [PCN] FW: RE: PCN encoding option >>> >>> Hi Ingemar, >>> >>> this solution essentially spends a DSCP to save 11-marking >>> through the PCN domain and allow them to be PCN-marked. This >>> is a rather high price, in particular because the PCN packets >>> need to be remarked to 00. This has the consequence that ECN >>> capability is lost for the rest of the path. >>> >> Not sure that I agree, yes the ECT(0), ECT(1) codepoints are lost and >> there goes also the ECN nonce and the "inband" ECN capability >> signaling. >> A router outside the PCN domain wont be able to set ECN-CE. However if >> the ECN capability is negotiated out of band for the wireless >> endpoints >> and the up and downlink wireless nodes, these will be ECN-CE >> capable but >> without the nonce capability. >> >> >>> Therefore, I opt for one of the two versions >>> 1) discard 11-marked PCN packets before entering the PCN domain OR >>> 2) let them go through the PCN domain, take them into account >>> for metering, but do not remark them. >>> The first option loses ECN capability for PCN traffic, the >>> second option keeps it on the subpath before entering the >>> >> PCN domain. >> Not sure I follow here. What would option 2 look like? >> My interpretation: Packets with DSCP=EF enters the PCN domain, at >> ingress they are remarked as DSCP=PCN unless ECN="11", in which case >> DSCP=EF. What about ECN="01" or "01" will these also be kept >> as DSCP=EF >> or will the ECN bits be set to "00". >> Please explain. >> >> >> >> >>> Regards, >>> >>> Michael >>> >>> Ingemar Johansson S wrote: >>> >>>> Hi >>>> >>>> Answers inline >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >>>>> Sent: den 21 februari 2008 15:34 >>>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; >>>>> philip.eardley@bt.com >>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>> menth@informatik.uni-wuerzburg.de >>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>> >>>>> Hi Ingemar, >>>>> >>>>> This is exactly the sort of thing Phil and I were hoping >>>>> >>> to trigger >>> >>>>> people to write in response to our email. We are hoping to >>>>> >>> settle on >>> >>>>> what are the real options people support for the >>>>> >> encoding and why >> >>>>> they support them... >>>>> >>>>> Just one quick observation - if we have to leave 11 >>>>> >>> unchanged across >>> >>>>> the PCN domain this will mean that such packets can't be >>>>> >>> PCN marked >>> >>>>> and thus they should not form part of any PCN aggregate (in my >>>>> opinion)... >>>>> >>>>> >>>> Realized that this is one (big) problem, thanks for >>>> >>> pointing out this >>> >>>> issue. >>>> >>>> The next alternative is then >>>> PCN Meaning ECN DSCP >>>> ============================= >>>> PCN capable 00 PCN 1 >>>> Admission Mark 01 PCN 1 >>>> Termination Mark 10 PCN 1 >>>> >>>> PCN capable+ECN CE 00 PCN 2 >>>> AM+ECN CE 01 PCN 2 >>>> TM+ECN CE 10 PCN 2 >>>> >>>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN >>>> >>> egress PCN >>> >>>> 2 is mapped back to the ECN bits as ECN-CE "11". >>>> >>>> AfM can also be included in the schema >>>> >>>> I know this does cost an extra DSCP codepoint and it completely >>>> disregards the leakage issue, also it possible that this >>>> >>> alternative >>> >>>> or something similar is given in the PCN encoding draft >>>> >> but I don't >> >>>> think so as this alternative does not preserve the end to end ECN >>>> semantics to 100%, rather it assumes that negotiation of >>>> >> the use of >> >>>> ECN is done out of band at session setup. >>>> >>>> /Ingemar >>>> >>>> >>>> >>>> >>>>> Toby >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ingemar Johansson S >>>>>> >>> [mailto:ingemar.s.johansson@ericsson.com] >>> >>>>>> Sent: 21 February 2008 13:47 >>>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Hi >>>>>> >>>>>> Putting the issues with "leakage" aside (I cannot tell >>>>>> >>> how serious >>> >>>>>> this problem really is). >>>>>> >>>>>> I would prefer to sacrifice the end to end ECN semantics for the >>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE >>>>>> >> codepoint. The >> >>>>>> reason is simply that from a realtime communication >>>>>> >>>>>> >>>>> scenario with out >>>>> >>>>> >>>>>> of band signaling it is always possible to negotiate the >>>>>> >>>>>> >>>>> use of ECN CE >>>>> >>>>> >>>>>> mark in wireless nodes by means of eg. SIP signaling. >>>>>> >>> Also, atleast >>> >>>>>> for RTP/UDP I see little use for ECN nonce like it is done >>>>>> >>>>>> >>>>> with TCP as >>>>> >>>>> >>>>>> this is more or less an anti-cheat feature. >>>>>> >>>>>> >>>>>> One would then end up with a PCN encoding schema like (I beleve >>>>>> option 5 in figure 1 in the PCN encoding draft) is the closest. >>>>>> >>>>>> PCN Meaning ECN DSCP >>>>>> ============================= >>>>>> PCN capable 00 PCN 1 >>>>>> Admission Mark 01 PCN 1 >>>>>> Termination Mark 10 PCN 1 >>>>>> >>>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>>>>> >>>>>> >>>>> set to "00", >>>>> >>>>> >>>>>> likewise at PCN egress. ECN CE is however left untouched. >>>>>> >>>>>> >>>>> This has the >>>>> >>>>> >>>>>> effect that routers will be able to set ECN-CE on packets >>>>>> >>>>>> >>>>> before they >>>>> >>>>> >>>>>> enter the first PCN domain, after exit from the PCN >>>>>> >>> domain routers >>> >>>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>>>>> Wireless nodes >>>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>>>>> >>>>>> >>>>> however set >>>>> >>>>> >>>>>> ECN CE as this is can be managed by out of band signaling. >>>>>> >>>>>> Besides this I would prefer a solution that maintains >>>>>> >> end to end >> >>>>>> semantics regardless of DSCP value. If one consider DCCP we >>>>>> >>>>>> >>>>> don't know >>>>> >>>>> >>>>>> today if it will be a best effort traffic alternatiive or >>>>>> >>> if there >>> >>>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. >>>>>> >>>>>> /Ingemar >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>> Sent: den 21 februari 2008 11:07 >>>>>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>> >>>>>>> >>>>>>> Hi Phil, Hi all >>>>>>> >>>>>>> In order to make a selection of one single (or two) options, I >>>>>>> think that the PCN WG should get the possibility to >>>>>>> >>> study all the >>> >>>>>>> possible and PCN relevant encoding options. >>>>>>> >>>>>>> In my opinion the goal of the encoding draft is to >>>>>>> >> provide this >> >>>>>>> information to the PCN-WG. >>>>>>> Based on this information the PCN WG can discuss and >>>>>>> >>> decide which >>> >>>>>>> of the options should be used. >>>>>>> >>>>>>> The below text is copied from the current version of the >>>>>>> >>> encoding >>> >>>>>>> draft! >>>>>>> Four options are described! >>>>>>> Please note that the encoding draft should list all relevant >>>>>>> options with advantages and disadvantages. >>>>>>> >>>>>>> Phil and Ingemar, if you can add advantages, >>>>>>> >>> disadvantages to the >>> >>>>>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the >>>>>>> encoding draft, please do. >>>>>>> >>>>>>> Best regards, >>>>>>> Georgios >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3.2. Encoding Using DSCP Field >>>>>>> >>>>>>> In this type of encoding and transport method the >>>>>>> >>>>>>> >>>>> congestion and >>>>> >>>>> >>>>>>> precongestion information is encoded into the 6 DSCP >>>>>>> >>>>>>> >>>>>> bits that are >>>>>> >>>>>> >>>>>>> transported in the IP header of the data packets. >>>>>>> >>>>>>> >>>>> Four possible >>>>> >>>>> >>>>>>> alternatives can be distinguished, as can be seen in >>>>>>> >>>>>>> >>>>>> Figure 3, with >>>>>> >>>>>> >>>>>>> details provided by >>>>>>> >>> draft-westberg-pcn-load-control-02.txt [4]. >>> >>>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>>>>> >>>>>>> >>>>>> need three >>>>>> >>>>>> >>>>>>> additional DSCP values and Option 10 needs four >>>>>>> >>> additional DSCP >>> >>>>>>> values. Note that all additional and experimental DSCP >>>>>>> >>>>>>> >>>>>> values are >>>>>> >>>>>> >>>>>>> representing and are associated with the same PHB. >>>>>>> >>>>>>> >>>>> The 1st, 2nd, >>>>> >>>>> >>>>>>> 3rd, and 4th DSCP values are representing DSCP >>>>>>> >> values that are >> >>>>>>> assigned by IANA as DSCP experimental values, see RFC >>>>>>> >>> 2211 [9]. >>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------- >>>>>>> --------- >>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add >>>>>>> >> DSCP 3 Add >> >>>>>>> |DSCP 4 >>>>>>> || >>>>>>> ===========++==========+===========+===========+===========+== >>>>>>> =========| >>>>>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | >>>>>>> NA | >>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>> ----------| >>>>>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | >>>>>>> NA | >>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>> ----------| >>>>>>> | Option 8 || Not-PCN | PCN | AM | TM | >>>>>>> NA | >>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>> ----------| >>>>>>> | Option 9 || Not-PCN | PCN | AM | TM | >>>>>>> AfM | >>>>>>> >>>>>>> -------------------------------------------------------------- >>>>>>> --------- >>>>>>> >>>>>>> Notes: Not-PCN means the packet is not PCN capable. >>>>>>> >>>>>>> Figure 2: Encoding of PCN Information Using >>>>>>> >> DSCP Field >> >>>>>>> 3.2.1. Benefits of Using DSCP Field >>>>>>> >>>>>>> The main benefit of using the DSCP field is that it is not >>>>>>> affecting >>>>>>> the end-to-end ECN semantics and therefore the issues >>>>>>> >>>>>>> >>>>>> and concerns >>>>>> >>>>>> >>>>>>> raised in RFC 4774 [22] are not applicable for this >>>>>>> >> encoding >> >>>>>>> scheme. >>>>>>> Another benefit is related to the fact that all 4 >>>>>>> >>> DSCP encoding >>> >>>>>>> options depicted in Figure 2 can support the PCN capable not >>>>>>> congested (PCN) indication, the admission control >>>>>>> >>> (AM) and flow >>> >>>>>>> termination (TM) encoding states. In addition Option 8 >>>>>>> >>>>>>> >>>>>> and 10 can >>>>>> >>>>>> >>>>>>> support the ECMP solution. >>>>>>> >>>>>>> 3.2.2. Drawbacks of Using DSCP Field >>>>>>> >>>>>>> This type of encoding needs to use per PHB, in >>>>>>> >> addition to the >> >>>>>>> original DSCP and depending on the encoding option used, >>>>>>> >>>>>>> >>>>>> one, two, >>>>>> >>>>>> >>>>>>> three, or four DSCP values, respectively. These >>>>>>> >>>>>>> >>>>> additional DSCP >>>>> >>>>> >>>>>>> values can be taken from the DSCP values that are not >>>>>>> >>>>>>> >>>>> defined by >>>>> >>>>> >>>>>>> standards action, see RFC 2211 [9]. Note that all the >>>>>>> >>>>>>> >>>>> additional >>>>> >>>>> >>>>>>> DSCP values are representing and are associated with one >>>>>>> >>>>>>> >>>>>> PHB. The >>>>>> >>>>>> >>>>>>> value of this DSCP/PHB can either follow a standards >>>>>>> >>> action or >>> >>>>>>> use a >>>>>>> value that is applied for experimental or local use. It is >>>>>>> important >>>>>>> to note that the number of the DSCP values used for local or >>>>>>> experimental use is restricted and therefore the number of >>>>>>> different >>>>>>> PHBs supported in the PCN domain will also be restricted. >>>>>>> >>>>>>> Best regards, >>>>>>> Georgios >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>> >>>>>>>> >>>>>>> Behalf Of >>>>>>> >>>>>>> >>>>>>>> philip.eardley@bt.com >>>>>>>> Sent: donderdag 21 februari 2008 10:24 >>>>>>>> To: ingemar.s.johansson@ericsson.com; >>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>> >>>>>>>> Ingemar >>>>>>>> >>>>>>>> Re >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> consider the end to end ECN usecases >>>>>>>>> >>>>>>>>> >>>>>>>> I believe that the emails below about Toby's encoding >>>>>>>> >>>>>>>> >>>>> proposal do >>>>> >>>>> >>>>>>>> indeed already consider ECN. Would appreciate it if you >>>>>>>> >>>>>>>> >>>>> could add >>>>> >>>>> >>>>>>>> further text to it to better capture the (pros and) cons. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> more DSCP codepoints >>>>>>>>> >>>>>>>>> >>>>>>>> I think you may be proposing an encoding that uses all dscp >>>>>>>> >>>>>>>> >>>>>>> codepoints >>>>>>> >>>>>>> >>>>>>>> (as has Georgios). That's fine - but a "1 pager" >>>>>>>> setting out this option with its pros and cons (ie >>>>>>>> >>>>>>>> >>>>>> similar to what >>>>>> >>>>>> >>>>>>>> toby has done below) is needed I think! At the moment we >>>>>>>> >>>>>>>> >>>>>>> have lots of >>>>>>> >>>>>>> >>>>>>>> options on the table - in order to reach a decision, I >>>>>>>> >>>>>>>> >>>>>>> think we really >>>>>>> >>>>>>> >>>>>>>> need very few options but with their pros and cons better >>>>>>>> >>>>>>>> >>>>>> laid out. >>>>>> >>>>>> >>>>>>>> I haven't managed to get to your draft yet, sorry (next week >>>>>>>> hopefully) >>>>>>>> - >>>>>>>> Thanks >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ingemar Johansson S >>>>>>>>> >>>>>>>>> >>>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>>> >>>>>>> >>>>>>>>> Sent: 21 February 2008 06:43 >>>>>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>>>>> >>>>>>>>> >>>>> menth@informatik.uni-wuerzburg.de; >>>>> >>>>> >>>>>>>>> Moncaster,T,Toby,CXR9 R >>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> In this discussion it may be well worth the effort to >>>>>>>>> >>>>>>>>> >>>>>>>> consider the end >>>>>>>> >>>>>>>> >>>>>>>>> to end ECN usecases that we foresee when considering >>>>>>>>> >>>>>>>>> >>>>>> various PCN >>>>>> >>>>>> >>>>>>>>> encoding options. >>>>>>>>> Please have a look at >>>>>>>>> >>>>>>>>> >>>>>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>>> >>>>> >>>>>>>>> for a discussion of the use cases and a motivation to why >>>>>>>>> >>>>>>>>> >>>>>>> end to end >>>>>>> >>>>>>> >>>>>>>> ECN >>>>>>>> >>>>>>>> >>>>>>>>> should be maintained even across PCN nodes even for non >>>>>>>>> >>>>>>>>> >>>>>>> DF traffic. >>>>>>> >>>>>>> >>>>>>>>> That said I realize that there is some cost associated to >>>>>>>>> >>>>>>>>> >>>>>>>> the use of >>>>>>>> >>>>>>>> >>>>>>>>> DSCP codepoints, this cost must however be weighted against >>>>>>>>> >>>>>>>>> >>>>>>>> the risk >>>>>>>> >>>>>>>> >>>>>>>>> that other functionality like end to end ECN semantics is >>>>>>>>> >>>>>>>>> >>>>>>> probably >>>>>>> >>>>>>> >>>>>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>>>>> >>>>>>>>> >>>>>> bits. It is >>>>>> >>>>>> >>>>>>>> easy >>>>>>>> >>>>>>>> >>>>>>>>> to see that if one wish to maintain support for end to >>>>>>>>> >>>>>>>>> >>>>>>> end ECN (not >>>>>>> >>>>>>> >>>>>>>> only >>>>>>>> >>>>>>>> >>>>>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>>>>> I am not explicitly saying don't do this or that but I wish >>>>>>>>> >>>>>>>>> >>>>>>>> to avoid a >>>>>>>> >>>>>>>> >>>>>>>>> situation where one technique has to be avoided in favor of >>>>>>>>> >>>>>>>>> >>>>>>>> the other >>>>>>>> as >>>>>>>> >>>>>>>> >>>>>>>>> it may in the end prevent deployment of both. If one can >>>>>>>>> >>>>>>>>> >>>>>>>> yank the two >>>>>>>> >>>>>>>> >>>>>>>>> together so much the better even though the cost e.g in >>>>>>>>> >>>>>>>>> >>>>>> DSCP code >>>>>> >>>>>> >>>>>>>> points >>>>>>>> >>>>>>>> >>>>>>>>> is regarded as higher. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Ingemar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>>>>> >>>>>>>>>> >>>>>>>> On Behalf >>>>>>>> >>>>>>>> >>>>>>>>>> Of philip.eardley@bt.com >>>>>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>> >>>>>>>>>> Thanks Michael >>>>>>>>>> >>>>>>>>>> I agree with you that spending one DSCP value is quite >>>>>>>>>> >>>>>>>>>> >>>>>>> expensive >>>>>>> >>>>>>> >>>>>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>>>>> >>>>>>>>>> >>>>>>> of really >>>>>>> >>>>>>> >>>>>>>>>> assessing this properly is for an alternative proposal >>>>>>>>>> >>>>>>>>>> >>>>>>> (with pros >>>>>>> >>>>>>> >>>>>>>>>> and cons) that requires only one DSCP. >>>>>>>>>> Then we can see where the consensus for the best >>>>>>>>>> >>>>>>>>>> >>>>> (/least bad) >>>>> >>>>> >>>>>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>>>>> >>>>>>>>>> >>>>>> or against >>>>>> >>>>>> >>>>>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>>>>> >>>>>>>>>> >>>>>>>> definitely >>>>>>>> >>>>>>>> >>>>>>>>>> the way to go, until compared it in detail with other >>>>>>>>>> >>>>>>>>>> >>>>>> proposals. >>>>>> >>>>>> >>>>>>>>>> So I think it would be really useful to have a "1 >>>>>>>>>> >>>>>>>>>> >>>>> pager" for >>>>> >>>>> >>>>>>>>>> alternative >>>>>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>>>>> >>>>>>>>>> >>>>>>>> Philadelphia >>>>>>>> >>>>>>>> >>>>>>>>>> discussions more productive. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You're correct about one of the motivations >>>>>>>>>> >>>>>>>>>> >>>>>>> (advantages) for this >>>>>>> >>>>>>> >>>>>>>>>> proposal (although I don't think the issues are exactly >>>>>>>>>> >>>>>>>>>> >>>>>>>> the same for >>>>>>>> >>>>>>>> >>>>>>>>>> 11 leakage as 01/10 leakage). >>>>>>>>>> >>>>>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>>>>> >>>>>>>>>> >>>>>> domain. If the >>>>>> >>>>>> >>>>>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>>>>> >>>>>>>>>> >>>>>>> down (seems >>>>>>> >>>>>>> >>>>>>>>>> reasonable). If they're not capable, then the impact >>>>>>>>>> >>>>>>>>>> >>>>>>> outside the >>>>>>> >>>>>>> >>>>>>>>>> domain isn't any different to what would happen without >>>>>>>>>> >>>>>>>>>> >>>>>>>> PCN-domain. >>>>>>>> >>>>>>>> >>>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>>>>> Then this will lead to either flow admission or >>>>>>>>>> >>>>>>>>>> >>>>>>>> termination in the >>>>>>>> >>>>>>>> >>>>>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>>>>> >>>>>>>>>> >>>>>>>> (I believe) >>>>>>>> >>>>>>>> >>>>>>>>>> at least as severe as would happen in an all ECN world. >>>>>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>>>>> specifically (some other flow might get terminated instead). >>>>>>>>>> I think this is true, though it also implies that [1] >>>>>>>>>> >>>>>>>>>> >>>>>>>> end-to-end ECN >>>>>>>> >>>>>>>> >>>>>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>>>>> >>>>>>>>>> >>>>> mechanism (eg >>>>> >>>>> >>>>>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>>>>> >>>>>>>>>> >>>>>>>> PCN-domain >>>>>>>> >>>>>>>> >>>>>>>>>> has also failed, [3] the flows which are terminated >>>>>>>>>> >>>>>>>>>> >>>>>> aren't other >>>>>> >>>>>> >>>>>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>>>>> misconfiguration. >>>>>>>>>> >>>>>>>>>> Best wishes >>>>>>>>>> Phil >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Michael Menth >>>>>>>>>>> >>>>>>>>>>> >>>>>> [mailto:menth@informatik.uni-wuerzburg.de] >>>>>> >>>>>> >>>>>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>>>>> >>>>>>>>>>> >>>>>>> khchan@nortel.com; >>>>>>> >>>>>>> >>>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>>>>> >>>>>>>>>>> >>>>>>> steven.blake@ericsson.com; >>>>>>> >>>>>>> >>>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>>>>> >>>>>>>>>>> Hi Toby, >>>>>>>>>>> >>>>>>>>>>> as I understand the proposal, the motivation is to >>>>>>>>>>> >>>>>>>>>>> >>>>>>> avoid 01/10 >>>>>>> >>>>>>> >>>>>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> network since >>>>>>>> >>>>>>>> >>>>>>>>>> 01/10 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> However, there is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>>>>> >>>>>>>>>>> >>>>> may not be >>>>> >>>>> >>>>>>>> dropped >>>>>>>> >>>>>>>> >>>>>>>>>> by >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>>>>> >>>>>>>>>>> >>>>>>> are not ECN >>>>>>> >>>>>>> >>>>>>>>>> capable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> guaranteed that >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> exactly the marked flow going over an overloaded >>>>>>>>>>> >>>>>>>>>>> >>>>> ECN node is >>>>> >>>>> >>>>>>>>>> terminated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Just want to say that this solution wants to solve a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> problem that >>>>>>>> >>>>>>>> >>>>>>>>>> exists >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> does not fully >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>>>>> >>>>>>>>>>> >>>>>>> spending two DSCP >>>>>>> >>>>>>> >>>>>>>>>> values >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> is quite expensive. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Michael >>>>>>>>>>> >>>>>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> All, >>>>>>>>>>>> >>>>>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> and feel we >>>>>>>>>> may >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> lots of pros >>>>>>> >>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> >>>>>>>>>> few >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> proposal I will go >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> through the simplified version without Affected >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> marking first: >>>>>>> >>>>>>> >>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>> >>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>>>>> >>>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> the same PCN >>>>>> >>>>>> >>>>>>>>>> behaviour >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> aggregate. >>>>>>>>>>>> >>>>>>>>>>>> Pros: >>>>>>>>>>>> o Termination marking and admission marking are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> independent, >>>>>>> >>>>>>> >>>>>>>> eg >>>>>>>> >>>>>>>> >>>>>>>>>>>> termination marking can be done after a packet has been >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> admission >>>>>>>> >>>>>>>> >>>>>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> having to read >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> implement. (Note: >>>>>>>> >>>>>>>> >>>>>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>>>>> >>>>>>>>>>>> >>>>> 3SM & CL, see >>>>> >>>>> >>>>>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>>>>> >>>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> ECT(1). This is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> region, due to >>>>>> >>>>>> >>>>>>>> some >>>>>>>> >>>>>>>> >>>>>>>>>> fort >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> for a single >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> domain deployment of PCN). >>>>>>>>>>>> >>>>>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> ECT(1) in some >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>>>>> >>>>>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> simply reads its >>>>>>>> >>>>>>>> >>>>>>>>>> DSCP. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> This is probably easier than checking both its >>>>>>>>>>>> >>>>>>>>>>>> >>>>> DSCP & ECN >>>>> >>>>> >>>>>>>> fields. >>>>>>>> >>>>>>>> >>>>>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> could deploy SM >>>>>>>> >>>>>>>> >>>>>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> DSCP. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> too horrific >>>>>>>> >>>>>>>> >>>>>>>>>>>> happens. >>>>>>>>>>>> [2] could just deploy admission control & add >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> termination later, >>>>>>>> >>>>>>>> >>>>>>>>>> just by >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> encoding and check >>>>>>>>>> for >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>>>>> >>>>>>>>>>>> Cons: >>>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> (Although >>>>>>>> >>>>>>>> >>>>>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> all PCN BAs?) >>>>>>> >>>>>>> >>>>>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>>>>> >>>>>>>>>>>> >>>>> egress with >>>>> >>>>> >>>>>>>>>> its ECN = >>>>>>>>>> 11 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> and it really is required to preserve this info >>>>>>>>>>>> >>>>>>>>>>>> >>>>> across the >>>>> >>>>> >>>>>>>>>> PCN-domain, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> (tunnelling) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> (ECMP) that uses >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> of packets >>>>>>>> >>>>>>>> >>>>>>>>>> within >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> they know of >>>>>>> >>>>>>> >>>>>>>> an >>>>>>>> >>>>>>>> >>>>>>>>>> ECMP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> mis-ordering >>>>>>>>>> when >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> there is termination marking may be acceptable >>>>>>>>>>>> >>>>>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> modified as >>>>>>>> >>>>>>>> >>>>>>>>>>>> follows: >>>>>>>>>>>> >>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>> >>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>>>>> >>>>>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>>>>> >>>>>>>>>>>> >>>>> the above. >>>>> >>>>> >>>>>>>> However >>>>>>>> >>>>>>>> >>>>>>>>>> there >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> affected >>>>>>>> >>>>>>>> >>>>>>>>>> marked >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> reset the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>>>>> >>>>>>>>>>>> >>>>> be needed >>>>> >>>>> >>>>>>>>>> to see if >>>>>>>>>> this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> skews the results and causes significant >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> over-termination or >>>>>> >>>>>> >>>>>>>> not. >>>>>>>> >>>>>>>> >>>>>>>>>>>> Please could people look through this scheme and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> highlight any >>>>>>>> >>>>>>>> >>>>>>>>>>>> additional concerns that they may have (and extra >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> benefits too). >>>>>>>> I >>>>>>>> >>>>>>>> >>>>>>>>>> would >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> like to get as many opinions as possible. >>>>>>>>>>>> >>>>>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> "why not try >>>>>>>>>> this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> possible >>>>>>>> >>>>>>>> >>>>>>>>>>>> schemes on the table and people need to start putting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> down much >>>>>>>> >>>>>>>> >>>>>>>>>> clearer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> pros and cons for the schemes they support... >>>>>>>>>>>> >>>>>>>>>>>> >>>>> So it could >>>>> >>>>> >>>>>>>>>> be good to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> have a similar "one page" email about a specific >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> scheme that >>>>>> >>>>>> >>>>>>>> only >>>>>>>> >>>>>>>> >>>>>>>>>> uses >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>>>>> >>>>>>>>>>>> Toby >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> ____________________________________________________________________ >>> >>>>>> >>>>>> >>>>>>>>>>>> Toby Moncaster, >>>>>>>>>>>> >>>>>>>>>>>> >>>>> Networks Research >>>>> >>>>> >>>>>>>>>> Centre, BT >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> 1473 648734 >>>>>> >>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PCN mailing list >>>>>>>> PCN@ietf.org >>>>>>>> http://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 >>> >>> >>> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 03:14:09 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A5D28C2EF; Fri, 22 Feb 2008 03:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.981 X-Spam-Level: ** X-Spam-Status: No, score=2.981 tagged_above=-999 required=5 tests=[AWL=-2.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 WSE7NqZ92RCd; Fri, 22 Feb 2008 03:14:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D54F3A6CB9; Fri, 22 Feb 2008 03:14:06 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045623A67D7 for ; Fri, 22 Feb 2008 03:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CxI9yaQuuk for ; Fri, 22 Feb 2008 03:14:03 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6FD463A6CBB for ; Fri, 22 Feb 2008 03:14:02 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3C2AC198E0D; Fri, 22 Feb 2008 12:13:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2D264198E05; Fri, 22 Feb 2008 12:13:58 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 96CA3198DFD; Fri, 22 Feb 2008 12:13:48 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1MBDmV12914; Fri, 22 Feb 2008 12:13:48 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 31121C837A; Fri, 22 Feb 2008 12:13:48 +0100 (CET) Message-ID: <47BEAE2D.1090305@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 12:12:45 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ingemar Johansson S References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, Ingemar Johansson S wrote: > Hi > > See inline > > /Ingemar > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: den 22 februari 2008 10:13 >> To: Ingemar Johansson S >> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >> Subject: Re: [PCN] FW: RE: PCN encoding option >> >> Hi Ingemar, >> >> this solution essentially spends a DSCP to save 11-marking >> through the PCN domain and allow them to be PCN-marked. This >> is a rather high price, in particular because the PCN packets >> need to be remarked to 00. This has the consequence that ECN >> capability is lost for the rest of the path. >> > Not sure that I agree, yes the ECT(0), ECT(1) codepoints are lost and > there goes also the ECN nonce and the "inband" ECN capability signaling. > A router outside the PCN domain wont be able to set ECN-CE. However if > the ECN capability is negotiated out of band for the wireless endpoints > and the up and downlink wireless nodes, these will be ECN-CE capable but > without the nonce capability. > The difficulty is that the information for each packet whether 10 or 01 must be kept, that says RFC4774: Similarly, if a packet that *could* be using default semantics is marked with the ECN codepoint "01", then this codepoint should not be changed to "10" in the network (and a "10" codepoint should not be changed to "01"). This requirement is necessary to avoid interference with the transport protocol's use of the ECN nonce [RFC3540]. This would require a per packet signalling ... > > >> Therefore, I opt for one of the two versions >> 1) discard 11-marked PCN packets before entering the PCN domain OR >> 2) let them go through the PCN domain, take them into account >> for metering, but do not remark them. >> The first option loses ECN capability for PCN traffic, the >> second option keeps it on the subpath before entering the PCN domain. >> > Not sure I follow here. What would option 2 look like? > My interpretation: Packets with DSCP=EF enters the PCN domain, at > ingress they are remarked as DSCP=PCN unless ECN="11", in which case > DSCP=EF. What about ECN="01" or "01" will these also be kept as DSCP=EF > or will the ECN bits be set to "00". > Please explain. > EF DSCP is remarked to PCN in any case. 1) 11-marked PCN packets are dropped by the PCN ingress 2) 11 is kept as is and 01/10 marking is reset to 00 (no-precongestion). The PCN egress node resets 10/01 marked packets to 00. Therefore, the ECN capability for PCN traffic is lost 1) completely 2) for the partial downstream path starting with the PCN ingress node. It's true that PCN marking can get problems if the majority of PCN packets was CE-marked when entering the PCN domain. This kind of traffic also cheats ECN when it doesn't back off. I just want to say: even TCP senders and receivers can cheat, do we care? The question is what's more important: remaining ECN functionality for the partial path up to the PCN ingress node or safety against too many 11-marked packets. I see these options (1 and 2) and have no particular preference. Regards, Michael > > > >> Regards, >> >> Michael >> >> Ingemar Johansson S wrote: >> >>> Hi >>> >>> Answers inline >>> >>> >>> >>>> -----Original Message----- >>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >>>> Sent: den 21 februari 2008 15:34 >>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; >>>> philip.eardley@bt.com >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>> menth@informatik.uni-wuerzburg.de >>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>> >>>> Hi Ingemar, >>>> >>>> This is exactly the sort of thing Phil and I were hoping >>>> >> to trigger >> >>>> people to write in response to our email. We are hoping to >>>> >> settle on >> >>>> what are the real options people support for the encoding and why >>>> they support them... >>>> >>>> Just one quick observation - if we have to leave 11 >>>> >> unchanged across >> >>>> the PCN domain this will mean that such packets can't be >>>> >> PCN marked >> >>>> and thus they should not form part of any PCN aggregate (in my >>>> opinion)... >>>> >>>> >>> Realized that this is one (big) problem, thanks for >>> >> pointing out this >> >>> issue. >>> >>> The next alternative is then >>> PCN Meaning ECN DSCP >>> ============================= >>> PCN capable 00 PCN 1 >>> Admission Mark 01 PCN 1 >>> Termination Mark 10 PCN 1 >>> >>> PCN capable+ECN CE 00 PCN 2 >>> AM+ECN CE 01 PCN 2 >>> TM+ECN CE 10 PCN 2 >>> >>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN >>> >> egress PCN >> >>> 2 is mapped back to the ECN bits as ECN-CE "11". >>> >>> AfM can also be included in the schema >>> >>> I know this does cost an extra DSCP codepoint and it completely >>> disregards the leakage issue, also it possible that this >>> >> alternative >> >>> or something similar is given in the PCN encoding draft but I don't >>> think so as this alternative does not preserve the end to end ECN >>> semantics to 100%, rather it assumes that negotiation of the use of >>> ECN is done out of band at session setup. >>> >>> /Ingemar >>> >>> >>> >>> >>>> Toby >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ingemar Johansson S >>>>> >> [mailto:ingemar.s.johansson@ericsson.com] >> >>>>> Sent: 21 February 2008 13:47 >>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>> >>>>> Hi >>>>> >>>>> Putting the issues with "leakage" aside (I cannot tell >>>>> >> how serious >> >>>>> this problem really is). >>>>> >>>>> I would prefer to sacrifice the end to end ECN semantics for the >>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The >>>>> reason is simply that from a realtime communication >>>>> >>>>> >>>> scenario with out >>>> >>>> >>>>> of band signaling it is always possible to negotiate the >>>>> >>>>> >>>> use of ECN CE >>>> >>>> >>>>> mark in wireless nodes by means of eg. SIP signaling. >>>>> >> Also, atleast >> >>>>> for RTP/UDP I see little use for ECN nonce like it is done >>>>> >>>>> >>>> with TCP as >>>> >>>> >>>>> this is more or less an anti-cheat feature. >>>>> >>>>> >>>>> One would then end up with a PCN encoding schema like (I beleve >>>>> option 5 in figure 1 in the PCN encoding draft) is the closest. >>>>> >>>>> PCN Meaning ECN DSCP >>>>> ============================= >>>>> PCN capable 00 PCN 1 >>>>> Admission Mark 01 PCN 1 >>>>> Termination Mark 10 PCN 1 >>>>> >>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>>>> >>>>> >>>> set to "00", >>>> >>>> >>>>> likewise at PCN egress. ECN CE is however left untouched. >>>>> >>>>> >>>> This has the >>>> >>>> >>>>> effect that routers will be able to set ECN-CE on packets >>>>> >>>>> >>>> before they >>>> >>>> >>>>> enter the first PCN domain, after exit from the PCN >>>>> >> domain routers >> >>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>>>> Wireless nodes >>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>>>> >>>>> >>>> however set >>>> >>>> >>>>> ECN CE as this is can be managed by out of band signaling. >>>>> >>>>> Besides this I would prefer a solution that maintains end to end >>>>> semantics regardless of DSCP value. If one consider DCCP we >>>>> >>>>> >>>> don't know >>>> >>>> >>>>> today if it will be a best effort traffic alternatiive or >>>>> >> if there >> >>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. >>>>> >>>>> /Ingemar >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>> Sent: den 21 februari 2008 11:07 >>>>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> >>>>>> Hi Phil, Hi all >>>>>> >>>>>> In order to make a selection of one single (or two) options, I >>>>>> think that the PCN WG should get the possibility to >>>>>> >> study all the >> >>>>>> possible and PCN relevant encoding options. >>>>>> >>>>>> In my opinion the goal of the encoding draft is to provide this >>>>>> information to the PCN-WG. >>>>>> Based on this information the PCN WG can discuss and >>>>>> >> decide which >> >>>>>> of the options should be used. >>>>>> >>>>>> The below text is copied from the current version of the >>>>>> >> encoding >> >>>>>> draft! >>>>>> Four options are described! >>>>>> Please note that the encoding draft should list all relevant >>>>>> options with advantages and disadvantages. >>>>>> >>>>>> Phil and Ingemar, if you can add advantages, >>>>>> >> disadvantages to the >> >>>>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the >>>>>> encoding draft, please do. >>>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>> 3.2. Encoding Using DSCP Field >>>>>> >>>>>> In this type of encoding and transport method the >>>>>> >>>>>> >>>> congestion and >>>> >>>> >>>>>> precongestion information is encoded into the 6 DSCP >>>>>> >>>>>> >>>>> bits that are >>>>> >>>>> >>>>>> transported in the IP header of the data packets. >>>>>> >>>>>> >>>> Four possible >>>> >>>> >>>>>> alternatives can be distinguished, as can be seen in >>>>>> >>>>>> >>>>> Figure 3, with >>>>> >>>>> >>>>>> details provided by >>>>>> >> draft-westberg-pcn-load-control-02.txt [4]. >> >>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>>>> >>>>>> >>>>> need three >>>>> >>>>> >>>>>> additional DSCP values and Option 10 needs four >>>>>> >> additional DSCP >> >>>>>> values. Note that all additional and experimental DSCP >>>>>> >>>>>> >>>>> values are >>>>> >>>>> >>>>>> representing and are associated with the same PHB. >>>>>> >>>>>> >>>> The 1st, 2nd, >>>> >>>> >>>>>> 3rd, and 4th DSCP values are representing DSCP values that are >>>>>> assigned by IANA as DSCP experimental values, see RFC >>>>>> >> 2211 [9]. >> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------- >>>>>> --------- >>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 Add >>>>>> |DSCP 4 >>>>>> || >>>>>> ===========++==========+===========+===========+===========+== >>>>>> =========| >>>>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | >>>>>> NA | >>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>> ----------| >>>>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | >>>>>> NA | >>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>> ----------| >>>>>> | Option 8 || Not-PCN | PCN | AM | TM | >>>>>> NA | >>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>> ----------| >>>>>> | Option 9 || Not-PCN | PCN | AM | TM | >>>>>> AfM | >>>>>> >>>>>> -------------------------------------------------------------- >>>>>> --------- >>>>>> >>>>>> Notes: Not-PCN means the packet is not PCN capable. >>>>>> >>>>>> Figure 2: Encoding of PCN Information Using DSCP Field >>>>>> >>>>>> 3.2.1. Benefits of Using DSCP Field >>>>>> >>>>>> The main benefit of using the DSCP field is that it is not >>>>>> affecting >>>>>> the end-to-end ECN semantics and therefore the issues >>>>>> >>>>>> >>>>> and concerns >>>>> >>>>> >>>>>> raised in RFC 4774 [22] are not applicable for this encoding >>>>>> scheme. >>>>>> Another benefit is related to the fact that all 4 >>>>>> >> DSCP encoding >> >>>>>> options depicted in Figure 2 can support the PCN capable not >>>>>> congested (PCN) indication, the admission control >>>>>> >> (AM) and flow >> >>>>>> termination (TM) encoding states. In addition Option 8 >>>>>> >>>>>> >>>>> and 10 can >>>>> >>>>> >>>>>> support the ECMP solution. >>>>>> >>>>>> 3.2.2. Drawbacks of Using DSCP Field >>>>>> >>>>>> This type of encoding needs to use per PHB, in addition to the >>>>>> original DSCP and depending on the encoding option used, >>>>>> >>>>>> >>>>> one, two, >>>>> >>>>> >>>>>> three, or four DSCP values, respectively. These >>>>>> >>>>>> >>>> additional DSCP >>>> >>>> >>>>>> values can be taken from the DSCP values that are not >>>>>> >>>>>> >>>> defined by >>>> >>>> >>>>>> standards action, see RFC 2211 [9]. Note that all the >>>>>> >>>>>> >>>> additional >>>> >>>> >>>>>> DSCP values are representing and are associated with one >>>>>> >>>>>> >>>>> PHB. The >>>>> >>>>> >>>>>> value of this DSCP/PHB can either follow a standards >>>>>> >> action or >> >>>>>> use a >>>>>> value that is applied for experimental or local use. It is >>>>>> important >>>>>> to note that the number of the DSCP values used for local or >>>>>> experimental use is restricted and therefore the number of >>>>>> different >>>>>> PHBs supported in the PCN domain will also be restricted. >>>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>> >>>>>>> >>>>>> Behalf Of >>>>>> >>>>>> >>>>>>> philip.eardley@bt.com >>>>>>> Sent: donderdag 21 februari 2008 10:24 >>>>>>> To: ingemar.s.johansson@ericsson.com; >>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>> >>>>>>> Ingemar >>>>>>> >>>>>>> Re >>>>>>> >>>>>>> >>>>>>> >>>>>>>> consider the end to end ECN usecases >>>>>>>> >>>>>>>> >>>>>>> I believe that the emails below about Toby's encoding >>>>>>> >>>>>>> >>>> proposal do >>>> >>>> >>>>>>> indeed already consider ECN. Would appreciate it if you >>>>>>> >>>>>>> >>>> could add >>>> >>>> >>>>>>> further text to it to better capture the (pros and) cons. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> more DSCP codepoints >>>>>>>> >>>>>>>> >>>>>>> I think you may be proposing an encoding that uses all dscp >>>>>>> >>>>>>> >>>>>> codepoints >>>>>> >>>>>> >>>>>>> (as has Georgios). That's fine - but a "1 pager" >>>>>>> setting out this option with its pros and cons (ie >>>>>>> >>>>>>> >>>>> similar to what >>>>> >>>>> >>>>>>> toby has done below) is needed I think! At the moment we >>>>>>> >>>>>>> >>>>>> have lots of >>>>>> >>>>>> >>>>>>> options on the table - in order to reach a decision, I >>>>>>> >>>>>>> >>>>>> think we really >>>>>> >>>>>> >>>>>>> need very few options but with their pros and cons better >>>>>>> >>>>>>> >>>>> laid out. >>>>> >>>>> >>>>>>> I haven't managed to get to your draft yet, sorry (next week >>>>>>> hopefully) >>>>>>> - >>>>>>> Thanks >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ingemar Johansson S >>>>>>>> >>>>>>>> >>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>> >>>>>> >>>>>>>> Sent: 21 February 2008 06:43 >>>>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>>>> >>>>>>>> >>>> menth@informatik.uni-wuerzburg.de; >>>> >>>> >>>>>>>> Moncaster,T,Toby,CXR9 R >>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> In this discussion it may be well worth the effort to >>>>>>>> >>>>>>>> >>>>>>> consider the end >>>>>>> >>>>>>> >>>>>>>> to end ECN usecases that we foresee when considering >>>>>>>> >>>>>>>> >>>>> various PCN >>>>> >>>>> >>>>>>>> encoding options. >>>>>>>> Please have a look at >>>>>>>> >>>>>>>> >>>>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>> >>>> >>>>>>>> for a discussion of the use cases and a motivation to why >>>>>>>> >>>>>>>> >>>>>> end to end >>>>>> >>>>>> >>>>>>> ECN >>>>>>> >>>>>>> >>>>>>>> should be maintained even across PCN nodes even for non >>>>>>>> >>>>>>>> >>>>>> DF traffic. >>>>>> >>>>>> >>>>>>>> That said I realize that there is some cost associated to >>>>>>>> >>>>>>>> >>>>>>> the use of >>>>>>> >>>>>>> >>>>>>>> DSCP codepoints, this cost must however be weighted against >>>>>>>> >>>>>>>> >>>>>>> the risk >>>>>>> >>>>>>> >>>>>>>> that other functionality like end to end ECN semantics is >>>>>>>> >>>>>>>> >>>>>> probably >>>>>> >>>>>> >>>>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>>>> >>>>>>>> >>>>> bits. It is >>>>> >>>>> >>>>>>> easy >>>>>>> >>>>>>> >>>>>>>> to see that if one wish to maintain support for end to >>>>>>>> >>>>>>>> >>>>>> end ECN (not >>>>>> >>>>>> >>>>>>> only >>>>>>> >>>>>>> >>>>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>>>> I am not explicitly saying don't do this or that but I wish >>>>>>>> >>>>>>>> >>>>>>> to avoid a >>>>>>> >>>>>>> >>>>>>>> situation where one technique has to be avoided in favor of >>>>>>>> >>>>>>>> >>>>>>> the other >>>>>>> as >>>>>>> >>>>>>> >>>>>>>> it may in the end prevent deployment of both. If one can >>>>>>>> >>>>>>>> >>>>>>> yank the two >>>>>>> >>>>>>> >>>>>>>> together so much the better even though the cost e.g in >>>>>>>> >>>>>>>> >>>>> DSCP code >>>>> >>>>> >>>>>>> points >>>>>>> >>>>>>> >>>>>>>> is regarded as higher. >>>>>>>> >>>>>>>> Regards >>>>>>>> Ingemar >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>>>> >>>>>>>>> >>>>>>> On Behalf >>>>>>> >>>>>>> >>>>>>>>> Of philip.eardley@bt.com >>>>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>> >>>>>>>>> Thanks Michael >>>>>>>>> >>>>>>>>> I agree with you that spending one DSCP value is quite >>>>>>>>> >>>>>>>>> >>>>>> expensive >>>>>> >>>>>> >>>>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>>>> >>>>>>>>> >>>>>> of really >>>>>> >>>>>> >>>>>>>>> assessing this properly is for an alternative proposal >>>>>>>>> >>>>>>>>> >>>>>> (with pros >>>>>> >>>>>> >>>>>>>>> and cons) that requires only one DSCP. >>>>>>>>> Then we can see where the consensus for the best >>>>>>>>> >>>>>>>>> >>>> (/least bad) >>>> >>>> >>>>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>>>> >>>>>>>>> >>>>> or against >>>>> >>>>> >>>>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>>>> >>>>>>>>> >>>>>>> definitely >>>>>>> >>>>>>> >>>>>>>>> the way to go, until compared it in detail with other >>>>>>>>> >>>>>>>>> >>>>> proposals. >>>>> >>>>> >>>>>>>>> So I think it would be really useful to have a "1 >>>>>>>>> >>>>>>>>> >>>> pager" for >>>> >>>> >>>>>>>>> alternative >>>>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>>>> >>>>>>>>> >>>>>>> Philadelphia >>>>>>> >>>>>>> >>>>>>>>> discussions more productive. >>>>>>>>> >>>>>>>>> >>>>>>>>> You're correct about one of the motivations >>>>>>>>> >>>>>>>>> >>>>>> (advantages) for this >>>>>> >>>>>> >>>>>>>>> proposal (although I don't think the issues are exactly >>>>>>>>> >>>>>>>>> >>>>>>> the same for >>>>>>> >>>>>>> >>>>>>>>> 11 leakage as 01/10 leakage). >>>>>>>>> >>>>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>>>> >>>>>>>>> >>>>> domain. If the >>>>> >>>>> >>>>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>>>> >>>>>>>>> >>>>>> down (seems >>>>>> >>>>>> >>>>>>>>> reasonable). If they're not capable, then the impact >>>>>>>>> >>>>>>>>> >>>>>> outside the >>>>>> >>>>>> >>>>>>>>> domain isn't any different to what would happen without >>>>>>>>> >>>>>>>>> >>>>>>> PCN-domain. >>>>>>> >>>>>>> >>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>>>> Then this will lead to either flow admission or >>>>>>>>> >>>>>>>>> >>>>>>> termination in the >>>>>>> >>>>>>> >>>>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>>>> >>>>>>>>> >>>>>>> (I believe) >>>>>>> >>>>>>> >>>>>>>>> at least as severe as would happen in an all ECN world. >>>>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>>>> specifically (some other flow might get terminated instead). >>>>>>>>> I think this is true, though it also implies that [1] >>>>>>>>> >>>>>>>>> >>>>>>> end-to-end ECN >>>>>>> >>>>>>> >>>>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>>>> >>>>>>>>> >>>> mechanism (eg >>>> >>>> >>>>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>>>> >>>>>>>>> >>>>>>> PCN-domain >>>>>>> >>>>>>> >>>>>>>>> has also failed, [3] the flows which are terminated >>>>>>>>> >>>>>>>>> >>>>> aren't other >>>>> >>>>> >>>>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>>>> misconfiguration. >>>>>>>>> >>>>>>>>> Best wishes >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Michael Menth >>>>>>>>>> >>>>>>>>>> >>>>> [mailto:menth@informatik.uni-wuerzburg.de] >>>>> >>>>> >>>>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>>>> >>>>>>>>>> >>>>>> khchan@nortel.com; >>>>>> >>>>>> >>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>>>> >>>>>>>>>> >>>>>> steven.blake@ericsson.com; >>>>>> >>>>>> >>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>>>> >>>>>>>>>> Hi Toby, >>>>>>>>>> >>>>>>>>>> as I understand the proposal, the motivation is to >>>>>>>>>> >>>>>>>>>> >>>>>> avoid 01/10 >>>>>> >>>>>> >>>>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>>>> >>>>>>>>>> >>>>>>> network since >>>>>>> >>>>>>> >>>>>>>>> 01/10 >>>>>>>>> >>>>>>>>> >>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> However, there is >>>>>>>>> >>>>>>>>> >>>>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>>>> >>>>>>>>>> >>>> may not be >>>> >>>> >>>>>>> dropped >>>>>>> >>>>>>> >>>>>>>>> by >>>>>>>>> >>>>>>>>> >>>>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>>>> >>>>>>>>>> >>>>>> are not ECN >>>>>> >>>>>> >>>>>>>>> capable. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>>>> >>>>>>>>>> >>>>>>>>> guaranteed that >>>>>>>>> >>>>>>>>> >>>>>>>>>> exactly the marked flow going over an overloaded >>>>>>>>>> >>>>>>>>>> >>>> ECN node is >>>> >>>> >>>>>>>>> terminated. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Just want to say that this solution wants to solve a >>>>>>>>>> >>>>>>>>>> >>>>>>> problem that >>>>>>> >>>>>>> >>>>>>>>> exists >>>>>>>>> >>>>>>>>> >>>>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>>>> >>>>>>>>>> >>>>>>>>> does not fully >>>>>>>>> >>>>>>>>> >>>>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>>>> >>>>>>>>>> >>>>>> spending two DSCP >>>>>> >>>>>> >>>>>>>>> values >>>>>>>>> >>>>>>>>> >>>>>>>>>> is quite expensive. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> and feel we >>>>>>>>> may >>>>>>>>> >>>>>>>>> >>>>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>>>> >>>>>>>>>>> >>>>>> lots of pros >>>>>> >>>>>> >>>>>>> and >>>>>>> >>>>>>> >>>>>>>>> few >>>>>>>>> >>>>>>>>> >>>>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> proposal I will go >>>>>>>>> >>>>>>>>> >>>>>>>>>>> through the simplified version without Affected >>>>>>>>>>> >>>>>>>>>>> >>>>>> marking first: >>>>>> >>>>>> >>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>> >>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>>>> >>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>>>> >>>>>>>>>>> >>>>> the same PCN >>>>> >>>>> >>>>>>>>> behaviour >>>>>>>>> >>>>>>>>> >>>>>>>>>>> aggregate. >>>>>>>>>>> >>>>>>>>>>> Pros: >>>>>>>>>>> o Termination marking and admission marking are >>>>>>>>>>> >>>>>>>>>>> >>>>>> independent, >>>>>> >>>>>> >>>>>>> eg >>>>>>> >>>>>>> >>>>>>>>>>> termination marking can be done after a packet has been >>>>>>>>>>> >>>>>>>>>>> >>>>>>> admission >>>>>>> >>>>>>> >>>>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> having to read >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>>>> >>>>>>>>>>> >>>>>>> implement. (Note: >>>>>>> >>>>>>> >>>>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>>>> >>>>>>>>>>> >>>> 3SM & CL, see >>>> >>>> >>>>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>>>> >>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> ECT(1). This is >>>>>>>>> >>>>>>>>> >>>>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>>>> >>>>>>>>>>> >>>>> region, due to >>>>> >>>>> >>>>>>> some >>>>>>> >>>>>>> >>>>>>>>> fort >>>>>>>>> >>>>>>>>> >>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> for a single >>>>>>>>> >>>>>>>>> >>>>>>>>>>> domain deployment of PCN). >>>>>>>>>>> >>>>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> ECT(1) in some >>>>>>>>> >>>>>>>>> >>>>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>>>> >>>>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>>>> >>>>>>>>>>> >>>>>>> simply reads its >>>>>>> >>>>>>> >>>>>>>>> DSCP. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> This is probably easier than checking both its >>>>>>>>>>> >>>>>>>>>>> >>>> DSCP & ECN >>>> >>>> >>>>>>> fields. >>>>>>> >>>>>>> >>>>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>>>> >>>>>>>>>>> >>>>>>> could deploy SM >>>>>>> >>>>>>> >>>>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> DSCP. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>>>> >>>>>>>>>>> >>>>>>> too horrific >>>>>>> >>>>>>> >>>>>>>>>>> happens. >>>>>>>>>>> [2] could just deploy admission control & add >>>>>>>>>>> >>>>>>>>>>> >>>>>>> termination later, >>>>>>> >>>>>>> >>>>>>>>> just by >>>>>>>>> >>>>>>>>> >>>>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> encoding and check >>>>>>>>> for >>>>>>>>> >>>>>>>>> >>>>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>>>> >>>>>>>>>>> Cons: >>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>>>> >>>>>>>>>>> >>>>>>> (Although >>>>>>> >>>>>>> >>>>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>>>> >>>>>>>>>>> >>>>>> all PCN BAs?) >>>>>> >>>>>> >>>>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>>>> >>>>>>>>>>> >>>> egress with >>>> >>>> >>>>>>>>> its ECN = >>>>>>>>> 11 >>>>>>>>> >>>>>>>>> >>>>>>>>>>> and it really is required to preserve this info >>>>>>>>>>> >>>>>>>>>>> >>>> across the >>>> >>>> >>>>>>>>> PCN-domain, >>>>>>>>> >>>>>>>>> >>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> (tunnelling) >>>>>>>>> >>>>>>>>> >>>>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> (ECMP) that uses >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>>>> >>>>>>>>>>> >>>>>>> of packets >>>>>>> >>>>>>> >>>>>>>>> within >>>>>>>>> >>>>>>>>> >>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>>>> >>>>>>>>>>> >>>>>> they know of >>>>>> >>>>>> >>>>>>> an >>>>>>> >>>>>>> >>>>>>>>> ECMP >>>>>>>>> >>>>>>>>> >>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> mis-ordering >>>>>>>>> when >>>>>>>>> >>>>>>>>> >>>>>>>>>>> there is termination marking may be acceptable >>>>>>>>>>> >>>>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>>>> >>>>>>>>>>> >>>>>>> modified as >>>>>>> >>>>>>> >>>>>>>>>>> follows: >>>>>>>>>>> >>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>> >>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>>>> >>>>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>>>> >>>>>>>>>>> >>>> the above. >>>> >>>> >>>>>>> However >>>>>>> >>>>>>> >>>>>>>>> there >>>>>>>>> >>>>>>>>> >>>>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>>>> >>>>>>>>>>> >>>>>>> affected >>>>>>> >>>>>>> >>>>>>>>> marked >>>>>>>>> >>>>>>>>> >>>>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> reset the >>>>>>>>> >>>>>>>>> >>>>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>>>> >>>>>>>>>>> >>>> be needed >>>> >>>> >>>>>>>>> to see if >>>>>>>>> this >>>>>>>>> >>>>>>>>> >>>>>>>>>>> skews the results and causes significant >>>>>>>>>>> >>>>>>>>>>> >>>>> over-termination or >>>>> >>>>> >>>>>>> not. >>>>>>> >>>>>>> >>>>>>>>>>> Please could people look through this scheme and >>>>>>>>>>> >>>>>>>>>>> >>>>>>> highlight any >>>>>>> >>>>>>> >>>>>>>>>>> additional concerns that they may have (and extra >>>>>>>>>>> >>>>>>>>>>> >>>>>>> benefits too). >>>>>>> I >>>>>>> >>>>>>> >>>>>>>>> would >>>>>>>>> >>>>>>>>> >>>>>>>>>>> like to get as many opinions as possible. >>>>>>>>>>> >>>>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> "why not try >>>>>>>>> this >>>>>>>>> >>>>>>>>> >>>>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>>>> >>>>>>>>>>> >>>>>>> possible >>>>>>> >>>>>>> >>>>>>>>>>> schemes on the table and people need to start putting >>>>>>>>>>> >>>>>>>>>>> >>>>>>> down much >>>>>>> >>>>>>> >>>>>>>>> clearer >>>>>>>>> >>>>>>>>> >>>>>>>>>>> pros and cons for the schemes they support... >>>>>>>>>>> >>>>>>>>>>> >>>> So it could >>>> >>>> >>>>>>>>> be good to >>>>>>>>> >>>>>>>>> >>>>>>>>>>> have a similar "one page" email about a specific >>>>>>>>>>> >>>>>>>>>>> >>>>> scheme that >>>>> >>>>> >>>>>>> only >>>>>>> >>>>>>> >>>>>>>>> uses >>>>>>>>> >>>>>>>>> >>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>>>> >>>>>>>>>>> Toby >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> ____________________________________________________________________ >> >>>>> >>>>> >>>>>>>>>>> Toby Moncaster, >>>>>>>>>>> >>>>>>>>>>> >>>> Networks Research >>>> >>>> >>>>>>>>> Centre, BT >>>>>>>>> >>>>>>>>> >>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>>>> >>>>>>>>>>> >>>>> 1473 648734 >>>>> >>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> PCN mailing list >>>>>>> PCN@ietf.org >>>>>>> http://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 >> >> >> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:10:11 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1F83A6D01; Fri, 22 Feb 2008 07:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.21 X-Spam-Level: *** X-Spam-Status: No, score=3.21 tagged_above=-999 required=5 tests=[AWL=-2.853, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 7JP9kIEZpmNK; Fri, 22 Feb 2008 07:10:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFEF3A6CAF; Fri, 22 Feb 2008 07:10:06 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1663A68DF for ; Fri, 22 Feb 2008 07:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojg5X4R1limr for ; Fri, 22 Feb 2008 07:10:00 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9C0D83A6C6D for ; Fri, 22 Feb 2008 07:09:59 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 78DCE20E11; Fri, 22 Feb 2008 16:09:54 +0100 (CET) X-AuditID: c1b4fb3c-af8bebb000007e19-fe-47bee5c22a08 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58B4D20E24; Fri, 22 Feb 2008 16:09:54 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 16:09:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 16:09:52 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1D8@esealmw109.eemea.ericsson.se> In-Reply-To: <47BEAE2D.1090305@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Ach1RB2LxjOfwHSrRv2C3FrNG4CVdAAHm56Q References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> <47BEAE2D.1090305@informatik.uni-wuerzburg.de> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 22 Feb 2008 15:09:53.0919 (UTC) FILETIME=[FA74B0F0:01C87564] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael. Answer inline below. > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: den 22 februari 2008 12:13 > To: Ingemar Johansson S > Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > Subject: Re: [PCN] FW: RE: PCN encoding option > > Hi Ingemar, > > Ingemar Johansson S wrote: > > Hi > > > > See inline > > > > /Ingemar > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: den 22 februari 2008 10:13 > >> To: Ingemar Johansson S > >> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > >> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > >> Subject: Re: [PCN] FW: RE: PCN encoding option > >> > >> Hi Ingemar, > >> > >> this solution essentially spends a DSCP to save 11-marking through > >> the PCN domain and allow them to be PCN-marked. This is a > rather high > >> price, in particular because the PCN packets need to be > remarked to > >> 00. This has the consequence that ECN capability is lost > for the rest > >> of the path. > >> > > Not sure that I agree, yes the ECT(0), ECT(1) codepoints > are lost and > > there goes also the ECN nonce and the "inband" ECN > capability signaling. > > A router outside the PCN domain wont be able to set ECN-CE. > However if > > the ECN capability is negotiated out of band for the wireless > > endpoints and the up and downlink wireless nodes, these > will be ECN-CE > > capable but without the nonce capability. > > > > The difficulty is that the information for each packet > whether 10 or 01 must be kept, that says RFC4774: > > Similarly, if a packet that *could* be using default > semantics is marked with the ECN codepoint "01", then this > codepoint > should not be changed to "10" in the network (and a "10" codepoint > should not be changed to "01"). This requirement is necessary to > avoid interference with the transport protocol's use of > the ECN nonce > [RFC3540]. > > This would require a per packet signalling ... Not 100% convinced here, ECN codepoints "01" and "10" can be reset to "00", that is my interpretation of 4.3 in RFC4774. What might be seen as odd is perhaps that after PCN egress the ECN pattern using this trick will only use the code points "00" or "11" instead of the normal "01", "10" and "11" (if ECN capable). Routers located after PCN egress won't be able to set ECN "11" as the flow is not anymore regarded as ECN capable (on IP level). Wireless nodes such as LTE-eNB can however be instructed to set ECN "11" during congestion as this then controlled using out of band signaling, this out of band signaling is in turn controlled by policy rules that will limit the risk for cheating. Note that this is meant for realtime traffic and a means to do efficient adaptation in a wireless enviroment where the transmission capacity for a single user changes changes dynamically due to physical factors such as shadowing et.c. > > > > > > >> Therefore, I opt for one of the two versions > >> 1) discard 11-marked PCN packets before entering the PCN domain OR > >> 2) let them go through the PCN domain, take them into account for > >> metering, but do not remark them. > >> The first option loses ECN capability for PCN traffic, the second > >> option keeps it on the subpath before entering the PCN domain. > >> > > Not sure I follow here. What would option 2 look like? > > My interpretation: Packets with DSCP=EF enters the PCN domain, at > > ingress they are remarked as DSCP=PCN unless ECN="11", in > which case > > DSCP=EF. What about ECN="01" or "01" will these also be kept as > > DSCP=EF or will the ECN bits be set to "00". > > Please explain. > > > EF DSCP is remarked to PCN in any case. > 1) 11-marked PCN packets are dropped by the PCN ingress > 2) 11 is kept as is > and 01/10 marking is reset to 00 (no-precongestion). The PCN > egress node resets 10/01 marked packets to 00. Therefore, the > ECN capability for PCN traffic is lost > 1) completely > 2) for the partial downstream path starting with the PCN ingress node. > > It's true that PCN marking can get problems if the majority > of PCN packets was CE-marked when entering the PCN domain. > This kind of traffic also cheats ECN when it doesn't back > off. I just want to say: even TCP senders and receivers can > cheat, do we care? The question is what's more > important: remaining ECN functionality for the partial path > up to the PCN ingress node or safety against too many > 11-marked packets. I see these options (1 and 2) and have no > particular preference. > > Regards, > > Michael > > > > > > > > >> Regards, > >> > >> Michael > >> > >> Ingemar Johansson S wrote: > >> > >>> Hi > >>> > >>> Answers inline > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > >>>> Sent: den 21 februari 2008 15:34 > >>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; > >>>> philip.eardley@bt.com > >>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >>>> menth@informatik.uni-wuerzburg.de > >>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>> > >>>> Hi Ingemar, > >>>> > >>>> This is exactly the sort of thing Phil and I were hoping > >>>> > >> to trigger > >> > >>>> people to write in response to our email. We are hoping to > >>>> > >> settle on > >> > >>>> what are the real options people support for the > encoding and why > >>>> they support them... > >>>> > >>>> Just one quick observation - if we have to leave 11 > >>>> > >> unchanged across > >> > >>>> the PCN domain this will mean that such packets can't be > >>>> > >> PCN marked > >> > >>>> and thus they should not form part of any PCN aggregate (in my > >>>> opinion)... > >>>> > >>>> > >>> Realized that this is one (big) problem, thanks for > >>> > >> pointing out this > >> > >>> issue. > >>> > >>> The next alternative is then > >>> PCN Meaning ECN DSCP > >>> ============================= > >>> PCN capable 00 PCN 1 > >>> Admission Mark 01 PCN 1 > >>> Termination Mark 10 PCN 1 > >>> > >>> PCN capable+ECN CE 00 PCN 2 > >>> AM+ECN CE 01 PCN 2 > >>> TM+ECN CE 10 PCN 2 > >>> > >>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN > >>> > >> egress PCN > >> > >>> 2 is mapped back to the ECN bits as ECN-CE "11". > >>> > >>> AfM can also be included in the schema > >>> > >>> I know this does cost an extra DSCP codepoint and it completely > >>> disregards the leakage issue, also it possible that this > >>> > >> alternative > >> > >>> or something similar is given in the PCN encoding draft > but I don't > >>> think so as this alternative does not preserve the end to end ECN > >>> semantics to 100%, rather it assumes that negotiation of > the use of > >>> ECN is done out of band at session setup. > >>> > >>> /Ingemar > >>> > >>> > >>> > >>> > >>>> Toby > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ingemar Johansson S > >>>>> > >> [mailto:ingemar.s.johansson@ericsson.com] > >> > >>>>> Sent: 21 February 2008 13:47 > >>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > >>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > >>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > >>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>> > >>>>> Hi > >>>>> > >>>>> Putting the issues with "leakage" aside (I cannot tell > >>>>> > >> how serious > >> > >>>>> this problem really is). > >>>>> > >>>>> I would prefer to sacrifice the end to end ECN semantics for the > >>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE > codepoint. The > >>>>> reason is simply that from a realtime communication > >>>>> > >>>>> > >>>> scenario with out > >>>> > >>>> > >>>>> of band signaling it is always possible to negotiate the > >>>>> > >>>>> > >>>> use of ECN CE > >>>> > >>>> > >>>>> mark in wireless nodes by means of eg. SIP signaling. > >>>>> > >> Also, atleast > >> > >>>>> for RTP/UDP I see little use for ECN nonce like it is done > >>>>> > >>>>> > >>>> with TCP as > >>>> > >>>> > >>>>> this is more or less an anti-cheat feature. > >>>>> > >>>>> > >>>>> One would then end up with a PCN encoding schema like (I beleve > >>>>> option 5 in figure 1 in the PCN encoding draft) is the closest. > >>>>> > >>>>> PCN Meaning ECN DSCP > >>>>> ============================= > >>>>> PCN capable 00 PCN 1 > >>>>> Admission Mark 01 PCN 1 > >>>>> Termination Mark 10 PCN 1 > >>>>> > >>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be > >>>>> > >>>>> > >>>> set to "00", > >>>> > >>>> > >>>>> likewise at PCN egress. ECN CE is however left untouched. > >>>>> > >>>>> > >>>> This has the > >>>> > >>>> > >>>>> effect that routers will be able to set ECN-CE on packets > >>>>> > >>>>> > >>>> before they > >>>> > >>>> > >>>>> enter the first PCN domain, after exit from the PCN > >>>>> > >> domain routers > >> > >>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). > >>>>> Wireless nodes > >>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can > >>>>> > >>>>> > >>>> however set > >>>> > >>>> > >>>>> ECN CE as this is can be managed by out of band signaling. > >>>>> > >>>>> Besides this I would prefer a solution that maintains > end to end > >>>>> semantics regardless of DSCP value. If one consider DCCP we > >>>>> > >>>>> > >>>> don't know > >>>> > >>>> > >>>>> today if it will be a best effort traffic alternatiive or > >>>>> > >> if there > >> > >>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. > >>>>> > >>>>> /Ingemar > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>>>> Sent: den 21 februari 2008 11:07 > >>>>>> To: philip.eardley@bt.com; Ingemar Johansson S > >>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>> > >>>>>> > >>>>>> Hi Phil, Hi all > >>>>>> > >>>>>> In order to make a selection of one single (or two) options, I > >>>>>> think that the PCN WG should get the possibility to > >>>>>> > >> study all the > >> > >>>>>> possible and PCN relevant encoding options. > >>>>>> > >>>>>> In my opinion the goal of the encoding draft is to > provide this > >>>>>> information to the PCN-WG. > >>>>>> Based on this information the PCN WG can discuss and > >>>>>> > >> decide which > >> > >>>>>> of the options should be used. > >>>>>> > >>>>>> The below text is copied from the current version of the > >>>>>> > >> encoding > >> > >>>>>> draft! > >>>>>> Four options are described! > >>>>>> Please note that the encoding draft should list all relevant > >>>>>> options with advantages and disadvantages. > >>>>>> > >>>>>> Phil and Ingemar, if you can add advantages, > >>>>>> > >> disadvantages to the > >> > >>>>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the > >>>>>> encoding draft, please do. > >>>>>> > >>>>>> Best regards, > >>>>>> Georgios > >>>>>> > >>>>>> > >>>>>> > >>>>>> 3.2. Encoding Using DSCP Field > >>>>>> > >>>>>> In this type of encoding and transport method the > >>>>>> > >>>>>> > >>>> congestion and > >>>> > >>>> > >>>>>> precongestion information is encoded into the 6 DSCP > >>>>>> > >>>>>> > >>>>> bits that are > >>>>> > >>>>> > >>>>>> transported in the IP header of the data packets. > >>>>>> > >>>>>> > >>>> Four possible > >>>> > >>>> > >>>>>> alternatives can be distinguished, as can be seen in > >>>>>> > >>>>>> > >>>>> Figure 3, with > >>>>> > >>>>> > >>>>>> details provided by > >>>>>> > >> draft-westberg-pcn-load-control-02.txt [4]. > >> > >>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 > >>>>>> > >>>>>> > >>>>> need three > >>>>> > >>>>> > >>>>>> additional DSCP values and Option 10 needs four > >>>>>> > >> additional DSCP > >> > >>>>>> values. Note that all additional and experimental DSCP > >>>>>> > >>>>>> > >>>>> values are > >>>>> > >>>>> > >>>>>> representing and are associated with the same PHB. > >>>>>> > >>>>>> > >>>> The 1st, 2nd, > >>>> > >>>> > >>>>>> 3rd, and 4th DSCP values are representing DSCP > values that are > >>>>>> assigned by IANA as DSCP experimental values, see RFC > >>>>>> > >> 2211 [9]. > >> > >>>>>> > >>>>>> > >>>>>> -------------------------------------------------------------- > >>>>>> --------- > >>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add > DSCP 3 Add > >>>>>> |DSCP 4 > >>>>>> || > >>>>>> ===========++==========+===========+===========+===========+== > >>>>>> =========| > >>>>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | > >>>>>> NA | > >>>>>> |-----------++----------+-----------+-----------+-----------+- > >>>>>> ----------| > >>>>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | > >>>>>> NA | > >>>>>> |-----------++----------+-----------+-----------+-----------+- > >>>>>> ----------| > >>>>>> | Option 8 || Not-PCN | PCN | AM | TM | > >>>>>> NA | > >>>>>> |-----------++----------+-----------+-----------+-----------+- > >>>>>> ----------| > >>>>>> | Option 9 || Not-PCN | PCN | AM | TM | > >>>>>> AfM | > >>>>>> > >>>>>> -------------------------------------------------------------- > >>>>>> --------- > >>>>>> > >>>>>> Notes: Not-PCN means the packet is not PCN capable. > >>>>>> > >>>>>> Figure 2: Encoding of PCN Information Using > DSCP Field > >>>>>> > >>>>>> 3.2.1. Benefits of Using DSCP Field > >>>>>> > >>>>>> The main benefit of using the DSCP field is that it is not > >>>>>> affecting > >>>>>> the end-to-end ECN semantics and therefore the issues > >>>>>> > >>>>>> > >>>>> and concerns > >>>>> > >>>>> > >>>>>> raised in RFC 4774 [22] are not applicable for this > encoding > >>>>>> scheme. > >>>>>> Another benefit is related to the fact that all 4 > >>>>>> > >> DSCP encoding > >> > >>>>>> options depicted in Figure 2 can support the PCN capable not > >>>>>> congested (PCN) indication, the admission control > >>>>>> > >> (AM) and flow > >> > >>>>>> termination (TM) encoding states. In addition Option 8 > >>>>>> > >>>>>> > >>>>> and 10 can > >>>>> > >>>>> > >>>>>> support the ECMP solution. > >>>>>> > >>>>>> 3.2.2. Drawbacks of Using DSCP Field > >>>>>> > >>>>>> This type of encoding needs to use per PHB, in > addition to the > >>>>>> original DSCP and depending on the encoding option used, > >>>>>> > >>>>>> > >>>>> one, two, > >>>>> > >>>>> > >>>>>> three, or four DSCP values, respectively. These > >>>>>> > >>>>>> > >>>> additional DSCP > >>>> > >>>> > >>>>>> values can be taken from the DSCP values that are not > >>>>>> > >>>>>> > >>>> defined by > >>>> > >>>> > >>>>>> standards action, see RFC 2211 [9]. Note that all the > >>>>>> > >>>>>> > >>>> additional > >>>> > >>>> > >>>>>> DSCP values are representing and are associated with one > >>>>>> > >>>>>> > >>>>> PHB. The > >>>>> > >>>>> > >>>>>> value of this DSCP/PHB can either follow a standards > >>>>>> > >> action or > >> > >>>>>> use a > >>>>>> value that is applied for experimental or local use. It is > >>>>>> important > >>>>>> to note that the number of the DSCP values used for local or > >>>>>> experimental use is restricted and therefore the number of > >>>>>> different > >>>>>> PHBs supported in the PCN domain will also be restricted. > >>>>>> > >>>>>> Best regards, > >>>>>> Georgios > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > >>>>>>> > >>>>>>> > >>>>>> Behalf Of > >>>>>> > >>>>>> > >>>>>>> philip.eardley@bt.com > >>>>>>> Sent: donderdag 21 februari 2008 10:24 > >>>>>>> To: ingemar.s.johansson@ericsson.com; > >>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>>>> > >>>>>>> Ingemar > >>>>>>> > >>>>>>> Re > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> consider the end to end ECN usecases > >>>>>>>> > >>>>>>>> > >>>>>>> I believe that the emails below about Toby's encoding > >>>>>>> > >>>>>>> > >>>> proposal do > >>>> > >>>> > >>>>>>> indeed already consider ECN. Would appreciate it if you > >>>>>>> > >>>>>>> > >>>> could add > >>>> > >>>> > >>>>>>> further text to it to better capture the (pros and) cons. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> more DSCP codepoints > >>>>>>>> > >>>>>>>> > >>>>>>> I think you may be proposing an encoding that uses all dscp > >>>>>>> > >>>>>>> > >>>>>> codepoints > >>>>>> > >>>>>> > >>>>>>> (as has Georgios). That's fine - but a "1 pager" > >>>>>>> setting out this option with its pros and cons (ie > >>>>>>> > >>>>>>> > >>>>> similar to what > >>>>> > >>>>> > >>>>>>> toby has done below) is needed I think! At the moment we > >>>>>>> > >>>>>>> > >>>>>> have lots of > >>>>>> > >>>>>> > >>>>>>> options on the table - in order to reach a decision, I > >>>>>>> > >>>>>>> > >>>>>> think we really > >>>>>> > >>>>>> > >>>>>>> need very few options but with their pros and cons better > >>>>>>> > >>>>>>> > >>>>> laid out. > >>>>> > >>>>> > >>>>>>> I haven't managed to get to your draft yet, sorry (next week > >>>>>>> hopefully) > >>>>>>> - > >>>>>>> Thanks > >>>>>>> Phil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Ingemar Johansson S > >>>>>>>> > >>>>>>>> > >>>>>> [mailto:ingemar.s.johansson@ericsson.com] > >>>>>> > >>>>>> > >>>>>>>> Sent: 21 February 2008 06:43 > >>>>>>>> To: Eardley,PL,Philip,CXR9 R; > >>>>>>>> > >>>>>>>> > >>>> menth@informatik.uni-wuerzburg.de; > >>>> > >>>> > >>>>>>>> Moncaster,T,Toby,CXR9 R > >>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>>>> > >>>>>>>> Hi > >>>>>>>> > >>>>>>>> In this discussion it may be well worth the effort to > >>>>>>>> > >>>>>>>> > >>>>>>> consider the end > >>>>>>> > >>>>>>> > >>>>>>>> to end ECN usecases that we foresee when considering > >>>>>>>> > >>>>>>>> > >>>>> various PCN > >>>>> > >>>>> > >>>>>>>> encoding options. > >>>>>>>> Please have a look at > >>>>>>>> > >>>>>>>> > >>>>>>>> > >> > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > >> > >>>> > >>>> > >>>>>>>> for a discussion of the use cases and a motivation to why > >>>>>>>> > >>>>>>>> > >>>>>> end to end > >>>>>> > >>>>>> > >>>>>>> ECN > >>>>>>> > >>>>>>> > >>>>>>>> should be maintained even across PCN nodes even for non > >>>>>>>> > >>>>>>>> > >>>>>> DF traffic. > >>>>>> > >>>>>> > >>>>>>>> That said I realize that there is some cost associated to > >>>>>>>> > >>>>>>>> > >>>>>>> the use of > >>>>>>> > >>>>>>> > >>>>>>>> DSCP codepoints, this cost must however be weighted against > >>>>>>>> > >>>>>>>> > >>>>>>> the risk > >>>>>>> > >>>>>>> > >>>>>>>> that other functionality like end to end ECN semantics is > >>>>>>>> > >>>>>>>> > >>>>>> probably > >>>>>> > >>>>>> > >>>>>>>> broken if a PCN encoding option "fiddles" with the ECN > >>>>>>>> > >>>>>>>> > >>>>> bits. It is > >>>>> > >>>>> > >>>>>>> easy > >>>>>>> > >>>>>>> > >>>>>>>> to see that if one wish to maintain support for end to > >>>>>>>> > >>>>>>>> > >>>>>> end ECN (not > >>>>>> > >>>>>> > >>>>>>> only > >>>>>>> > >>>>>>> > >>>>>>>> in DF class) it simply costs more DSCP codepoints. > >>>>>>>> I am not explicitly saying don't do this or that but I wish > >>>>>>>> > >>>>>>>> > >>>>>>> to avoid a > >>>>>>> > >>>>>>> > >>>>>>>> situation where one technique has to be avoided in favor of > >>>>>>>> > >>>>>>>> > >>>>>>> the other > >>>>>>> as > >>>>>>> > >>>>>>> > >>>>>>>> it may in the end prevent deployment of both. If one can > >>>>>>>> > >>>>>>>> > >>>>>>> yank the two > >>>>>>> > >>>>>>> > >>>>>>>> together so much the better even though the cost e.g in > >>>>>>>> > >>>>>>>> > >>>>> DSCP code > >>>>> > >>>>> > >>>>>>> points > >>>>>>> > >>>>>>> > >>>>>>>> is regarded as higher. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Ingemar > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > >>>>>>>>> > >>>>>>>>> > >>>>>>> On Behalf > >>>>>>> > >>>>>>> > >>>>>>>>> Of philip.eardley@bt.com > >>>>>>>>> Sent: den 20 februari 2008 17:44 > >>>>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>>>>>> > >>>>>>>>> Thanks Michael > >>>>>>>>> > >>>>>>>>> I agree with you that spending one DSCP value is quite > >>>>>>>>> > >>>>>>>>> > >>>>>> expensive > >>>>>> > >>>>>> > >>>>>>>>> (not two, as one is spent anyway). I think the only way > >>>>>>>>> > >>>>>>>>> > >>>>>> of really > >>>>>> > >>>>>> > >>>>>>>>> assessing this properly is for an alternative proposal > >>>>>>>>> > >>>>>>>>> > >>>>>> (with pros > >>>>>> > >>>>>> > >>>>>>>>> and cons) that requires only one DSCP. > >>>>>>>>> Then we can see where the consensus for the best > >>>>>>>>> > >>>>>>>>> > >>>> (/least bad) > >>>> > >>>> > >>>>>>>>> encoding lies. Personally I have no axe to grind for > >>>>>>>>> > >>>>>>>>> > >>>>> or against > >>>>> > >>>>> > >>>>>>>>> either - I'm not yet convinced that the proposal below is > >>>>>>>>> > >>>>>>>>> > >>>>>>> definitely > >>>>>>> > >>>>>>> > >>>>>>>>> the way to go, until compared it in detail with other > >>>>>>>>> > >>>>>>>>> > >>>>> proposals. > >>>>> > >>>>> > >>>>>>>>> So I think it would be really useful to have a "1 > >>>>>>>>> > >>>>>>>>> > >>>> pager" for > >>>> > >>>> > >>>>>>>>> alternative > >>>>>>>>> proposal(s) before the ietf, as I think this would make > >>>>>>>>> > >>>>>>>>> > >>>>>>> Philadelphia > >>>>>>> > >>>>>>> > >>>>>>>>> discussions more productive. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> You're correct about one of the motivations > >>>>>>>>> > >>>>>>>>> > >>>>>> (advantages) for this > >>>>>> > >>>>>> > >>>>>>>>> proposal (although I don't think the issues are exactly > >>>>>>>>> > >>>>>>>>> > >>>>>>> the same for > >>>>>>> > >>>>>>> > >>>>>>>>> 11 leakage as 01/10 leakage). > >>>>>>>>> > >>>>>>>>> Consider the case where 11 leaks out of the PCN > >>>>>>>>> > >>>>>>>>> > >>>>> domain. If the > >>>>> > >>>>> > >>>>>>>>> endpoints are ECN capable, then the ECN source slows > >>>>>>>>> > >>>>>>>>> > >>>>>> down (seems > >>>>>> > >>>>>> > >>>>>>>>> reasonable). If they're not capable, then the impact > >>>>>>>>> > >>>>>>>>> > >>>>>> outside the > >>>>>> > >>>>>> > >>>>>>>>> domain isn't any different to what would happen without > >>>>>>>>> > >>>>>>>>> > >>>>>>> PCN-domain. > >>>>>>> > >>>>>>> > >>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. > >>>>>>>>> Then this will lead to either flow admission or > >>>>>>>>> > >>>>>>>>> > >>>>>>> termination in the > >>>>>>> > >>>>>>> > >>>>>>>>> PCN-domain. These are both safe, in that the reaction is > >>>>>>>>> > >>>>>>>>> > >>>>>>> (I believe) > >>>>>>> > >>>>>>> > >>>>>>>>> at least as severe as would happen in an all ECN world. > >>>>>>>>> You mention that this might not terminate the ECN-11 flow > >>>>>>>>> specifically (some other flow might get terminated instead). > >>>>>>>>> I think this is true, though it also implies that [1] > >>>>>>>>> > >>>>>>>>> > >>>>>>> end-to-end ECN > >>>>>>> > >>>>>>> > >>>>>>>>> & PCN on the same flow really is useful, [2] the > >>>>>>>>> > >>>>>>>>> > >>>> mechanism (eg > >>>> > >>>> > >>>>>>>>> tunnelling) to carry ECN-marking transparently across the > >>>>>>>>> > >>>>>>>>> > >>>>>>> PCN-domain > >>>>>>> > >>>>>>> > >>>>>>>>> has also failed, [3] the flows which are terminated > >>>>>>>>> > >>>>>>>>> > >>>>> aren't other > >>>>> > >>>>> > >>>>>>>>> ECN-11 flows that are also getting in due to the same > >>>>>>>>> misconfiguration. > >>>>>>>>> > >>>>>>>>> Best wishes > >>>>>>>>> Phil > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Michael Menth > >>>>>>>>>> > >>>>>>>>>> > >>>>> [mailto:menth@informatik.uni-wuerzburg.de] > >>>>> > >>>>> > >>>>>>>>>> Sent: 20 February 2008 10:50 > >>>>>>>>>> To: Moncaster,T,Toby,CXR9 R > >>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > >>>>>>>>>> > >>>>>>>>>> > >>>>>> khchan@nortel.com; > >>>>>> > >>>>>> > >>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; > >>>>>>>>>> > >>>>>>>>>> > >>>>>> steven.blake@ericsson.com; > >>>>>> > >>>>>> > >>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > >>>>>>>>>> Subject: Re: FW: RE: PCN encoding option > >>>>>>>>>> > >>>>>>>>>> Hi Toby, > >>>>>>>>>> > >>>>>>>>>> as I understand the proposal, the motivation is to > >>>>>>>>>> > >>>>>>>>>> > >>>>>> avoid 01/10 > >>>>>> > >>>>>> > >>>>>>>>>> codepoints as it is not good if they leak out of the > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> network since > >>>>>>> > >>>>>>> > >>>>>>>>> 01/10 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> However, there is > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> the same problem with 11 marking, i.e. 11-packets > >>>>>>>>>> > >>>>>>>>>> > >>>> may not be > >>>> > >>>> > >>>>>>> dropped > >>>>>>> > >>>>>>> > >>>>>>>>> by > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> ECN nodes outside the PCN domain although endpoints > >>>>>>>>>> > >>>>>>>>>> > >>>>>> are not ECN > >>>>>> > >>>>>> > >>>>>>>>> capable. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Even if 11-packets trigger flow termination, it is not > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> guaranteed that > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> exactly the marked flow going over an overloaded > >>>>>>>>>> > >>>>>>>>>> > >>>> ECN node is > >>>> > >>>> > >>>>>>>>> terminated. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Just want to say that this solution wants to solve a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> problem that > >>>>>>> > >>>>>>> > >>>>>>>>> exists > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> only in case of misconfiguration (leaking packets), but > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> does not fully > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> achieve that objective. Therefore, I feel that > >>>>>>>>>> > >>>>>>>>>> > >>>>>> spending two DSCP > >>>>>> > >>>>>> > >>>>>>>>> values > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> is quite expensive. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Michael > >>>>>>>>>> > >>>>>>>>>> toby.moncaster@bt.com wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> All, > >>>>>>>>>>> > >>>>>>>>>>> Phil and I have just been discussing the encoding draft > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> and feel we > >>>>>>>>> may > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> have lit upon a neat solution that seems to have > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> lots of pros > >>>>>> > >>>>>> > >>>>>>> and > >>>>>>> > >>>>>>> > >>>>>>>>> few > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> cons... In order to get a better feeling for this > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> proposal I will go > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> through the simplified version without Affected > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> marking first: > >>>>>> > >>>>>> > >>>>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>>>> > >>>>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>>>> Termination Mark 11/00 PCN 2 > >>>>>>>>>>> > >>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> the same PCN > >>>>> > >>>>> > >>>>>>>>> behaviour > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> aggregate. > >>>>>>>>>>> > >>>>>>>>>>> Pros: > >>>>>>>>>>> o Termination marking and admission marking are > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> independent, > >>>>>> > >>>>>> > >>>>>>> eg > >>>>>>> > >>>>>>> > >>>>>>>>>>> termination marking can be done after a packet has been > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> admission > >>>>>>> > >>>>>>> > >>>>>>>>>>> marked. Therefore a router can write AM or TM without > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> having to read > >>>>>>>>> the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> packet's PCN marking first, which is easier to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> implement. (Note: > >>>>>>> > >>>>>>> > >>>>>>>>>>> Over-writing a TM with AM is not allowed for > >>>>>>>>>>> > >>>>>>>>>>> > >>>> 3SM & CL, see > >>>> > >>>> > >>>>>>>>>>> draft-charny-pcn-comparison.) > >>>>>>>>>>> > >>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> ECT(1). This is > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> safest option if packets leak outside the PCN > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> region, due to > >>>>> > >>>>> > >>>>>>> some > >>>>>>> > >>>>>>> > >>>>>>>>> fort > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> for a single > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> domain deployment of PCN). > >>>>>>>>>>> > >>>>>>>>>>> o It leaves open the possibility of using ECT(0) and > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> ECT(1) in some > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> mysterious way in a future end-to-end PCN deployment > >>>>>>>>>>> > >>>>>>>>>>> o For a router to classify a packet as PCN, it > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> simply reads its > >>>>>>> > >>>>>>> > >>>>>>>>> DSCP. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> This is probably easier than checking both its > >>>>>>>>>>> > >>>>>>>>>>> > >>>> DSCP & ECN > >>>> > >>>> > >>>>>>> fields. > >>>>>>> > >>>>>>> > >>>>>>>>>>> o Incremental deployment steps are possible [1] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> could deploy SM > >>>>>>> > >>>>>>> > >>>>>>>>>>> initially and later AM/TM. Just add the second > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> DSCP. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> If a router isn't upgraded at the same time nothing > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> too horrific > >>>>>>> > >>>>>>> > >>>>>>>>>>> happens. > >>>>>>>>>>> [2] could just deploy admission control & add > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> termination later, > >>>>>>> > >>>>>>> > >>>>>>>>> just by > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> adding a new DSCP; there is no need to change the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> encoding and check > >>>>>>>>> for > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> backwards compatibility? Vice-versa is also ok? > >>>>>>>>>>> > >>>>>>>>>>> Cons: > >>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> (Although > >>>>>>> > >>>>>>> > >>>>>>>>>>> possibly it's OK to use the same DSCP for TM for > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> all PCN BAs?) > >>>>>> > >>>>>> > >>>>>>>>>>> o If a packet (in a PCN flow) arrives at the > >>>>>>>>>>> > >>>>>>>>>>> > >>>> egress with > >>>> > >>>> > >>>>>>>>> its ECN = > >>>>>>>>> 11 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> and it really is required to preserve this info > >>>>>>>>>>> > >>>>>>>>>>> > >>>> across the > >>>> > >>>> > >>>>>>>>> PCN-domain, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> (tunnelling) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> o If the PCN-domain is operating multipath routing > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> (ECMP) that uses > >>>>>>>>> the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> DSCP to select routes, then there may be mis-ordering > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> of packets > >>>>>>> > >>>>>>> > >>>>>>>>> within > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> they know of > >>>>>> > >>>>>> > >>>>>>> an > >>>>>>> > >>>>>>> > >>>>>>>>> ECMP > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> mis-ordering > >>>>>>>>> when > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> there is termination marking may be acceptable > >>>>>>>>>>> > >>>>>>>>>>> If Affected marking is needed then the scheme can be > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> modified as > >>>>>>> > >>>>>>> > >>>>>>>>>>> follows: > >>>>>>>>>>> > >>>>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>>>> > >>>>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>>>> Termination Mark 11 PCN 2 > >>>>>>>>>>> Affected Mark 00 PCN 2 > >>>>>>>>>>> > >>>>>>>>>>> The pros for this scheme are broadly similar to > >>>>>>>>>>> > >>>>>>>>>>> > >>>> the above. > >>>> > >>>> > >>>>>>> However > >>>>>>> > >>>>>>> > >>>>>>>>> there > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> is a new con which may or may not matter: If a packet is > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> affected > >>>>>>> > >>>>>>> > >>>>>>>>> marked > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> and a later node is doing admission marking then it will > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> reset the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> affected mark to a termination mark. Work would > >>>>>>>>>>> > >>>>>>>>>>> > >>>> be needed > >>>> > >>>> > >>>>>>>>> to see if > >>>>>>>>> this > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> skews the results and causes significant > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> over-termination or > >>>>> > >>>>> > >>>>>>> not. > >>>>>>> > >>>>>>> > >>>>>>>>>>> Please could people look through this scheme and > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> highlight any > >>>>>>> > >>>>>>> > >>>>>>>>>>> additional concerns that they may have (and extra > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> benefits too). > >>>>>>> I > >>>>>>> > >>>>>>> > >>>>>>>>> would > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> like to get as many opinions as possible. > >>>>>>>>>>> > >>>>>>>>>>> What I want to avoid is people just emailing back with > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> "why not try > >>>>>>>>> this > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> scheme instead". Currently we seem to have a plethora of > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> possible > >>>>>>> > >>>>>>> > >>>>>>>>>>> schemes on the table and people need to start putting > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> down much > >>>>>>> > >>>>>>> > >>>>>>>>> clearer > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> pros and cons for the schemes they support... > >>>>>>>>>>> > >>>>>>>>>>> > >>>> So it could > >>>> > >>>> > >>>>>>>>> be good to > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> have a similar "one page" email about a specific > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> scheme that > >>>>> > >>>>> > >>>>>>> only > >>>>>>> > >>>>>>> > >>>>>>>>> uses > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. > >>>>>>>>>>> > >>>>>>>>>>> Toby > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >> > ____________________________________________________________________ > >> > >>>>> > >>>>> > >>>>>>>>>>> Toby Moncaster, > >>>>>>>>>>> > >>>>>>>>>>> > >>>> Networks Research > >>>> > >>>> > >>>>>>>>> Centre, BT > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> 1473 648734 > >>>>> > >>>>> > >>>>>>>>>> -- > >>>>>>>>>> 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 > >>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> PCN mailing list > >>>>>>> PCN@ietf.org > >>>>>>> http://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 > >> > >> > >> > > -- > 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:18:47 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF1028C33E; Fri, 22 Feb 2008 07:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.433 X-Spam-Level: *** X-Spam-Status: No, score=3.433 tagged_above=-999 required=5 tests=[AWL=-2.630, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 ysPdyP8rsayG; Fri, 22 Feb 2008 07:18:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A883A6817; Fri, 22 Feb 2008 07:18:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10EF28C2A4 for ; Fri, 22 Feb 2008 07:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 765z1lSH67Gb for ; Fri, 22 Feb 2008 07:18:39 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id D8FEB3A67D7 for ; Fri, 22 Feb 2008 07:18:38 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 605EBA0664; Fri, 22 Feb 2008 16:18:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 51F4BA064D; Fri, 22 Feb 2008 16:18:34 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id AA6F0A067A; Fri, 22 Feb 2008 16:18:28 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1MFISV16011; Fri, 22 Feb 2008 16:18:28 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 5D168C8785; Fri, 22 Feb 2008 16:18:28 +0100 (CET) Message-ID: <47BEE784.6070902@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 16:17:24 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ingemar Johansson S References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> <47BEAE2D.1090305@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D8@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1D8@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, see inline. Ingemar Johansson S wrote: > Hi Michael. > > Answer inline below. > > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: den 22 februari 2008 12:13 >> To: Ingemar Johansson S >> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >> Subject: Re: [PCN] FW: RE: PCN encoding option >> >> Hi Ingemar, >> >> Ingemar Johansson S wrote: >> >>> Hi >>> >>> See inline >>> >>> /Ingemar >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: den 22 februari 2008 10:13 >>>> To: Ingemar Johansson S >>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>> >>>> Hi Ingemar, >>>> >>>> this solution essentially spends a DSCP to save 11-marking through >>>> the PCN domain and allow them to be PCN-marked. This is a >>>> >> rather high >> >>>> price, in particular because the PCN packets need to be >>>> >> remarked to >> >>>> 00. This has the consequence that ECN capability is lost >>>> >> for the rest >> >>>> of the path. >>>> >>>> >>> Not sure that I agree, yes the ECT(0), ECT(1) codepoints >>> >> are lost and >> >>> there goes also the ECN nonce and the "inband" ECN >>> >> capability signaling. >> >>> A router outside the PCN domain wont be able to set ECN-CE. >>> >> However if >> >>> the ECN capability is negotiated out of band for the wireless >>> endpoints and the up and downlink wireless nodes, these >>> >> will be ECN-CE >> >>> capable but without the nonce capability. >>> >>> >> The difficulty is that the information for each packet >> whether 10 or 01 must be kept, that says RFC4774: >> >> Similarly, if a packet that *could* be using default >> semantics is marked with the ECN codepoint "01", then this >> codepoint >> should not be changed to "10" in the network (and a "10" codepoint >> should not be changed to "01"). This requirement is necessary to >> avoid interference with the transport protocol's use of >> the ECN nonce >> [RFC3540]. >> >> This would require a per packet signalling ... >> > > Not 100% convinced here, ECN codepoints "01" and "10" can be reset to > "00", that is my interpretation of 4.3 in RFC4774. > What might be seen as odd is perhaps that after PCN egress the ECN > pattern using this trick will only use the code points "00" or "11" > instead of the normal "01", "10" and "11" (if ECN capable). > Routers located after PCN egress won't be able to set ECN "11" as the > flow is not anymore regarded as ECN capable (on IP level). Wireless > nodes such as LTE-eNB can however be instructed to set ECN "11" during > congestion as this then controlled using out of band signaling, this out > of band signaling is in turn controlled by policy rules that will limit > the risk for cheating. > Note that this is meant for realtime traffic and a means to do efficient > adaptation in a wireless enviroment where the transmission capacity for > a single user changes changes dynamically due to physical factors such > as shadowing et.c. > Ok, I see. I think this is a solution not standardized by the IETF and can be done for any encoding scheme. If not, what's its requirement on the encoding? Regards, Michael > > >>> >>> >>> >>>> Therefore, I opt for one of the two versions >>>> 1) discard 11-marked PCN packets before entering the PCN domain OR >>>> 2) let them go through the PCN domain, take them into account for >>>> metering, but do not remark them. >>>> The first option loses ECN capability for PCN traffic, the second >>>> option keeps it on the subpath before entering the PCN domain. >>>> >>>> >>> Not sure I follow here. What would option 2 look like? >>> My interpretation: Packets with DSCP=EF enters the PCN domain, at >>> ingress they are remarked as DSCP=PCN unless ECN="11", in >>> >> which case >> >>> DSCP=EF. What about ECN="01" or "01" will these also be kept as >>> DSCP=EF or will the ECN bits be set to "00". >>> Please explain. >>> >>> >> EF DSCP is remarked to PCN in any case. >> 1) 11-marked PCN packets are dropped by the PCN ingress >> 2) 11 is kept as is >> and 01/10 marking is reset to 00 (no-precongestion). The PCN >> egress node resets 10/01 marked packets to 00. Therefore, the >> ECN capability for PCN traffic is lost >> 1) completely >> 2) for the partial downstream path starting with the PCN ingress node. >> >> It's true that PCN marking can get problems if the majority >> of PCN packets was CE-marked when entering the PCN domain. >> This kind of traffic also cheats ECN when it doesn't back >> off. I just want to say: even TCP senders and receivers can >> cheat, do we care? The question is what's more >> important: remaining ECN functionality for the partial path >> up to the PCN ingress node or safety against too many >> 11-marked packets. I see these options (1 and 2) and have no >> particular preference. >> >> Regards, >> >> Michael >> >> >>> >>> >>>> Regards, >>>> >>>> Michael >>>> >>>> Ingemar Johansson S wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> Answers inline >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >>>>>> Sent: den 21 februari 2008 15:34 >>>>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; >>>>>> philip.eardley@bt.com >>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>> menth@informatik.uni-wuerzburg.de >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Hi Ingemar, >>>>>> >>>>>> This is exactly the sort of thing Phil and I were hoping >>>>>> >>>>>> >>>> to trigger >>>> >>>> >>>>>> people to write in response to our email. We are hoping to >>>>>> >>>>>> >>>> settle on >>>> >>>> >>>>>> what are the real options people support for the >>>>>> >> encoding and why >> >>>>>> they support them... >>>>>> >>>>>> Just one quick observation - if we have to leave 11 >>>>>> >>>>>> >>>> unchanged across >>>> >>>> >>>>>> the PCN domain this will mean that such packets can't be >>>>>> >>>>>> >>>> PCN marked >>>> >>>> >>>>>> and thus they should not form part of any PCN aggregate (in my >>>>>> opinion)... >>>>>> >>>>>> >>>>>> >>>>> Realized that this is one (big) problem, thanks for >>>>> >>>>> >>>> pointing out this >>>> >>>> >>>>> issue. >>>>> >>>>> The next alternative is then >>>>> PCN Meaning ECN DSCP >>>>> ============================= >>>>> PCN capable 00 PCN 1 >>>>> Admission Mark 01 PCN 1 >>>>> Termination Mark 10 PCN 1 >>>>> >>>>> PCN capable+ECN CE 00 PCN 2 >>>>> AM+ECN CE 01 PCN 2 >>>>> TM+ECN CE 10 PCN 2 >>>>> >>>>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN >>>>> >>>>> >>>> egress PCN >>>> >>>> >>>>> 2 is mapped back to the ECN bits as ECN-CE "11". >>>>> >>>>> AfM can also be included in the schema >>>>> >>>>> I know this does cost an extra DSCP codepoint and it completely >>>>> disregards the leakage issue, also it possible that this >>>>> >>>>> >>>> alternative >>>> >>>> >>>>> or something similar is given in the PCN encoding draft >>>>> >> but I don't >> >>>>> think so as this alternative does not preserve the end to end ECN >>>>> semantics to 100%, rather it assumes that negotiation of >>>>> >> the use of >> >>>>> ECN is done out of band at session setup. >>>>> >>>>> /Ingemar >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Toby >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ingemar Johansson S >>>>>>> >>>>>>> >>>> [mailto:ingemar.s.johansson@ericsson.com] >>>> >>>> >>>>>>> Sent: 21 February 2008 13:47 >>>>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>>>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Putting the issues with "leakage" aside (I cannot tell >>>>>>> >>>>>>> >>>> how serious >>>> >>>> >>>>>>> this problem really is). >>>>>>> >>>>>>> I would prefer to sacrifice the end to end ECN semantics for the >>>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE >>>>>>> >> codepoint. The >> >>>>>>> reason is simply that from a realtime communication >>>>>>> >>>>>>> >>>>>>> >>>>>> scenario with out >>>>>> >>>>>> >>>>>> >>>>>>> of band signaling it is always possible to negotiate the >>>>>>> >>>>>>> >>>>>>> >>>>>> use of ECN CE >>>>>> >>>>>> >>>>>> >>>>>>> mark in wireless nodes by means of eg. SIP signaling. >>>>>>> >>>>>>> >>>> Also, atleast >>>> >>>> >>>>>>> for RTP/UDP I see little use for ECN nonce like it is done >>>>>>> >>>>>>> >>>>>>> >>>>>> with TCP as >>>>>> >>>>>> >>>>>> >>>>>>> this is more or less an anti-cheat feature. >>>>>>> >>>>>>> >>>>>>> One would then end up with a PCN encoding schema like (I beleve >>>>>>> option 5 in figure 1 in the PCN encoding draft) is the closest. >>>>>>> >>>>>>> PCN Meaning ECN DSCP >>>>>>> ============================= >>>>>>> PCN capable 00 PCN 1 >>>>>>> Admission Mark 01 PCN 1 >>>>>>> Termination Mark 10 PCN 1 >>>>>>> >>>>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>>>>>> >>>>>>> >>>>>>> >>>>>> set to "00", >>>>>> >>>>>> >>>>>> >>>>>>> likewise at PCN egress. ECN CE is however left untouched. >>>>>>> >>>>>>> >>>>>>> >>>>>> This has the >>>>>> >>>>>> >>>>>> >>>>>>> effect that routers will be able to set ECN-CE on packets >>>>>>> >>>>>>> >>>>>>> >>>>>> before they >>>>>> >>>>>> >>>>>> >>>>>>> enter the first PCN domain, after exit from the PCN >>>>>>> >>>>>>> >>>> domain routers >>>> >>>> >>>>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>>>>>> Wireless nodes >>>>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>>>>>> >>>>>>> >>>>>>> >>>>>> however set >>>>>> >>>>>> >>>>>> >>>>>>> ECN CE as this is can be managed by out of band signaling. >>>>>>> >>>>>>> Besides this I would prefer a solution that maintains >>>>>>> >> end to end >> >>>>>>> semantics regardless of DSCP value. If one consider DCCP we >>>>>>> >>>>>>> >>>>>>> >>>>>> don't know >>>>>> >>>>>> >>>>>> >>>>>>> today if it will be a best effort traffic alternatiive or >>>>>>> >>>>>>> >>>> if there >>>> >>>> >>>>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. >>>>>>> >>>>>>> /Ingemar >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>>> Sent: den 21 februari 2008 11:07 >>>>>>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>> >>>>>>>> >>>>>>>> Hi Phil, Hi all >>>>>>>> >>>>>>>> In order to make a selection of one single (or two) options, I >>>>>>>> think that the PCN WG should get the possibility to >>>>>>>> >>>>>>>> >>>> study all the >>>> >>>> >>>>>>>> possible and PCN relevant encoding options. >>>>>>>> >>>>>>>> In my opinion the goal of the encoding draft is to >>>>>>>> >> provide this >> >>>>>>>> information to the PCN-WG. >>>>>>>> Based on this information the PCN WG can discuss and >>>>>>>> >>>>>>>> >>>> decide which >>>> >>>> >>>>>>>> of the options should be used. >>>>>>>> >>>>>>>> The below text is copied from the current version of the >>>>>>>> >>>>>>>> >>>> encoding >>>> >>>> >>>>>>>> draft! >>>>>>>> Four options are described! >>>>>>>> Please note that the encoding draft should list all relevant >>>>>>>> options with advantages and disadvantages. >>>>>>>> >>>>>>>> Phil and Ingemar, if you can add advantages, >>>>>>>> >>>>>>>> >>>> disadvantages to the >>>> >>>> >>>>>>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the >>>>>>>> encoding draft, please do. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3.2. Encoding Using DSCP Field >>>>>>>> >>>>>>>> In this type of encoding and transport method the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> congestion and >>>>>> >>>>>> >>>>>> >>>>>>>> precongestion information is encoded into the 6 DSCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> bits that are >>>>>>> >>>>>>> >>>>>>> >>>>>>>> transported in the IP header of the data packets. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Four possible >>>>>> >>>>>> >>>>>> >>>>>>>> alternatives can be distinguished, as can be seen in >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Figure 3, with >>>>>>> >>>>>>> >>>>>>> >>>>>>>> details provided by >>>>>>>> >>>>>>>> >>>> draft-westberg-pcn-load-control-02.txt [4]. >>>> >>>> >>>>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> need three >>>>>>> >>>>>>> >>>>>>> >>>>>>>> additional DSCP values and Option 10 needs four >>>>>>>> >>>>>>>> >>>> additional DSCP >>>> >>>> >>>>>>>> values. Note that all additional and experimental DSCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> values are >>>>>>> >>>>>>> >>>>>>> >>>>>>>> representing and are associated with the same PHB. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> The 1st, 2nd, >>>>>> >>>>>> >>>>>> >>>>>>>> 3rd, and 4th DSCP values are representing DSCP >>>>>>>> >> values that are >> >>>>>>>> assigned by IANA as DSCP experimental values, see RFC >>>>>>>> >>>>>>>> >>>> 2211 [9]. >>>> >>>> >>>>>>>> >>>>>>>> -------------------------------------------------------------- >>>>>>>> --------- >>>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add >>>>>>>> >> DSCP 3 Add >> >>>>>>>> |DSCP 4 >>>>>>>> || >>>>>>>> ===========++==========+===========+===========+===========+== >>>>>>>> =========| >>>>>>>> | Option 6 || Not-PCN | PCN | AM/TM | NA | >>>>>>>> NA | >>>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>>> ----------| >>>>>>>> | Option 7 || Not-PCN | PCN | AM/TM | AfM | >>>>>>>> NA | >>>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>>> ----------| >>>>>>>> | Option 8 || Not-PCN | PCN | AM | TM | >>>>>>>> NA | >>>>>>>> |-----------++----------+-----------+-----------+-----------+- >>>>>>>> ----------| >>>>>>>> | Option 9 || Not-PCN | PCN | AM | TM | >>>>>>>> AfM | >>>>>>>> >>>>>>>> -------------------------------------------------------------- >>>>>>>> --------- >>>>>>>> >>>>>>>> Notes: Not-PCN means the packet is not PCN capable. >>>>>>>> >>>>>>>> Figure 2: Encoding of PCN Information Using >>>>>>>> >> DSCP Field >> >>>>>>>> 3.2.1. Benefits of Using DSCP Field >>>>>>>> >>>>>>>> The main benefit of using the DSCP field is that it is not >>>>>>>> affecting >>>>>>>> the end-to-end ECN semantics and therefore the issues >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> and concerns >>>>>>> >>>>>>> >>>>>>> >>>>>>>> raised in RFC 4774 [22] are not applicable for this >>>>>>>> >> encoding >> >>>>>>>> scheme. >>>>>>>> Another benefit is related to the fact that all 4 >>>>>>>> >>>>>>>> >>>> DSCP encoding >>>> >>>> >>>>>>>> options depicted in Figure 2 can support the PCN capable not >>>>>>>> congested (PCN) indication, the admission control >>>>>>>> >>>>>>>> >>>> (AM) and flow >>>> >>>> >>>>>>>> termination (TM) encoding states. In addition Option 8 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> and 10 can >>>>>>> >>>>>>> >>>>>>> >>>>>>>> support the ECMP solution. >>>>>>>> >>>>>>>> 3.2.2. Drawbacks of Using DSCP Field >>>>>>>> >>>>>>>> This type of encoding needs to use per PHB, in >>>>>>>> >> addition to the >> >>>>>>>> original DSCP and depending on the encoding option used, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> one, two, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> three, or four DSCP values, respectively. These >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> additional DSCP >>>>>> >>>>>> >>>>>> >>>>>>>> values can be taken from the DSCP values that are not >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> defined by >>>>>> >>>>>> >>>>>> >>>>>>>> standards action, see RFC 2211 [9]. Note that all the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> additional >>>>>> >>>>>> >>>>>> >>>>>>>> DSCP values are representing and are associated with one >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> PHB. The >>>>>>> >>>>>>> >>>>>>> >>>>>>>> value of this DSCP/PHB can either follow a standards >>>>>>>> >>>>>>>> >>>> action or >>>> >>>> >>>>>>>> use a >>>>>>>> value that is applied for experimental or local use. It is >>>>>>>> important >>>>>>>> to note that the number of the DSCP values used for local or >>>>>>>> experimental use is restricted and therefore the number of >>>>>>>> different >>>>>>>> PHBs supported in the PCN domain will also be restricted. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> philip.eardley@bt.com >>>>>>>>> Sent: donderdag 21 februari 2008 10:24 >>>>>>>>> To: ingemar.s.johansson@ericsson.com; >>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>> >>>>>>>>> Ingemar >>>>>>>>> >>>>>>>>> Re >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> consider the end to end ECN usecases >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I believe that the emails below about Toby's encoding >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> proposal do >>>>>> >>>>>> >>>>>> >>>>>>>>> indeed already consider ECN. Would appreciate it if you >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> could add >>>>>> >>>>>> >>>>>> >>>>>>>>> further text to it to better capture the (pros and) cons. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> more DSCP codepoints >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I think you may be proposing an encoding that uses all dscp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> codepoints >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> (as has Georgios). That's fine - but a "1 pager" >>>>>>>>> setting out this option with its pros and cons (ie >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> similar to what >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> toby has done below) is needed I think! At the moment we >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> have lots of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> options on the table - in order to reach a decision, I >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> think we really >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> need very few options but with their pros and cons better >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> laid out. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> I haven't managed to get to your draft yet, sorry (next week >>>>>>>>> hopefully) >>>>>>>>> - >>>>>>>>> Thanks >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Ingemar Johansson S >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> Sent: 21 February 2008 06:43 >>>>>>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> menth@informatik.uni-wuerzburg.de; >>>>>> >>>>>> >>>>>> >>>>>>>>>> Moncaster,T,Toby,CXR9 R >>>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> In this discussion it may be well worth the effort to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> consider the end >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> to end ECN usecases that we foresee when considering >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> various PCN >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> encoding options. >>>>>>>>>> Please have a look at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>> for a discussion of the use cases and a motivation to why >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> end to end >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ECN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> should be maintained even across PCN nodes even for non >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> DF traffic. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> That said I realize that there is some cost associated to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> the use of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> DSCP codepoints, this cost must however be weighted against >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> the risk >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> that other functionality like end to end ECN semantics is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> probably >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> bits. It is >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> easy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> to see that if one wish to maintain support for end to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> end ECN (not >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> only >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>>>>>> I am not explicitly saying don't do this or that but I wish >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> to avoid a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> situation where one technique has to be avoided in favor of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> the other >>>>>>>>> as >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> it may in the end prevent deployment of both. If one can >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> yank the two >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> together so much the better even though the cost e.g in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> DSCP code >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> points >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> is regarded as higher. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Ingemar >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> On Behalf >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Of philip.eardley@bt.com >>>>>>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>>>>>> To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>>> >>>>>>>>>>> Thanks Michael >>>>>>>>>>> >>>>>>>>>>> I agree with you that spending one DSCP value is quite >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> expensive >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> of really >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> assessing this properly is for an alternative proposal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> (with pros >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> and cons) that requires only one DSCP. >>>>>>>>>>> Then we can see where the consensus for the best >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> (/least bad) >>>>>> >>>>>> >>>>>> >>>>>>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> or against >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> definitely >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> the way to go, until compared it in detail with other >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> proposals. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> So I think it would be really useful to have a "1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> pager" for >>>>>> >>>>>> >>>>>> >>>>>>>>>>> alternative >>>>>>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> Philadelphia >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> discussions more productive. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You're correct about one of the motivations >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> (advantages) for this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> proposal (although I don't think the issues are exactly >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> the same for >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 11 leakage as 01/10 leakage). >>>>>>>>>>> >>>>>>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> domain. If the >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> down (seems >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> reasonable). If they're not capable, then the impact >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> outside the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> domain isn't any different to what would happen without >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> PCN-domain. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>>>>>> Then this will lead to either flow admission or >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> termination in the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> (I believe) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> at least as severe as would happen in an all ECN world. >>>>>>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>>>>>> specifically (some other flow might get terminated instead). >>>>>>>>>>> I think this is true, though it also implies that [1] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> end-to-end ECN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> mechanism (eg >>>>>> >>>>>> >>>>>> >>>>>>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> PCN-domain >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> has also failed, [3] the flows which are terminated >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> aren't other >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>>>>>> misconfiguration. >>>>>>>>>>> >>>>>>>>>>> Best wishes >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Michael Menth >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> [mailto:menth@informatik.uni-wuerzburg.de] >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> khchan@nortel.com; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> steven.blake@ericsson.com; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>>>>>> >>>>>>>>>>>> Hi Toby, >>>>>>>>>>>> >>>>>>>>>>>> as I understand the proposal, the motivation is to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> avoid 01/10 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> network since >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 01/10 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> However, there is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> may not be >>>>>> >>>>>> >>>>>> >>>>>>>>> dropped >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> by >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> are not ECN >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> capable. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> guaranteed that >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> exactly the marked flow going over an overloaded >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> ECN node is >>>>>> >>>>>> >>>>>> >>>>>>>>>>> terminated. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Just want to say that this solution wants to solve a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> problem that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> exists >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> does not fully >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> spending two DSCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> values >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> is quite expensive. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Michael >>>>>>>>>>>> >>>>>>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> All, >>>>>>>>>>>>> >>>>>>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> and feel we >>>>>>>>>>> may >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> lots of pros >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> few >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> proposal I will go >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> through the simplified version without Affected >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> marking first: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>> >>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>>>>>> >>>>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> the same PCN >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> behaviour >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> aggregate. >>>>>>>>>>>>> >>>>>>>>>>>>> Pros: >>>>>>>>>>>>> o Termination marking and admission marking are >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> independent, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> eg >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> termination marking can be done after a packet has been >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> admission >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> having to read >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> implement. (Note: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> 3SM & CL, see >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>>>>>> >>>>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> ECT(1). This is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> region, due to >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> some >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> fort >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> for a single >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> domain deployment of PCN). >>>>>>>>>>>>> >>>>>>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> ECT(1) in some >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>>>>>> >>>>>>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> simply reads its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> DSCP. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> This is probably easier than checking both its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> DSCP & ECN >>>>>> >>>>>> >>>>>> >>>>>>>>> fields. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> could deploy SM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> DSCP. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> too horrific >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> happens. >>>>>>>>>>>>> [2] could just deploy admission control & add >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> termination later, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> just by >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> encoding and check >>>>>>>>>>> for >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>>>>>> >>>>>>>>>>>>> Cons: >>>>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> (Although >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> all PCN BAs?) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> egress with >>>>>> >>>>>> >>>>>> >>>>>>>>>>> its ECN = >>>>>>>>>>> 11 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> and it really is required to preserve this info >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> across the >>>>>> >>>>>> >>>>>> >>>>>>>>>>> PCN-domain, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> (tunnelling) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> (ECMP) that uses >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> of packets >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> within >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> they know of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> an >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> ECMP >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> mis-ordering >>>>>>>>>>> when >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> there is termination marking may be acceptable >>>>>>>>>>>>> >>>>>>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> modified as >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> follows: >>>>>>>>>>>>> >>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>> >>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>>>>>> >>>>>>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> the above. >>>>>> >>>>>> >>>>>> >>>>>>>>> However >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> there >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> affected >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> marked >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> reset the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> be needed >>>>>> >>>>>> >>>>>> >>>>>>>>>>> to see if >>>>>>>>>>> this >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> skews the results and causes significant >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> over-termination or >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> not. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Please could people look through this scheme and >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> highlight any >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> additional concerns that they may have (and extra >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> benefits too). >>>>>>>>> I >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> would >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> like to get as many opinions as possible. >>>>>>>>>>>>> >>>>>>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> "why not try >>>>>>>>>>> this >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> possible >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> schemes on the table and people need to start putting >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> down much >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> clearer >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> pros and cons for the schemes they support... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> So it could >>>>>> >>>>>> >>>>>> >>>>>>>>>>> be good to >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> have a similar "one page" email about a specific >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> scheme that >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> only >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> uses >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>>>>>> >>>>>>>>>>>>> Toby >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> ____________________________________________________________________ >> >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> Toby Moncaster, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> Networks Research >>>>>> >>>>>> >>>>>> >>>>>>>>>>> Centre, BT >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> 1473 648734 >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> PCN mailing list >>>>>>>>> PCN@ietf.org >>>>>>>>> http://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 >>>> >>>> >>>> >>>> >> -- >> 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 >> >> >> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:25:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8969728C1C8; Fri, 22 Feb 2008 07:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 KH-F6zTDVzAd; Fri, 22 Feb 2008 07:25:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF8E3A6CB0; Fri, 22 Feb 2008 07:25:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B093A6CCB for ; Fri, 22 Feb 2008 07:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVd8MiP4sLLx for ; Fri, 22 Feb 2008 07:25:00 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6B8AF3A6CB0 for ; Fri, 22 Feb 2008 07:24:58 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 15:24:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 15:24:52 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345BF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Achzyy0sp38h2l6HSYqRz2yLO9jMwAAEVyCgAB2PZmAABaOHIAABqVHwAAS8CrAAOLaIkA== From: To: , X-OriginalArrivalTime: 22 Feb 2008 15:24:52.0259 (UTC) FILETIME=[11E87F30:01C87567] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ingemar Just catching up - haven't read all the thread, so sorry if this has already been brought up. you clear ECT to 00 at the ingress. therefore ecn [3168] doesn't work - unless you take alternative action (Architecture draft describes the possibilities, S3.5: [downgrade the packet to non PCN-BA, eg best effort; tunnel the packet, so that the ECN-marking is carried transparently across the PCN-domain.]) I don't see the fact that you carry 11 transparently makes any difference to this. phil > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 21 February 2008 13:47 > To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni- > wuerzburg.de; Moncaster,T,Toby,CXR9 R > Subject: RE: [PCN] FW: RE: PCN encoding option > > Hi > > Putting the issues with "leakage" aside (I cannot tell how serious this > problem really is). > > I would prefer to sacrifice the end to end ECN semantics for the ECT(0) > and ECT(1) codepoints instead of the ECN-CE codepoint. The reason is > simply that from a realtime communication scenario with out of band > signaling it is always possible to negotiate the use of ECN CE mark in > wireless nodes by means of eg. SIP signaling. Also, atleast for RTP/UDP > I see little use for ECN nonce like it is done with TCP as this is more > or less an anti-cheat feature. > > > One would then end up with a PCN encoding schema like (I beleve option 5 > in figure 1 in the PCN encoding draft) is the closest. > > PCN Meaning ECN DSCP > ============================= > PCN capable 00 PCN 1 > Admission Mark 01 PCN 1 > Termination Mark 10 PCN 1 > > At PCN ingress the ECT(0) and ECT(1) codepoints should be set to "00", > likewise at PCN egress. ECN CE is however left untouched. This has the > effect that routers will be able to set ECN-CE on packets before they > enter the first PCN domain, after exit from the PCN domain routers are > not anymore allowed to set ECN-CE (RFC4774 section 4.3). Wireless nodes > such as LTE-eNB (Long Term Evolution-Enhanced Node B) can however set > ECN CE as this is can be managed by out of band signaling. > > Besides this I would prefer a solution that maintains end to end > semantics regardless of DSCP value. If one consider DCCP we don't know > today if it will be a best effort traffic alternatiive or if there is a > benefit with it even with QoS and DCCP can use ECN nonce. > > /Ingemar > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: den 21 februari 2008 11:07 > > To: philip.eardley@bt.com; Ingemar Johansson S > > Cc: pcn@ietf.org; bob.briscoe@bt.com; > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > Hi Phil, Hi all > > > > In order to make a selection of one single (or two) options, > > I think that the PCN WG should get the possibility to study > > all the possible and PCN relevant encoding options. > > > > In my opinion the goal of the encoding draft is to provide > > this information to the PCN-WG. > > Based on this information the PCN WG can discuss and decide > > which of the options should be used. > > > > The below text is copied from the current version of the > > encoding draft! > > Four options are described! > > Please note that the encoding draft should list all relevant > > options with advantages and disadvantages. > > > > Phil and Ingemar, if you can add advantages, disadvantages to > > the ones already mentioned below in Section 3.2.1 and 3.2.2 > > of the encoding draft, please do. > > > > Best regards, > > Georgios > > > > > > > > 3.2. Encoding Using DSCP Field > > > > In this type of encoding and transport method the congestion and > > precongestion information is encoded into the 6 DSCP bits that are > > transported in the IP header of the data packets. Four possible > > alternatives can be distinguished, as can be seen in Figure 3, with > > details provided by draft-westberg-pcn-load-control-02.txt [4]. > > Option 7 needs 2 additional DSCP values, Options 8 and 9 need three > > additional DSCP values and Option 10 needs four additional DSCP > > values. Note that all additional and experimental DSCP values are > > representing and are associated with the same PHB. The 1st, 2nd, > > 3rd, and 4th DSCP values are representing DSCP values that are > > assigned by IANA as DSCP experimental values, see RFC 2211 [9]. > > > > > > > > > > -------------------------------------------------------------- > > --------- > > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 > > |Add DSCP 4 > > || > > ===========++==========+===========+===========+===========+== > > =========| > > | Option 6 || Not-PCN | PCN | AM/TM | NA | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 7 || Not-PCN | PCN | AM/TM | AfM | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 8 || Not-PCN | PCN | AM | TM | > > NA | > > |-----------++----------+-----------+-----------+-----------+- > > ----------| > > | Option 9 || Not-PCN | PCN | AM | TM | > > AfM | > > > > -------------------------------------------------------------- > > --------- > > > > Notes: Not-PCN means the packet is not PCN capable. > > > > Figure 2: Encoding of PCN Information Using DSCP Field > > > > 3.2.1. Benefits of Using DSCP Field > > > > The main benefit of using the DSCP field is that it is not > > affecting > > the end-to-end ECN semantics and therefore the issues and concerns > > raised in RFC 4774 [22] are not applicable for this > > encoding scheme. > > Another benefit is related to the fact that all 4 DSCP encoding > > options depicted in Figure 2 can support the PCN capable not > > congested (PCN) indication, the admission control (AM) and flow > > termination (TM) encoding states. In addition Option 8 and 10 can > > support the ECMP solution. > > > > 3.2.2. Drawbacks of Using DSCP Field > > > > This type of encoding needs to use per PHB, in addition to the > > original DSCP and depending on the encoding option used, one, two, > > three, or four DSCP values, respectively. These additional DSCP > > values can be taken from the DSCP values that are not defined by > > standards action, see RFC 2211 [9]. Note that all the additional > > DSCP values are representing and are associated with one PHB. The > > value of this DSCP/PHB can either follow a standards > > action or use a > > value that is applied for experimental or local use. It > > is important > > to note that the number of the DSCP values used for local or > > experimental use is restricted and therefore the number of > > different > > PHBs supported in the PCN domain will also be restricted. > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > philip.eardley@bt.com > > > Sent: donderdag 21 februari 2008 10:24 > > > To: ingemar.s.johansson@ericsson.com; > > > menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > Ingemar > > > > > > Re > > > > > > > consider the end to end ECN usecases > > > > > > I believe that the emails below about Toby's encoding proposal do > > > indeed already consider ECN. Would appreciate it if you could add > > > further text to it to better capture the (pros and) cons. > > > > > > > more DSCP codepoints > > > I think you may be proposing an encoding that uses all dscp > > codepoints > > > (as has Georgios). That's fine - but a "1 pager" > > > setting out this option with its pros and cons (ie similar to what > > > toby has done below) is needed I think! At the moment we > > have lots of > > > options on the table - in order to reach a decision, I > > think we really > > > need very few options but with their pros and cons better laid out. > > > > > > > > > I haven't managed to get to your draft yet, sorry (next week > > > hopefully) > > > - > > > Thanks > > > Phil > > > > > > > > > > -----Original Message----- > > > > From: Ingemar Johansson S > > [mailto:ingemar.s.johansson@ericsson.com] > > > > Sent: 21 February 2008 06:43 > > > > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de; > > > > Moncaster,T,Toby,CXR9 R > > > > Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > > > > Subject: RE: [PCN] FW: RE: PCN encoding option > > > > > > > > Hi > > > > > > > > In this discussion it may be well worth the effort to > > > consider the end > > > > to end ECN usecases that we foresee when considering various PCN > > > > encoding options. > > > > Please have a look at > > > > > > > > > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > > > > for a discussion of the use cases and a motivation to why > > end to end > > > ECN > > > > should be maintained even across PCN nodes even for non > > DF traffic. > > > > That said I realize that there is some cost associated to > > > the use of > > > > DSCP codepoints, this cost must however be weighted against > > > the risk > > > > that other functionality like end to end ECN semantics is > > probably > > > > broken if a PCN encoding option "fiddles" with the ECN bits. It is > > > easy > > > > to see that if one wish to maintain support for end to > > end ECN (not > > > only > > > > in DF class) it simply costs more DSCP codepoints. > > > > I am not explicitly saying don't do this or that but I wish > > > to avoid a > > > > situation where one technique has to be avoided in favor of > > > the other > > > as > > > > it may in the end prevent deployment of both. If one can > > > yank the two > > > > together so much the better even though the cost e.g in DSCP code > > > points > > > > is regarded as higher. > > > > > > > > Regards > > > > Ingemar > > > > > > > > > -----Original Message----- > > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > On Behalf > > > > > Of philip.eardley@bt.com > > > > > Sent: den 20 februari 2008 17:44 > > > > > To: menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > > > > > Cc: pcn@ietf.org; bob.briscoe@bt.com > > > > > Subject: Re: [PCN] FW: RE: PCN encoding option > > > > > > > > > > Thanks Michael > > > > > > > > > > I agree with you that spending one DSCP value is quite > > expensive > > > > > (not two, as one is spent anyway). I think the only way > > of really > > > > > assessing this properly is for an alternative proposal > > (with pros > > > > > and cons) that requires only one DSCP. > > > > > Then we can see where the consensus for the best (/least bad) > > > > > encoding lies. Personally I have no axe to grind for or against > > > > > either - I'm not yet convinced that the proposal below is > > > definitely > > > > > the way to go, until compared it in detail with other proposals. > > > > > > > > > > So I think it would be really useful to have a "1 pager" for > > > > > alternative > > > > > proposal(s) before the ietf, as I think this would make > > > Philadelphia > > > > > discussions more productive. > > > > > > > > > > > > > > > You're correct about one of the motivations > > (advantages) for this > > > > > proposal (although I don't think the issues are exactly > > > the same for > > > > > 11 leakage as 01/10 leakage). > > > > > > > > > > Consider the case where 11 leaks out of the PCN domain. If the > > > > > endpoints are ECN capable, then the ECN source slows > > down (seems > > > > > reasonable). If they're not capable, then the impact > > outside the > > > > > domain isn't any different to what would happen without > > > PCN-domain. > > > > > > > > > > Consider the case where ECN-11 leaks into the PCN domain. > > > > > Then this will lead to either flow admission or > > > termination in the > > > > > PCN-domain. These are both safe, in that the reaction is > > > (I believe) > > > > > at least as severe as would happen in an all ECN world. > > > > > You mention that this might not terminate the ECN-11 flow > > > > > specifically (some other flow might get terminated instead). > > > > > I think this is true, though it also implies that [1] > > > end-to-end ECN > > > > > & PCN on the same flow really is useful, [2] the mechanism (eg > > > > > tunnelling) to carry ECN-marking transparently across the > > > PCN-domain > > > > > has also failed, [3] the flows which are terminated aren't other > > > > > ECN-11 flows that are also getting in due to the same > > > > > misconfiguration. > > > > > > > > > > Best wishes > > > > > Phil > > > > > > -----Original Message----- > > > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > > > Sent: 20 February 2008 10:50 > > > > > > To: Moncaster,T,Toby,CXR9 R > > > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > > khchan@nortel.com; > > > > > > babiarz@nortel.com; sob@harvard.edu; > > steven.blake@ericsson.com; > > > > > > karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > > > > > > Subject: Re: FW: RE: PCN encoding option > > > > > > > > > > > > Hi Toby, > > > > > > > > > > > > as I understand the proposal, the motivation is to > > avoid 01/10 > > > > > > codepoints as it is not good if they leak out of the > > > network since > > > > > 01/10 > > > > > > is interpreted as ECN-capable ECT(0/1) by ECN nodes. > > > > > However, there is > > > > > > the same problem with 11 marking, i.e. 11-packets may not be > > > dropped > > > > > by > > > > > > ECN nodes outside the PCN domain although endpoints > > are not ECN > > > > > capable. > > > > > > Even if 11-packets trigger flow termination, it is not > > > > > guaranteed that > > > > > > exactly the marked flow going over an overloaded ECN node is > > > > > terminated. > > > > > > Just want to say that this solution wants to solve a > > > problem that > > > > > exists > > > > > > only in case of misconfiguration (leaking packets), but > > > > > does not fully > > > > > > achieve that objective. Therefore, I feel that > > spending two DSCP > > > > > values > > > > > > is quite expensive. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Michael > > > > > > > > > > > > toby.moncaster@bt.com wrote: > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > Phil and I have just been discussing the encoding draft > > > > > and feel we > > > > > may > > > > > > > have lit upon a neat solution that seems to have > > lots of pros > > > and > > > > > few > > > > > > > cons... In order to get a better feeling for this > > > > > proposal I will go > > > > > > > through the simplified version without Affected > > marking first: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11/00 PCN 2 > > > > > > > > > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same PCN > > > > > behaviour > > > > > > > aggregate. > > > > > > > > > > > > > > Pros: > > > > > > > o Termination marking and admission marking are > > independent, > > > eg > > > > > > > termination marking can be done after a packet has been > > > admission > > > > > > > marked. Therefore a router can write AM or TM without > > > > > having to read > > > > > the > > > > > > > packet's PCN marking first, which is easier to > > > implement. (Note: > > > > > > > Over-writing a TM with AM is not allowed for 3SM & CL, see > > > > > > > draft-charny-pcn-comparison.) > > > > > > > > > > > > > > o This scheme avoids giving semantics to ECT(0) and > > > > > ECT(1). This is > > > > > > > safest option if packets leak outside the PCN region, due to > > > some > > > > > fort > > > > > > > of misconfiguration of the PCN-boundary-nodes (relevant > > > > > for a single > > > > > > > domain deployment of PCN). > > > > > > > > > > > > > > o It leaves open the possibility of using ECT(0) and > > > > > ECT(1) in some > > > > > > > mysterious way in a future end-to-end PCN deployment > > > > > > > > > > > > > > o For a router to classify a packet as PCN, it > > > simply reads its > > > > > DSCP. > > > > > > > This is probably easier than checking both its DSCP & ECN > > > fields. > > > > > > > > > > > > > > o Incremental deployment steps are possible [1] > > > could deploy SM > > > > > > > initially and later AM/TM. Just add the second > > > > > DSCP. > > > > > > > If a router isn't upgraded at the same time nothing > > > too horrific > > > > > > > happens. > > > > > > > [2] could just deploy admission control & add > > > termination later, > > > > > just by > > > > > > > adding a new DSCP; there is no need to change the > > > > > encoding and check > > > > > for > > > > > > > backwards compatibility? Vice-versa is also ok? > > > > > > > > > > > > > > Cons: > > > > > > > o It needs an extra DSCP, per PCN behaviour aggregate. > > > (Although > > > > > > > possibly it's OK to use the same DSCP for TM for > > all PCN BAs?) > > > > > > > > > > > > > > o If a packet (in a PCN flow) arrives at the egress with > > > > > its ECN = > > > > > 11 > > > > > > > and it really is required to preserve this info across the > > > > > PCN-domain, > > > > > > > then some complexity is needed at the PCN-boundary-nodes > > > > > (tunnelling) > > > > > > > > > > > > > > o If the PCN-domain is operating multipath routing > > > > > (ECMP) that uses > > > > > the > > > > > > > DSCP to select routes, then there may be mis-ordering > > > of packets > > > > > within > > > > > > > a flow. This may be OK as (1) no-one has yet said > > they know of > > > an > > > > > ECMP > > > > > > > algorithm that in practie uses the DSCP; (2) a risk of > > > > > mis-ordering > > > > > when > > > > > > > there is termination marking may be acceptable > > > > > > > > > > > > > > If Affected marking is needed then the scheme can be > > > modified as > > > > > > > follows: > > > > > > > > > > > > > > PCN Meaning ECN DSCP > > > > > > > > > > > > > > PCN capable 00 PCN 1 > > > > > > > Admission Mark 11 PCN 1 > > > > > > > Termination Mark 11 PCN 2 > > > > > > > Affected Mark 00 PCN 2 > > > > > > > > > > > > > > The pros for this scheme are broadly similar to the above. > > > However > > > > > there > > > > > > > is a new con which may or may not matter: If a packet is > > > affected > > > > > marked > > > > > > > and a later node is doing admission marking then it will > > > > > reset the > > > > > > > affected mark to a termination mark. Work would be needed > > > > > to see if > > > > > this > > > > > > > skews the results and causes significant over-termination or > > > not. > > > > > > > > > > > > > > Please could people look through this scheme and > > > highlight any > > > > > > > additional concerns that they may have (and extra > > > benefits too). > > > I > > > > > would > > > > > > > like to get as many opinions as possible. > > > > > > > > > > > > > > What I want to avoid is people just emailing back with > > > > > "why not try > > > > > this > > > > > > > scheme instead". Currently we seem to have a plethora of > > > possible > > > > > > > schemes on the table and people need to start putting > > > down much > > > > > clearer > > > > > > > pros and cons for the schemes they support... So it could > > > > > be good to > > > > > > > have a similar "one page" email about a specific scheme that > > > only > > > > > uses > > > > > > > one DSCP for PCN, but uses the 01/10 codepoints instead. > > > > > > > > > > > > > > Toby > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > Toby Moncaster, Networks Research > > > > > Centre, BT > > > > > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > http://www.ietf.org/mailman/listinfo/pcn > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:29:19 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3233A6D05; Fri, 22 Feb 2008 07:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=-2.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 fOvAkBnmPLbY; Fri, 22 Feb 2008 07:29:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADD23A6CA7; Fri, 22 Feb 2008 07:29:18 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BD03A6CA7 for ; Fri, 22 Feb 2008 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SHAaDDCsHYu for ; Fri, 22 Feb 2008 07:29:16 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 13D5E3A67D7 for ; Fri, 22 Feb 2008 07:29:15 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1MFTBhU010108 for ; Fri, 22 Feb 2008 09:29:11 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:29:11 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:29:10 -0600 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Fri, 22 Feb 2008 15:29:10 +0000 Message-Id: <1203694150.3476.2.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 22 Feb 2008 15:29:11.0079 (UTC) FILETIME=[AC2D4B70:01C87567] Subject: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The chairs would like input on whether the working group has read draft-ietf-pcn-architecture-03, and believes that it is ready for working group last call. Please send your comments to this list. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:33:41 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEB528C403; Fri, 22 Feb 2008 07:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 f7rrWKQh3v2c; Fri, 22 Feb 2008 07:33:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BDC28C728; Fri, 22 Feb 2008 07:33:37 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163DE28C69F for ; Fri, 22 Feb 2008 07:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO+G0lid6Iuu for ; Fri, 22 Feb 2008 07:33:36 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A522E28CA70 for ; Fri, 22 Feb 2008 07:32:35 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1MFWVki012919 for ; Fri, 22 Feb 2008 09:32:31 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:32:30 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 09:32:30 -0600 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Fri, 22 Feb 2008 15:32:29 +0000 Message-Id: <1203694349.3476.6.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 22 Feb 2008 15:32:30.0828 (UTC) FILETIME=[233C92C0:01C87568] Subject: [PCN] PCN IETF 71 agenda 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org PCN currently has two meeting slots scheduled for IETF 71 - Philidelphia: Tuesday 1520-1720 Thursday 0900-1130 Please send your requests for agenda time to the chairs. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:44:07 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C33B28C3F5; Fri, 22 Feb 2008 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.416 X-Spam-Level: *** X-Spam-Status: No, score=3.416 tagged_above=-999 required=5 tests=[AWL=-2.647, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 tYeZRCXb6wLL; Fri, 22 Feb 2008 07:44:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C175B28C25A; Fri, 22 Feb 2008 07:44:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED30E28C25A for ; Fri, 22 Feb 2008 07:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifQGQV7mLFRk for ; Fri, 22 Feb 2008 07:43:59 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id BFF2C28C23B for ; Fri, 22 Feb 2008 07:43:58 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 15:43:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 15:44:05 -0000 Message-ID: In-Reply-To: <47BEE784.6070902@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option thread-index: Ach1Zjcjf84NAwkYTM2wJ3+W8HV18wAAB4RA From: To: , X-OriginalArrivalTime: 22 Feb 2008 15:43:53.0773 (UTC) FILETIME=[BA4DB5D0:01C87569] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Just a quick question relating to all this: What deployment scenarios do people envisage as being sensible for the single-domain PCN solution we are currently meant to be standardising? It strikes me that some of the coding schemes are making assumptions about the nature of the network topology either side of the PCN domain. I actually do quite like Ingemar's scheme, especially in the modified version using a parallel DSCP which provides a really elegant way to tunnel 11 across the PCN region. One definite con (true for many schemes) is that you have to read both the DSCP and the ECN fields before you can decide how to mark (as you mustn't remark TM to AM). I am still unclear exactly how Michael envisages metering these packets? Would you meter them with other TM marks? Toby > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 22 February 2008 15:17 > To: Ingemar Johansson S > Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; > Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > Subject: Re: [PCN] FW: RE: PCN encoding option > > Hi Ingemar, > > see inline. > > Ingemar Johansson S wrote: > > Hi Michael. > > > > Answer inline below. > > > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: den 22 februari 2008 12:13 > >> To: Ingemar Johansson S > >> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > >> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > >> Subject: Re: [PCN] FW: RE: PCN encoding option > >> > >> Hi Ingemar, > >> > >> Ingemar Johansson S wrote: > >> > >>> Hi > >>> > >>> See inline > >>> > >>> /Ingemar > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >>>> Sent: den 22 februari 2008 10:13 > >>>> To: Ingemar Johansson S > >>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; > >>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com > >>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>> > >>>> Hi Ingemar, > >>>> > >>>> this solution essentially spends a DSCP to save > 11-marking through > >>>> the PCN domain and allow them to be PCN-marked. This is a > >>>> > >> rather high > >> > >>>> price, in particular because the PCN packets need to be > >>>> > >> remarked to > >> > >>>> 00. This has the consequence that ECN capability is lost > >>>> > >> for the rest > >> > >>>> of the path. > >>>> > >>>> > >>> Not sure that I agree, yes the ECT(0), ECT(1) codepoints > >>> > >> are lost and > >> > >>> there goes also the ECN nonce and the "inband" ECN > >>> > >> capability signaling. > >> > >>> A router outside the PCN domain wont be able to set ECN-CE. > >>> > >> However if > >> > >>> the ECN capability is negotiated out of band for the wireless > >>> endpoints and the up and downlink wireless nodes, these > >>> > >> will be ECN-CE > >> > >>> capable but without the nonce capability. > >>> > >>> > >> The difficulty is that the information for each packet > >> whether 10 or 01 must be kept, that says RFC4774: > >> > >> Similarly, if a packet that *could* be using default > >> semantics is marked with the ECN codepoint "01", then this > >> codepoint > >> should not be changed to "10" in the network (and a > "10" codepoint > >> should not be changed to "01"). This requirement is > necessary to > >> avoid interference with the transport protocol's use of > >> the ECN nonce > >> [RFC3540]. > >> > >> This would require a per packet signalling ... > >> > > > > Not 100% convinced here, ECN codepoints "01" and "10" can > be reset to > > "00", that is my interpretation of 4.3 in RFC4774. > > What might be seen as odd is perhaps that after PCN egress the ECN > > pattern using this trick will only use the code points "00" or "11" > > instead of the normal "01", "10" and "11" (if ECN capable). > > Routers located after PCN egress won't be able to set ECN > "11" as the > > flow is not anymore regarded as ECN capable (on IP level). Wireless > > nodes such as LTE-eNB can however be instructed to set ECN > "11" during > > congestion as this then controlled using out of band > signaling, this out > > of band signaling is in turn controlled by policy rules > that will limit > > the risk for cheating. > > Note that this is meant for realtime traffic and a means to > do efficient > > adaptation in a wireless enviroment where the transmission > capacity for > > a single user changes changes dynamically due to physical > factors such > > as shadowing et.c. > > > > Ok, I see. I think this is a solution not standardized by the > IETF and > can be done for any encoding scheme. If not, what's its > requirement on > the encoding? > > Regards, > > Michael > > > > > > > > >>> > >>> > >>> > >>>> Therefore, I opt for one of the two versions > >>>> 1) discard 11-marked PCN packets before entering the PCN > domain OR > >>>> 2) let them go through the PCN domain, take them into > account for > >>>> metering, but do not remark them. > >>>> The first option loses ECN capability for PCN traffic, > the second > >>>> option keeps it on the subpath before entering the PCN domain. > >>>> > >>>> > >>> Not sure I follow here. What would option 2 look like? > >>> My interpretation: Packets with DSCP=EF enters the PCN domain, at > >>> ingress they are remarked as DSCP=PCN unless ECN="11", in > >>> > >> which case > >> > >>> DSCP=EF. What about ECN="01" or "01" will these also be kept as > >>> DSCP=EF or will the ECN bits be set to "00". > >>> Please explain. > >>> > >>> > >> EF DSCP is remarked to PCN in any case. > >> 1) 11-marked PCN packets are dropped by the PCN ingress > >> 2) 11 is kept as is > >> and 01/10 marking is reset to 00 (no-precongestion). The PCN > >> egress node resets 10/01 marked packets to 00. Therefore, the > >> ECN capability for PCN traffic is lost > >> 1) completely > >> 2) for the partial downstream path starting with the PCN > ingress node. > >> > >> It's true that PCN marking can get problems if the majority > >> of PCN packets was CE-marked when entering the PCN domain. > >> This kind of traffic also cheats ECN when it doesn't back > >> off. I just want to say: even TCP senders and receivers can > >> cheat, do we care? The question is what's more > >> important: remaining ECN functionality for the partial path > >> up to the PCN ingress node or safety against too many > >> 11-marked packets. I see these options (1 and 2) and have no > >> particular preference. > >> > >> Regards, > >> > >> Michael > >> > >> > >>> > >>> > >>>> Regards, > >>>> > >>>> Michael > >>>> > >>>> Ingemar Johansson S wrote: > >>>> > >>>> > >>>>> Hi > >>>>> > >>>>> Answers inline > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > >>>>>> Sent: den 21 februari 2008 15:34 > >>>>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; > >>>>>> philip.eardley@bt.com > >>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >>>>>> menth@informatik.uni-wuerzburg.de > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>> > >>>>>> Hi Ingemar, > >>>>>> > >>>>>> This is exactly the sort of thing Phil and I were hoping > >>>>>> > >>>>>> > >>>> to trigger > >>>> > >>>> > >>>>>> people to write in response to our email. We are hoping to > >>>>>> > >>>>>> > >>>> settle on > >>>> > >>>> > >>>>>> what are the real options people support for the > >>>>>> > >> encoding and why > >> > >>>>>> they support them... > >>>>>> > >>>>>> Just one quick observation - if we have to leave 11 > >>>>>> > >>>>>> > >>>> unchanged across > >>>> > >>>> > >>>>>> the PCN domain this will mean that such packets can't be > >>>>>> > >>>>>> > >>>> PCN marked > >>>> > >>>> > >>>>>> and thus they should not form part of any PCN aggregate (in my > >>>>>> opinion)... > >>>>>> > >>>>>> > >>>>>> > >>>>> Realized that this is one (big) problem, thanks for > >>>>> > >>>>> > >>>> pointing out this > >>>> > >>>> > >>>>> issue. > >>>>> > >>>>> The next alternative is then > >>>>> PCN Meaning ECN DSCP > >>>>> ============================= > >>>>> PCN capable 00 PCN 1 > >>>>> Admission Mark 01 PCN 1 > >>>>> Termination Mark 10 PCN 1 > >>>>> > >>>>> PCN capable+ECN CE 00 PCN 2 > >>>>> AM+ECN CE 01 PCN 2 > >>>>> TM+ECN CE 10 PCN 2 > >>>>> > >>>>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN > >>>>> > >>>>> > >>>> egress PCN > >>>> > >>>> > >>>>> 2 is mapped back to the ECN bits as ECN-CE "11". > >>>>> > >>>>> AfM can also be included in the schema > >>>>> > >>>>> I know this does cost an extra DSCP codepoint and it completely > >>>>> disregards the leakage issue, also it possible that this > >>>>> > >>>>> > >>>> alternative > >>>> > >>>> > >>>>> or something similar is given in the PCN encoding draft > >>>>> > >> but I don't > >> > >>>>> think so as this alternative does not preserve the end > to end ECN > >>>>> semantics to 100%, rather it assumes that negotiation of > >>>>> > >> the use of > >> > >>>>> ECN is done out of band at session setup. > >>>>> > >>>>> /Ingemar > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Toby > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ingemar Johansson S > >>>>>>> > >>>>>>> > >>>> [mailto:ingemar.s.johansson@ericsson.com] > >>>> > >>>> > >>>>>>> Sent: 21 February 2008 13:47 > >>>>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R > >>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; > >>>>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R > >>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>>> > >>>>>>> Hi > >>>>>>> > >>>>>>> Putting the issues with "leakage" aside (I cannot tell > >>>>>>> > >>>>>>> > >>>> how serious > >>>> > >>>> > >>>>>>> this problem really is). > >>>>>>> > >>>>>>> I would prefer to sacrifice the end to end ECN > semantics for the > >>>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE > >>>>>>> > >> codepoint. The > >> > >>>>>>> reason is simply that from a realtime communication > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> scenario with out > >>>>>> > >>>>>> > >>>>>> > >>>>>>> of band signaling it is always possible to negotiate the > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> use of ECN CE > >>>>>> > >>>>>> > >>>>>> > >>>>>>> mark in wireless nodes by means of eg. SIP signaling. > >>>>>>> > >>>>>>> > >>>> Also, atleast > >>>> > >>>> > >>>>>>> for RTP/UDP I see little use for ECN nonce like it is done > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> with TCP as > >>>>>> > >>>>>> > >>>>>> > >>>>>>> this is more or less an anti-cheat feature. > >>>>>>> > >>>>>>> > >>>>>>> One would then end up with a PCN encoding schema like > (I beleve > >>>>>>> option 5 in figure 1 in the PCN encoding draft) is > the closest. > >>>>>>> > >>>>>>> PCN Meaning ECN DSCP > >>>>>>> ============================= > >>>>>>> PCN capable 00 PCN 1 > >>>>>>> Admission Mark 01 PCN 1 > >>>>>>> Termination Mark 10 PCN 1 > >>>>>>> > >>>>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> set to "00", > >>>>>> > >>>>>> > >>>>>> > >>>>>>> likewise at PCN egress. ECN CE is however left untouched. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> This has the > >>>>>> > >>>>>> > >>>>>> > >>>>>>> effect that routers will be able to set ECN-CE on packets > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> before they > >>>>>> > >>>>>> > >>>>>> > >>>>>>> enter the first PCN domain, after exit from the PCN > >>>>>>> > >>>>>>> > >>>> domain routers > >>>> > >>>> > >>>>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). > >>>>>>> Wireless nodes > >>>>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> however set > >>>>>> > >>>>>> > >>>>>> > >>>>>>> ECN CE as this is can be managed by out of band signaling. > >>>>>>> > >>>>>>> Besides this I would prefer a solution that maintains > >>>>>>> > >> end to end > >> > >>>>>>> semantics regardless of DSCP value. If one consider DCCP we > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> don't know > >>>>>> > >>>>>> > >>>>>> > >>>>>>> today if it will be a best effort traffic alternatiive or > >>>>>>> > >>>>>>> > >>>> if there > >>>> > >>>> > >>>>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. > >>>>>>> > >>>>>>> /Ingemar > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>>>>>> Sent: den 21 februari 2008 11:07 > >>>>>>>> To: philip.eardley@bt.com; Ingemar Johansson S > >>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; > >>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Phil, Hi all > >>>>>>>> > >>>>>>>> In order to make a selection of one single (or two) > options, I > >>>>>>>> think that the PCN WG should get the possibility to > >>>>>>>> > >>>>>>>> > >>>> study all the > >>>> > >>>> > >>>>>>>> possible and PCN relevant encoding options. > >>>>>>>> > >>>>>>>> In my opinion the goal of the encoding draft is to > >>>>>>>> > >> provide this > >> > >>>>>>>> information to the PCN-WG. > >>>>>>>> Based on this information the PCN WG can discuss and > >>>>>>>> > >>>>>>>> > >>>> decide which > >>>> > >>>> > >>>>>>>> of the options should be used. > >>>>>>>> > >>>>>>>> The below text is copied from the current version of the > >>>>>>>> > >>>>>>>> > >>>> encoding > >>>> > >>>> > >>>>>>>> draft! > >>>>>>>> Four options are described! > >>>>>>>> Please note that the encoding draft should list all relevant > >>>>>>>> options with advantages and disadvantages. > >>>>>>>> > >>>>>>>> Phil and Ingemar, if you can add advantages, > >>>>>>>> > >>>>>>>> > >>>> disadvantages to the > >>>> > >>>> > >>>>>>>> ones already mentioned below in Section 3.2.1 and > 3.2.2 of the > >>>>>>>> encoding draft, please do. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Georgios > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 3.2. Encoding Using DSCP Field > >>>>>>>> > >>>>>>>> In this type of encoding and transport method the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> congestion and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> precongestion information is encoded into the 6 DSCP > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> bits that are > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> transported in the IP header of the data packets. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> Four possible > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> alternatives can be distinguished, as can be seen in > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Figure 3, with > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> details provided by > >>>>>>>> > >>>>>>>> > >>>> draft-westberg-pcn-load-control-02.txt [4]. > >>>> > >>>> > >>>>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> need three > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> additional DSCP values and Option 10 needs four > >>>>>>>> > >>>>>>>> > >>>> additional DSCP > >>>> > >>>> > >>>>>>>> values. Note that all additional and experimental DSCP > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> values are > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> representing and are associated with the same PHB. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> The 1st, 2nd, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> 3rd, and 4th DSCP values are representing DSCP > >>>>>>>> > >> values that are > >> > >>>>>>>> assigned by IANA as DSCP experimental values, see RFC > >>>>>>>> > >>>>>>>> > >>>> 2211 [9]. > >>>> > >>>> > >>>>>>>> > >>>>>>>> > -------------------------------------------------------------- > >>>>>>>> --------- > >>>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add > >>>>>>>> > >> DSCP 3 Add > >> > >>>>>>>> |DSCP 4 > >>>>>>>> || > >>>>>>>> > ===========++==========+===========+===========+===========+== > >>>>>>>> =========| > >>>>>>>> | Option 6 || Not-PCN | PCN | AM/TM | > NA | > >>>>>>>> NA | > >>>>>>>> > |-----------++----------+-----------+-----------+-----------+- > >>>>>>>> ----------| > >>>>>>>> | Option 7 || Not-PCN | PCN | AM/TM | > AfM | > >>>>>>>> NA | > >>>>>>>> > |-----------++----------+-----------+-----------+-----------+- > >>>>>>>> ----------| > >>>>>>>> | Option 8 || Not-PCN | PCN | AM | > TM | > >>>>>>>> NA | > >>>>>>>> > |-----------++----------+-----------+-----------+-----------+- > >>>>>>>> ----------| > >>>>>>>> | Option 9 || Not-PCN | PCN | AM | > TM | > >>>>>>>> AfM | > >>>>>>>> > >>>>>>>> > -------------------------------------------------------------- > >>>>>>>> --------- > >>>>>>>> > >>>>>>>> Notes: Not-PCN means the packet is not PCN capable. > >>>>>>>> > >>>>>>>> Figure 2: Encoding of PCN Information Using > >>>>>>>> > >> DSCP Field > >> > >>>>>>>> 3.2.1. Benefits of Using DSCP Field > >>>>>>>> > >>>>>>>> The main benefit of using the DSCP field is that > it is not > >>>>>>>> affecting > >>>>>>>> the end-to-end ECN semantics and therefore the issues > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> and concerns > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> raised in RFC 4774 [22] are not applicable for this > >>>>>>>> > >> encoding > >> > >>>>>>>> scheme. > >>>>>>>> Another benefit is related to the fact that all 4 > >>>>>>>> > >>>>>>>> > >>>> DSCP encoding > >>>> > >>>> > >>>>>>>> options depicted in Figure 2 can support the PCN > capable not > >>>>>>>> congested (PCN) indication, the admission control > >>>>>>>> > >>>>>>>> > >>>> (AM) and flow > >>>> > >>>> > >>>>>>>> termination (TM) encoding states. In addition Option 8 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> and 10 can > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> support the ECMP solution. > >>>>>>>> > >>>>>>>> 3.2.2. Drawbacks of Using DSCP Field > >>>>>>>> > >>>>>>>> This type of encoding needs to use per PHB, in > >>>>>>>> > >> addition to the > >> > >>>>>>>> original DSCP and depending on the encoding option used, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> one, two, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> three, or four DSCP values, respectively. These > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> additional DSCP > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> values can be taken from the DSCP values that are not > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> defined by > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> standards action, see RFC 2211 [9]. Note that all the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> additional > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> DSCP values are representing and are associated with one > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> PHB. The > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> value of this DSCP/PHB can either follow a standards > >>>>>>>> > >>>>>>>> > >>>> action or > >>>> > >>>> > >>>>>>>> use a > >>>>>>>> value that is applied for experimental or local > use. It is > >>>>>>>> important > >>>>>>>> to note that the number of the DSCP values used > for local or > >>>>>>>> experimental use is restricted and therefore the > number of > >>>>>>>> different > >>>>>>>> PHBs supported in the PCN domain will also be restricted. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Georgios > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Behalf Of > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> philip.eardley@bt.com > >>>>>>>>> Sent: donderdag 21 februari 2008 10:24 > >>>>>>>>> To: ingemar.s.johansson@ericsson.com; > >>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com > >>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>>>>>> > >>>>>>>>> Ingemar > >>>>>>>>> > >>>>>>>>> Re > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> consider the end to end ECN usecases > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> I believe that the emails below about Toby's encoding > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> proposal do > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> indeed already consider ECN. Would appreciate it if you > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> could add > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> further text to it to better capture the (pros and) cons. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> more DSCP codepoints > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> I think you may be proposing an encoding that uses all dscp > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> codepoints > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> (as has Georgios). That's fine - but a "1 pager" > >>>>>>>>> setting out this option with its pros and cons (ie > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> similar to what > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> toby has done below) is needed I think! At the moment we > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> have lots of > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> options on the table - in order to reach a decision, I > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> think we really > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> need very few options but with their pros and cons better > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> laid out. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> I haven't managed to get to your draft yet, sorry (next week > >>>>>>>>> hopefully) > >>>>>>>>> - > >>>>>>>>> Thanks > >>>>>>>>> Phil > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Ingemar Johansson S > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> [mailto:ingemar.s.johansson@ericsson.com] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>> Sent: 21 February 2008 06:43 > >>>>>>>>>> To: Eardley,PL,Philip,CXR9 R; > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> menth@informatik.uni-wuerzburg.de; > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> Moncaster,T,Toby,CXR9 R > >>>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R > >>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option > >>>>>>>>>> > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> In this discussion it may be well worth the effort to > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> consider the end > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> to end ECN usecases that we foresee when considering > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> various PCN > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>> encoding options. > >>>>>>>>>> Please have a look at > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >> > http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt > >> > >>>> > >>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> for a discussion of the use cases and a motivation to why > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> end to end > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> ECN > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> should be maintained even across PCN nodes even for non > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> DF traffic. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>> That said I realize that there is some cost associated to > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> the use of > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> DSCP codepoints, this cost must however be weighted against > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> the risk > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> that other functionality like end to end ECN semantics is > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> probably > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>> broken if a PCN encoding option "fiddles" with the ECN > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> bits. It is > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> easy > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> to see that if one wish to maintain support for end to > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> end ECN (not > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> only > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> in DF class) it simply costs more DSCP codepoints. > >>>>>>>>>> I am not explicitly saying don't do this or that but I wish > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> to avoid a > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> situation where one technique has to be avoided in favor of > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> the other > >>>>>>>>> as > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> it may in the end prevent deployment of both. If one can > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> yank the two > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> together so much the better even though the cost e.g in > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> DSCP code > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> points > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> is regarded as higher. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> Ingemar > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> On Behalf > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Of philip.eardley@bt.com > >>>>>>>>>>> Sent: den 20 februari 2008 17:44 > >>>>>>>>>>> To: menth@informatik.uni-wuerzburg.de; > toby.moncaster@bt.com > >>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com > >>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option > >>>>>>>>>>> > >>>>>>>>>>> Thanks Michael > >>>>>>>>>>> > >>>>>>>>>>> I agree with you that spending one DSCP value is quite > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> expensive > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> (not two, as one is spent anyway). I think the only way > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> of really > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> assessing this properly is for an alternative proposal > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> (with pros > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> and cons) that requires only one DSCP. > >>>>>>>>>>> Then we can see where the consensus for the best > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> (/least bad) > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> encoding lies. Personally I have no axe to grind for > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> or against > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>> either - I'm not yet convinced that the proposal below is > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> definitely > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> the way to go, until compared it in detail with other > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> proposals. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>> So I think it would be really useful to have a "1 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> pager" for > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> alternative > >>>>>>>>>>> proposal(s) before the ietf, as I think this would make > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> Philadelphia > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> discussions more productive. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> You're correct about one of the motivations > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> (advantages) for this > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> proposal (although I don't think the issues are exactly > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> the same for > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 11 leakage as 01/10 leakage). > >>>>>>>>>>> > >>>>>>>>>>> Consider the case where 11 leaks out of the PCN > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> domain. If the > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>> endpoints are ECN capable, then the ECN source slows > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> down (seems > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> reasonable). If they're not capable, then the impact > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> outside the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> domain isn't any different to what would happen without > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> PCN-domain. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. > >>>>>>>>>>> Then this will lead to either flow admission or > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> termination in the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> PCN-domain. These are both safe, in that the reaction is > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> (I believe) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> at least as severe as would happen in an all ECN world. > >>>>>>>>>>> You mention that this might not terminate the ECN-11 flow > >>>>>>>>>>> specifically (some other flow might get > terminated instead). > >>>>>>>>>>> I think this is true, though it also implies that [1] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> end-to-end ECN > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> & PCN on the same flow really is useful, [2] the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> mechanism (eg > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> tunnelling) to carry ECN-marking transparently across the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> PCN-domain > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> has also failed, [3] the flows which are terminated > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> aren't other > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>> ECN-11 flows that are also getting in due to the same > >>>>>>>>>>> misconfiguration. > >>>>>>>>>>> > >>>>>>>>>>> Best wishes > >>>>>>>>>>> Phil > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Michael Menth > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> [mailto:menth@informatik.uni-wuerzburg.de] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>>> Sent: 20 February 2008 10:50 > >>>>>>>>>>>> To: Moncaster,T,Toby,CXR9 R > >>>>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> khchan@nortel.com; > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> steven.blake@ericsson.com; > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R > >>>>>>>>>>>> Subject: Re: FW: RE: PCN encoding option > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Toby, > >>>>>>>>>>>> > >>>>>>>>>>>> as I understand the proposal, the motivation is to > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> avoid 01/10 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> codepoints as it is not good if they leak out of the > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> network since > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 01/10 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> However, there is > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> the same problem with 11 marking, i.e. 11-packets > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> may not be > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> dropped > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> by > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> ECN nodes outside the PCN domain although endpoints > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> are not ECN > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> capable. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Even if 11-packets trigger flow termination, it is not > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> guaranteed that > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> exactly the marked flow going over an overloaded > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> ECN node is > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> terminated. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Just want to say that this solution wants to solve a > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> problem that > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> exists > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> only in case of misconfiguration (leaking packets), but > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> does not fully > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> achieve that objective. Therefore, I feel that > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> spending two DSCP > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> values > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> is quite expensive. > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Michael > >>>>>>>>>>>> > >>>>>>>>>>>> toby.moncaster@bt.com wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> All, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Phil and I have just been discussing the encoding draft > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> and feel we > >>>>>>>>>>> may > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> have lit upon a neat solution that seems to have > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> lots of pros > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> and > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> few > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> cons... In order to get a better feeling for this > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> proposal I will go > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> through the simplified version without Affected > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> marking first: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>>>>>> > >>>>>>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>>>>>> Termination Mark 11/00 PCN 2 > >>>>>>>>>>>>> > >>>>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> the same PCN > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>> behaviour > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> aggregate. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Pros: > >>>>>>>>>>>>> o Termination marking and admission marking are > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> independent, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> eg > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> termination marking can be done after a packet has been > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> admission > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> marked. Therefore a router can write AM or TM without > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> having to read > >>>>>>>>>>> the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> packet's PCN marking first, which is easier to > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> implement. (Note: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> Over-writing a TM with AM is not allowed for > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> 3SM & CL, see > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>> draft-charny-pcn-comparison.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> ECT(1). This is > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> safest option if packets leak outside the PCN > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> region, due to > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> some > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> fort > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> for a single > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> domain deployment of PCN). > >>>>>>>>>>>>> > >>>>>>>>>>>>> o It leaves open the possibility of using ECT(0) and > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> ECT(1) in some > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> mysterious way in a future end-to-end PCN deployment > >>>>>>>>>>>>> > >>>>>>>>>>>>> o For a router to classify a packet as PCN, it > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> simply reads its > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> DSCP. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> This is probably easier than checking both its > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> DSCP & ECN > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> fields. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> o Incremental deployment steps are possible [1] > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> could deploy SM > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> initially and later AM/TM. Just add the second > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> DSCP. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> If a router isn't upgraded at the same time nothing > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> too horrific > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> happens. > >>>>>>>>>>>>> [2] could just deploy admission control & add > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> termination later, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> just by > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> adding a new DSCP; there is no need to change the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> encoding and check > >>>>>>>>>>> for > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> backwards compatibility? Vice-versa is also ok? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cons: > >>>>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> (Although > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> possibly it's OK to use the same DSCP for TM for > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> all PCN BAs?) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> o If a packet (in a PCN flow) arrives at the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> egress with > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> its ECN = > >>>>>>>>>>> 11 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> and it really is required to preserve this info > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> across the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> PCN-domain, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> (tunnelling) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> o If the PCN-domain is operating multipath routing > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> (ECMP) that uses > >>>>>>>>>>> the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> DSCP to select routes, then there may be mis-ordering > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> of packets > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> within > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> they know of > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> an > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> ECMP > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> mis-ordering > >>>>>>>>>>> when > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> there is termination marking may be acceptable > >>>>>>>>>>>>> > >>>>>>>>>>>>> If Affected marking is needed then the scheme can be > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> modified as > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> follows: > >>>>>>>>>>>>> > >>>>>>>>>>>>> PCN Meaning ECN DSCP > >>>>>>>>>>>>> > >>>>>>>>>>>>> PCN capable 00 PCN 1 > >>>>>>>>>>>>> Admission Mark 11 PCN 1 > >>>>>>>>>>>>> Termination Mark 11 PCN 2 > >>>>>>>>>>>>> Affected Mark 00 PCN 2 > >>>>>>>>>>>>> > >>>>>>>>>>>>> The pros for this scheme are broadly similar to > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> the above. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> However > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> there > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> is a new con which may or may not matter: If a packet is > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> affected > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> marked > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> and a later node is doing admission marking then it will > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> reset the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> affected mark to a termination mark. Work would > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> be needed > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> to see if > >>>>>>>>>>> this > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> skews the results and causes significant > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> over-termination or > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> not. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> Please could people look through this scheme and > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> highlight any > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> additional concerns that they may have (and extra > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> benefits too). > >>>>>>>>> I > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> would > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> like to get as many opinions as possible. > >>>>>>>>>>>>> > >>>>>>>>>>>>> What I want to avoid is people just emailing back with > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> "why not try > >>>>>>>>>>> this > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> scheme instead". Currently we seem to have a plethora of > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> possible > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> schemes on the table and people need to start putting > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> down much > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> clearer > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> pros and cons for the schemes they support... > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> So it could > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> be good to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> have a similar "one page" email about a specific > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> scheme that > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> only > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> uses > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Toby > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >> > ____________________________________________________________________ > >> > >>>> > >>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>>>> Toby Moncaster, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> Networks Research > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> Centre, BT > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> 1473 648734 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> 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 > >>>>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> PCN mailing list > >>>>>>>>> PCN@ietf.org > >>>>>>>>> http://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 > >>>> > >>>> > >>>> > >>>> > >> -- > >> 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 > >> > >> > >> > > -- > 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 07:54:46 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9281228C1F4; Fri, 22 Feb 2008 07:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.582 X-Spam-Level: *** X-Spam-Status: No, score=3.582 tagged_above=-999 required=5 tests=[AWL=-2.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, 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 I7rbZh+IFcV7; Fri, 22 Feb 2008 07:54:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E5A3A6C5F; Fri, 22 Feb 2008 07:54:43 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849E33A6C47 for ; Fri, 22 Feb 2008 07:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltSvAud87cc8 for ; Fri, 22 Feb 2008 07:54:38 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C9E573A681C for ; Fri, 22 Feb 2008 07:54:36 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 82ABDA0685; Fri, 22 Feb 2008 16:54:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 74918A0684; Fri, 22 Feb 2008 16:54:32 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D72B1A060E; Fri, 22 Feb 2008 16:54:26 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1MFsQV16468; Fri, 22 Feb 2008 16:54:26 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 4EB90C8193; Fri, 22 Feb 2008 16:54:26 +0100 (CET) Message-ID: <47BEEFF2.5060503@informatik.uni-wuerzburg.de> Date: Fri, 22 Feb 2008 16:53:22 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, toby.moncaster@bt.com wrote: > Just a quick question relating to all this: What deployment scenarios do > people envisage as being sensible for the single-domain PCN solution we > are currently meant to be standardising? It strikes me that some of the > coding schemes are making assumptions about the nature of the network > topology either side of the PCN domain. > > I actually do quite like Ingemar's scheme, especially in the modified > version using a parallel DSCP which provides a really elegant way to > tunnel 11 across the PCN region. One definite con (true for many > schemes) is that you have to read both the DSCP and the ECN fields > before you can decide how to mark (as you mustn't remark TM to AM). I am > still unclear exactly how Michael envisages metering these packets? > Would you meter them with other TM marks? > All 11-marked packets would undergo the metering process with other NP, AM, and TM marked packets for admission metering, and they would also undergo the metering process with other NP, AM marked packets for termination metering. But given the fact that this raises vulnerabilities, I tend towards dropping 11-marked packets at the ingress which essentially switches off ECN capability for PCN traffic and saves a codepoint (11). This pushes Phil's idea of "blind marking": NP: 00 AM: 10 TM: 01 AM&TM: 11 The marker does not need to read the ECN bits before marking. Well, actually this is not true because only NP and AM packets should be respected for TM marking ... maybe not so helpful then as this applies only to AM-marking. Saving a codepoint might possibly be better for future use such as AffM? Regards, Michael > Toby > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 22 February 2008 15:17 >> To: Ingemar Johansson S >> Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; >> Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >> Subject: Re: [PCN] FW: RE: PCN encoding option >> >> Hi Ingemar, >> >> see inline. >> >> Ingemar Johansson S wrote: >> >>> Hi Michael. >>> >>> Answer inline below. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: den 22 februari 2008 12:13 >>>> To: Ingemar Johansson S >>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>> >>>> Hi Ingemar, >>>> >>>> Ingemar Johansson S wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> See inline >>>>> >>>>> /Ingemar >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>>> Sent: den 22 februari 2008 10:13 >>>>>> To: Ingemar Johansson S >>>>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>>>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Hi Ingemar, >>>>>> >>>>>> this solution essentially spends a DSCP to save >>>>>> >> 11-marking through >> >>>>>> the PCN domain and allow them to be PCN-marked. This is a >>>>>> >>>>>> >>>> rather high >>>> >>>> >>>>>> price, in particular because the PCN packets need to be >>>>>> >>>>>> >>>> remarked to >>>> >>>> >>>>>> 00. This has the consequence that ECN capability is lost >>>>>> >>>>>> >>>> for the rest >>>> >>>> >>>>>> of the path. >>>>>> >>>>>> >>>>>> >>>>> Not sure that I agree, yes the ECT(0), ECT(1) codepoints >>>>> >>>>> >>>> are lost and >>>> >>>> >>>>> there goes also the ECN nonce and the "inband" ECN >>>>> >>>>> >>>> capability signaling. >>>> >>>> >>>>> A router outside the PCN domain wont be able to set ECN-CE. >>>>> >>>>> >>>> However if >>>> >>>> >>>>> the ECN capability is negotiated out of band for the wireless >>>>> endpoints and the up and downlink wireless nodes, these >>>>> >>>>> >>>> will be ECN-CE >>>> >>>> >>>>> capable but without the nonce capability. >>>>> >>>>> >>>>> >>>> The difficulty is that the information for each packet >>>> whether 10 or 01 must be kept, that says RFC4774: >>>> >>>> Similarly, if a packet that *could* be using default >>>> semantics is marked with the ECN codepoint "01", then this >>>> codepoint >>>> should not be changed to "10" in the network (and a >>>> >> "10" codepoint >> >>>> should not be changed to "01"). This requirement is >>>> >> necessary to >> >>>> avoid interference with the transport protocol's use of >>>> the ECN nonce >>>> [RFC3540]. >>>> >>>> This would require a per packet signalling ... >>>> >>>> >>> Not 100% convinced here, ECN codepoints "01" and "10" can >>> >> be reset to >> >>> "00", that is my interpretation of 4.3 in RFC4774. >>> What might be seen as odd is perhaps that after PCN egress the ECN >>> pattern using this trick will only use the code points "00" or "11" >>> instead of the normal "01", "10" and "11" (if ECN capable). >>> Routers located after PCN egress won't be able to set ECN >>> >> "11" as the >> >>> flow is not anymore regarded as ECN capable (on IP level). Wireless >>> nodes such as LTE-eNB can however be instructed to set ECN >>> >> "11" during >> >>> congestion as this then controlled using out of band >>> >> signaling, this out >> >>> of band signaling is in turn controlled by policy rules >>> >> that will limit >> >>> the risk for cheating. >>> Note that this is meant for realtime traffic and a means to >>> >> do efficient >> >>> adaptation in a wireless enviroment where the transmission >>> >> capacity for >> >>> a single user changes changes dynamically due to physical >>> >> factors such >> >>> as shadowing et.c. >>> >>> >> Ok, I see. I think this is a solution not standardized by the >> IETF and >> can be done for any encoding scheme. If not, what's its >> requirement on >> the encoding? >> >> Regards, >> >> Michael >> >> >> >> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>> Therefore, I opt for one of the two versions >>>>>> 1) discard 11-marked PCN packets before entering the PCN >>>>>> >> domain OR >> >>>>>> 2) let them go through the PCN domain, take them into >>>>>> >> account for >> >>>>>> metering, but do not remark them. >>>>>> The first option loses ECN capability for PCN traffic, >>>>>> >> the second >> >>>>>> option keeps it on the subpath before entering the PCN domain. >>>>>> >>>>>> >>>>>> >>>>> Not sure I follow here. What would option 2 look like? >>>>> My interpretation: Packets with DSCP=EF enters the PCN domain, at >>>>> ingress they are remarked as DSCP=PCN unless ECN="11", in >>>>> >>>>> >>>> which case >>>> >>>> >>>>> DSCP=EF. What about ECN="01" or "01" will these also be kept as >>>>> DSCP=EF or will the ECN bits be set to "00". >>>>> Please explain. >>>>> >>>>> >>>>> >>>> EF DSCP is remarked to PCN in any case. >>>> 1) 11-marked PCN packets are dropped by the PCN ingress >>>> 2) 11 is kept as is >>>> and 01/10 marking is reset to 00 (no-precongestion). The PCN >>>> egress node resets 10/01 marked packets to 00. Therefore, the >>>> ECN capability for PCN traffic is lost >>>> 1) completely >>>> 2) for the partial downstream path starting with the PCN >>>> >> ingress node. >> >>>> It's true that PCN marking can get problems if the majority >>>> of PCN packets was CE-marked when entering the PCN domain. >>>> This kind of traffic also cheats ECN when it doesn't back >>>> off. I just want to say: even TCP senders and receivers can >>>> cheat, do we care? The question is what's more >>>> important: remaining ECN functionality for the partial path >>>> up to the PCN ingress node or safety against too many >>>> 11-marked packets. I see these options (1 and 2) and have no >>>> particular preference. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>>> Ingemar Johansson S wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Answers inline >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >>>>>>>> Sent: den 21 februari 2008 15:34 >>>>>>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; >>>>>>>> philip.eardley@bt.com >>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>>> menth@informatik.uni-wuerzburg.de >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>> >>>>>>>> Hi Ingemar, >>>>>>>> >>>>>>>> This is exactly the sort of thing Phil and I were hoping >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> to trigger >>>>>> >>>>>> >>>>>> >>>>>>>> people to write in response to our email. We are hoping to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> settle on >>>>>> >>>>>> >>>>>> >>>>>>>> what are the real options people support for the >>>>>>>> >>>>>>>> >>>> encoding and why >>>> >>>> >>>>>>>> they support them... >>>>>>>> >>>>>>>> Just one quick observation - if we have to leave 11 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> unchanged across >>>>>> >>>>>> >>>>>> >>>>>>>> the PCN domain this will mean that such packets can't be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> PCN marked >>>>>> >>>>>> >>>>>> >>>>>>>> and thus they should not form part of any PCN aggregate (in my >>>>>>>> opinion)... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Realized that this is one (big) problem, thanks for >>>>>>> >>>>>>> >>>>>>> >>>>>> pointing out this >>>>>> >>>>>> >>>>>> >>>>>>> issue. >>>>>>> >>>>>>> The next alternative is then >>>>>>> PCN Meaning ECN DSCP >>>>>>> ============================= >>>>>>> PCN capable 00 PCN 1 >>>>>>> Admission Mark 01 PCN 1 >>>>>>> Termination Mark 10 PCN 1 >>>>>>> >>>>>>> PCN capable+ECN CE 00 PCN 2 >>>>>>> AM+ECN CE 01 PCN 2 >>>>>>> TM+ECN CE 10 PCN 2 >>>>>>> >>>>>>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN >>>>>>> >>>>>>> >>>>>>> >>>>>> egress PCN >>>>>> >>>>>> >>>>>> >>>>>>> 2 is mapped back to the ECN bits as ECN-CE "11". >>>>>>> >>>>>>> AfM can also be included in the schema >>>>>>> >>>>>>> I know this does cost an extra DSCP codepoint and it completely >>>>>>> disregards the leakage issue, also it possible that this >>>>>>> >>>>>>> >>>>>>> >>>>>> alternative >>>>>> >>>>>> >>>>>> >>>>>>> or something similar is given in the PCN encoding draft >>>>>>> >>>>>>> >>>> but I don't >>>> >>>> >>>>>>> think so as this alternative does not preserve the end >>>>>>> >> to end ECN >> >>>>>>> semantics to 100%, rather it assumes that negotiation of >>>>>>> >>>>>>> >>>> the use of >>>> >>>> >>>>>>> ECN is done out of band at session setup. >>>>>>> >>>>>>> /Ingemar >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Toby >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ingemar Johansson S >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>> >>>>>> >>>>>> >>>>>>>>> Sent: 21 February 2008 13:47 >>>>>>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>>>>>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Putting the issues with "leakage" aside (I cannot tell >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> how serious >>>>>> >>>>>> >>>>>> >>>>>>>>> this problem really is). >>>>>>>>> >>>>>>>>> I would prefer to sacrifice the end to end ECN >>>>>>>>> >> semantics for the >> >>>>>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE >>>>>>>>> >>>>>>>>> >>>> codepoint. The >>>> >>>> >>>>>>>>> reason is simply that from a realtime communication >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> scenario with out >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> of band signaling it is always possible to negotiate the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> use of ECN CE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> mark in wireless nodes by means of eg. SIP signaling. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> Also, atleast >>>>>> >>>>>> >>>>>> >>>>>>>>> for RTP/UDP I see little use for ECN nonce like it is done >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> with TCP as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> this is more or less an anti-cheat feature. >>>>>>>>> >>>>>>>>> >>>>>>>>> One would then end up with a PCN encoding schema like >>>>>>>>> >> (I beleve >> >>>>>>>>> option 5 in figure 1 in the PCN encoding draft) is >>>>>>>>> >> the closest. >> >>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>> ============================= >>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>> Admission Mark 01 PCN 1 >>>>>>>>> Termination Mark 10 PCN 1 >>>>>>>>> >>>>>>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> set to "00", >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> likewise at PCN egress. ECN CE is however left untouched. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> This has the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> effect that routers will be able to set ECN-CE on packets >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> before they >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> enter the first PCN domain, after exit from the PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> domain routers >>>>>> >>>>>> >>>>>> >>>>>>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>>>>>>>> Wireless nodes >>>>>>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> however set >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ECN CE as this is can be managed by out of band signaling. >>>>>>>>> >>>>>>>>> Besides this I would prefer a solution that maintains >>>>>>>>> >>>>>>>>> >>>> end to end >>>> >>>> >>>>>>>>> semantics regardless of DSCP value. If one consider DCCP we >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> don't know >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> today if it will be a best effort traffic alternatiive or >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> if there >>>>>> >>>>>> >>>>>> >>>>>>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. >>>>>>>>> >>>>>>>>> /Ingemar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>>>>> Sent: den 21 februari 2008 11:07 >>>>>>>>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Phil, Hi all >>>>>>>>>> >>>>>>>>>> In order to make a selection of one single (or two) >>>>>>>>>> >> options, I >> >>>>>>>>>> think that the PCN WG should get the possibility to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> study all the >>>>>> >>>>>> >>>>>> >>>>>>>>>> possible and PCN relevant encoding options. >>>>>>>>>> >>>>>>>>>> In my opinion the goal of the encoding draft is to >>>>>>>>>> >>>>>>>>>> >>>> provide this >>>> >>>> >>>>>>>>>> information to the PCN-WG. >>>>>>>>>> Based on this information the PCN WG can discuss and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> decide which >>>>>> >>>>>> >>>>>> >>>>>>>>>> of the options should be used. >>>>>>>>>> >>>>>>>>>> The below text is copied from the current version of the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> encoding >>>>>> >>>>>> >>>>>> >>>>>>>>>> draft! >>>>>>>>>> Four options are described! >>>>>>>>>> Please note that the encoding draft should list all relevant >>>>>>>>>> options with advantages and disadvantages. >>>>>>>>>> >>>>>>>>>> Phil and Ingemar, if you can add advantages, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> disadvantages to the >>>>>> >>>>>> >>>>>> >>>>>>>>>> ones already mentioned below in Section 3.2.1 and >>>>>>>>>> >> 3.2.2 of the >> >>>>>>>>>> encoding draft, please do. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Georgios >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3.2. Encoding Using DSCP Field >>>>>>>>>> >>>>>>>>>> In this type of encoding and transport method the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> congestion and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> precongestion information is encoded into the 6 DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> bits that are >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> transported in the IP header of the data packets. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> Four possible >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> alternatives can be distinguished, as can be seen in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Figure 3, with >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> details provided by >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> draft-westberg-pcn-load-control-02.txt [4]. >>>>>> >>>>>> >>>>>> >>>>>>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> need three >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> additional DSCP values and Option 10 needs four >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> additional DSCP >>>>>> >>>>>> >>>>>> >>>>>>>>>> values. Note that all additional and experimental DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> values are >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> representing and are associated with the same PHB. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> The 1st, 2nd, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> 3rd, and 4th DSCP values are representing DSCP >>>>>>>>>> >>>>>>>>>> >>>> values that are >>>> >>>> >>>>>>>>>> assigned by IANA as DSCP experimental values, see RFC >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> 2211 [9]. >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> -------------------------------------------------------------- >> >>>>>>>>>> --------- >>>>>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add >>>>>>>>>> >>>>>>>>>> >>>> DSCP 3 Add >>>> >>>> >>>>>>>>>> |DSCP 4 >>>>>>>>>> || >>>>>>>>>> >>>>>>>>>> >> ===========++==========+===========+===========+===========+== >> >>>>>>>>>> =========| >>>>>>>>>> | Option 6 || Not-PCN | PCN | AM/TM | >>>>>>>>>> >> NA | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 7 || Not-PCN | PCN | AM/TM | >>>>>>>>>> >> AfM | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 8 || Not-PCN | PCN | AM | >>>>>>>>>> >> TM | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 9 || Not-PCN | PCN | AM | >>>>>>>>>> >> TM | >> >>>>>>>>>> AfM | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> -------------------------------------------------------------- >> >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Notes: Not-PCN means the packet is not PCN capable. >>>>>>>>>> >>>>>>>>>> Figure 2: Encoding of PCN Information Using >>>>>>>>>> >>>>>>>>>> >>>> DSCP Field >>>> >>>> >>>>>>>>>> 3.2.1. Benefits of Using DSCP Field >>>>>>>>>> >>>>>>>>>> The main benefit of using the DSCP field is that >>>>>>>>>> >> it is not >> >>>>>>>>>> affecting >>>>>>>>>> the end-to-end ECN semantics and therefore the issues >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> and concerns >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> raised in RFC 4774 [22] are not applicable for this >>>>>>>>>> >>>>>>>>>> >>>> encoding >>>> >>>> >>>>>>>>>> scheme. >>>>>>>>>> Another benefit is related to the fact that all 4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> DSCP encoding >>>>>> >>>>>> >>>>>> >>>>>>>>>> options depicted in Figure 2 can support the PCN >>>>>>>>>> >> capable not >> >>>>>>>>>> congested (PCN) indication, the admission control >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> (AM) and flow >>>>>> >>>>>> >>>>>> >>>>>>>>>> termination (TM) encoding states. In addition Option 8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> and 10 can >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> support the ECMP solution. >>>>>>>>>> >>>>>>>>>> 3.2.2. Drawbacks of Using DSCP Field >>>>>>>>>> >>>>>>>>>> This type of encoding needs to use per PHB, in >>>>>>>>>> >>>>>>>>>> >>>> addition to the >>>> >>>> >>>>>>>>>> original DSCP and depending on the encoding option used, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> one, two, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> three, or four DSCP values, respectively. These >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> additional DSCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> values can be taken from the DSCP values that are not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> defined by >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> standards action, see RFC 2211 [9]. Note that all the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> additional >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> DSCP values are representing and are associated with one >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> PHB. The >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> value of this DSCP/PHB can either follow a standards >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> action or >>>>>> >>>>>> >>>>>> >>>>>>>>>> use a >>>>>>>>>> value that is applied for experimental or local >>>>>>>>>> >> use. It is >> >>>>>>>>>> important >>>>>>>>>> to note that the number of the DSCP values used >>>>>>>>>> >> for local or >> >>>>>>>>>> experimental use is restricted and therefore the >>>>>>>>>> >> number of >> >>>>>>>>>> different >>>>>>>>>> PHBs supported in the PCN domain will also be restricted. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Georgios >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Behalf Of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> philip.eardley@bt.com >>>>>>>>>>> Sent: donderdag 21 februari 2008 10:24 >>>>>>>>>>> To: ingemar.s.johansson@ericsson.com; >>>>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>>> >>>>>>>>>>> Ingemar >>>>>>>>>>> >>>>>>>>>>> Re >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> consider the end to end ECN usecases >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I believe that the emails below about Toby's encoding >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> proposal do >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> indeed already consider ECN. Would appreciate it if you >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> could add >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> further text to it to better capture the (pros and) cons. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> more DSCP codepoints >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I think you may be proposing an encoding that uses all dscp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> codepoints >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (as has Georgios). That's fine - but a "1 pager" >>>>>>>>>>> setting out this option with its pros and cons (ie >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> similar to what >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> toby has done below) is needed I think! At the moment we >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> have lots of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> options on the table - in order to reach a decision, I >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> think we really >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> need very few options but with their pros and cons better >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> laid out. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> I haven't managed to get to your draft yet, sorry (next week >>>>>>>>>>> hopefully) >>>>>>>>>>> - >>>>>>>>>>> Thanks >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Ingemar Johansson S >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Sent: 21 February 2008 06:43 >>>>>>>>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> menth@informatik.uni-wuerzburg.de; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> Moncaster,T,Toby,CXR9 R >>>>>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> In this discussion it may be well worth the effort to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> consider the end >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to end ECN usecases that we foresee when considering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> various PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> encoding options. >>>>>>>>>>>> Please have a look at >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> for a discussion of the use cases and a motivation to why >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> end to end >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ECN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> should be maintained even across PCN nodes even for non >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> DF traffic. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> That said I realize that there is some cost associated to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the use of >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> DSCP codepoints, this cost must however be weighted against >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the risk >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> that other functionality like end to end ECN semantics is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> probably >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> bits. It is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> easy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to see that if one wish to maintain support for end to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> end ECN (not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> only >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>>>>>>>> I am not explicitly saying don't do this or that but I wish >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> to avoid a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> situation where one technique has to be avoided in favor of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the other >>>>>>>>>>> as >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> it may in the end prevent deployment of both. If one can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> yank the two >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> together so much the better even though the cost e.g in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> DSCP code >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> points >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> is regarded as higher. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Ingemar >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> On Behalf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Of philip.eardley@bt.com >>>>>>>>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>>>>>>>> To: menth@informatik.uni-wuerzburg.de; >>>>>>>>>>>>> >> toby.moncaster@bt.com >> >>>>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks Michael >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with you that spending one DSCP value is quite >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> expensive >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> of really >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> assessing this properly is for an alternative proposal >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> (with pros >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> and cons) that requires only one DSCP. >>>>>>>>>>>>> Then we can see where the consensus for the best >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> (/least bad) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> or against >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> definitely >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> the way to go, until compared it in detail with other >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> proposals. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> So I think it would be really useful to have a "1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> pager" for >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> alternative >>>>>>>>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Philadelphia >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> discussions more productive. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You're correct about one of the motivations >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> (advantages) for this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> proposal (although I don't think the issues are exactly >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> the same for >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 11 leakage as 01/10 leakage). >>>>>>>>>>>>> >>>>>>>>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> domain. If the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> down (seems >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> reasonable). If they're not capable, then the impact >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> outside the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> domain isn't any different to what would happen without >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> PCN-domain. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>>>>>>>> Then this will lead to either flow admission or >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> termination in the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> (I believe) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> at least as severe as would happen in an all ECN world. >>>>>>>>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>>>>>>>> specifically (some other flow might get >>>>>>>>>>>>> >> terminated instead). >> >>>>>>>>>>>>> I think this is true, though it also implies that [1] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> end-to-end ECN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> mechanism (eg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> PCN-domain >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> has also failed, [3] the flows which are terminated >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> aren't other >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>>>>>>>> misconfiguration. >>>>>>>>>>>>> >>>>>>>>>>>>> Best wishes >>>>>>>>>>>>> Phil >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Michael Menth >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> [mailto:menth@informatik.uni-wuerzburg.de] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> khchan@nortel.com; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> steven.blake@ericsson.com; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Toby, >>>>>>>>>>>>>> >>>>>>>>>>>>>> as I understand the proposal, the motivation is to >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> avoid 01/10 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> network since >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 01/10 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> However, there is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> may not be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> dropped >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> by >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> are not ECN >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> capable. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> guaranteed that >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> exactly the marked flow going over an overloaded >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> ECN node is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> terminated. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Just want to say that this solution wants to solve a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> problem that >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> exists >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> does not fully >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> spending two DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> values >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> is quite expensive. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael >>>>>>>>>>>>>> >>>>>>>>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> and feel we >>>>>>>>>>>>> may >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> lots of pros >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> few >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> proposal I will go >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> through the simplified version without Affected >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> marking first: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> the same PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> behaviour >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> aggregate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Pros: >>>>>>>>>>>>>>> o Termination marking and admission marking are >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> independent, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> eg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> termination marking can be done after a packet has been >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> admission >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> having to read >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> implement. (Note: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> 3SM & CL, see >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> ECT(1). This is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> region, due to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> some >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> fort >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> for a single >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> domain deployment of PCN). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> ECT(1) in some >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> simply reads its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > > >>>>>>>>>>>>> DSCP. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> This is probably easier than checking both its >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> DSCP & ECN >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> fields. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> could deploy SM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> DSCP. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> too horrific >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>> [2] could just deploy admission control & add >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> termination later, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> just by >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> encoding and check >>>>>>>>>>>>> for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cons: >>>>>>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> (Although >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> all PCN BAs?) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> egress with >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> its ECN = >>>>>>>>>>>>> 11 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> and it really is required to preserve this info >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> across the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> PCN-domain, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> (tunnelling) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> (ECMP) that uses >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> of packets >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> within >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> they know of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> an >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> ECMP >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> mis-ordering >>>>>>>>>>>>> when >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> there is termination marking may be acceptable >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> modified as >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> the above. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> However >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> there >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> affected >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> marked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> reset the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> be needed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> to see if >>>>>>>>>>>>> this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> skews the results and causes significant >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> over-termination or >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> not. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> Please could people look through this scheme and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> highlight any >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> additional concerns that they may have (and extra >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> benefits too). >>>>>>>>>>> I >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> would >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> like to get as many opinions as possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> "why not try >>>>>>>>>>>>> this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> possible >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> schemes on the table and people need to start putting >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> down much >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> clearer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> pros and cons for the schemes they support... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> So it could >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> be good to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> have a similar "one page" email about a specific >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> scheme that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> only >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> uses >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Toby >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> ____________________________________________________________________ >> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> Toby Moncaster, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> Networks Research >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> Centre, BT >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> 1473 648734 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 >>>>>>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> PCN mailing list >>>>>>>>>>> PCN@ietf.org >>>>>>>>>>> http://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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> >> -- >> 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 >> >> >> -- 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 10:07:36 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764AF28C402; Fri, 22 Feb 2008 10:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 EMsFxP8RT2wX; Fri, 22 Feb 2008 10:07:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618A928C408; Fri, 22 Feb 2008 10:06:45 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4383A6806 for ; Fri, 22 Feb 2008 10:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxhbpKyfdawx for ; Fri, 22 Feb 2008 10:06:42 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 79B1228CAF3 for ; Fri, 22 Feb 2008 10:04:14 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 18:04:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 18:04:09 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C2@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1203694150.3476.2.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7clBGqQEI/cQd22a5iHcP4BywAFDB1w From: To: , X-OriginalArrivalTime: 22 Feb 2008 18:04:09.0835 (UTC) FILETIME=[52AADBB0:01C8757D] Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Not sure if I'm allowed to comment, since I edited it, but if I am then I believe it's ready for WGLC! Best wishes, Phil Ps to save you having to read it all again! * Diffs from -02 version http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- architecture-03-from-02.diff.html * a detailed list of changes is in S14.1 (there aren't many) http://tools.ietf.org/html/draft-ietf-pcn-architecture-03#section-14.1 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 22 February 2008 15:29 > To: pcn > Subject: [PCN] draft-ietf-pcn-architecture-03 > > The chairs would like input on whether the working group has read > draft-ietf-pcn-architecture-03, and believes that it is ready for > working group last call. Please send your comments to this list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 10:14:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4F33A67F3; Fri, 22 Feb 2008 10:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-2.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_73=0.6, MANGLED_TOOL=2.3, 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 NehHjqT8CmxZ; Fri, 22 Feb 2008 10:14:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF5E3A6808; Fri, 22 Feb 2008 10:14:04 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DFB3A67F3 for ; Fri, 22 Feb 2008 10:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzBghHRJz9Vo for ; Fri, 22 Feb 2008 10:13:58 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 288093A6808 for ; Fri, 22 Feb 2008 10:13:58 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 18:13:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 18:13:52 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C3@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47BEAAE9.5040802@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: Ach1Qh+xO+q0EiygQbGwezIKlZvXPwAN+R4Q From: To: , X-OriginalArrivalTime: 22 Feb 2008 18:13:53.0580 (UTC) FILETIME=[AE9B46C0:01C8757E] Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: Re: [PCN] FW: RE: PCN encoding option 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org 3 replies below to snippets from this thread phil > > resetting 01- and 10-marked packets to 00-marking does not conflict with > RFC4774, only interchanging them is bad: don't agree. Swapping 01 & 10 breaks the ecn nonce. But setting ect [10 or 01] to 00 turns off ECN 3168. since 3168 is a STD, this is a problem. > > A requirement for compatibility with end-nodes using default ECN is > that if a packet that *could* be using default semantics is marked > with the ECN codepoint "00", this marking must not be changed to > "01", "10", or "11" in the network. This prevents the packet from > being represented incorrectly to a default-ECN router downstream as > ECN-Capable. Similarly, if a packet that *could* be using default > semantics is marked with the ECN codepoint "01", then this codepoint > should not be changed to "10" in the network (and a "10" codepoint > should not be changed to "01"). This requirement is necessary to > avoid interference with the transport protocol's use of the ECN nonce > [RFC3540]. > > Regards, > > Michael > ---- Ingemar said: > Routers located after PCN egress won't be able to set ECN "11" as the > flow is not anymore regarded as ECN capable (on IP level). Wireless > nodes such as LTE-eNB can however be instructed to set ECN "11" during > congestion as this then controlled using out of band signaling, this out > of band signaling is in turn controlled by policy rules that will limit > the risk for cheating. > Note that this is meant for realtime traffic and a means to do efficient > adaptation in a wireless enviroment where the transmission capacity for > a single user changes changes dynamically due to physical factors such > as shadowing et.c. think the talk about future uses of ECN by wireless users is a bit speculative. Worrying about things that are ietf stds already is hard enough! ----- Elsewhere Ingemar also said: > The next alternative is then > PCN Meaning ECN DSCP > ============================= > PCN capable 00 PCN 1 > Admission Mark 01 PCN 1 > Termination Mark 10 PCN 1 > > PCN capable+ECN CE 00 PCN 2 > AM+ECN CE 01 PCN 2 > TM+ECN CE 10 PCN 2 > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN egress PCN 2 > is mapped back to the ECN bits as ECN-CE "11". > > AfM can also be included in the schema this could be directly compared with toby's scheme, in that they both use ECN & 2 DSCPs. So I copied in the pros and cons that toby claims for his scheme, & added some remarks below to compare with your idea > Pros: > o Termination marking and admission marking are independent, eg > termination marking can be done after a packet has been admission marked. > Therefore a router can write AM or TM without having to read the packet's > PCN marking first, which is easier to implement. (Note: Over-writing a TM > with AM is not allowed for 3SM & CL, see draft-charny-pcn-comparison.) your scheme doesn't have this pro > > o This scheme avoids giving semantics to ECT(0) and ECT(1). This is > safest option if packets leak outside the PCN region, due to some fort of > misconfiguration of the PCN-boundary-nodes (relevant for a single domain > deployment of PCN). see issue above about loss of 3168 semantics. > > o It leaves open the possibility of using ECT(0) and ECT(1) in some > mysterious way in a future end-to-end PCN deployment > > o For a router to classify a packet as PCN, it simply reads its DSCP. > This is probably easier than checking both its DSCP & ECN fields. > > o Incremental deployment steps are possible > [1] could deploy SM initially and later AM/TM. Just add the second DSCP. > If a router isn't upgraded at the same time nothing too horrific happens. > [2] could just deploy admission control & add termination later, just by > adding a new DSCP; there is no need to change the encoding and check for > backwards compatibility? Vice-versa is also ok? This pro is lost > > Cons: > o It needs an extra DSCP, per PCN behaviour aggregate. (Although possibly > it's OK to use the same DSCP for TM for all PCN BAs?) > > o If a packet (in a PCN flow) arrives at the egress with its ECN = 11 and > it really is required to preserve this info across the PCN-domain, then > some complexity is needed at the PCN-boundary-nodes (tunnelling) you're trying to avoid this con, which is a noble aim & would be nice if succeed, although I don't think you've managed it > > o If the PCN-domain is operating multipath routing (ECMP) that uses the > DSCP to select routes, then there may be mis-ordering of packets within a > flow. This may be OK as (1) no-one has yet said they know of an ECMP > algorithm that in practie uses the DSCP; (2) a risk of mis-ordering when > there is termination marking may be acceptable point (2) doesn't hold for your scheme _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 22 11:08:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D571028C426; Fri, 22 Feb 2008 11:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-2.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Qxv37O-5uEN5; Fri, 22 Feb 2008 11:08:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C357B3A6B08; Fri, 22 Feb 2008 11:08:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B35D28C199 for ; Fri, 22 Feb 2008 11:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75fG3cxM4HW7 for ; Fri, 22 Feb 2008 11:08:49 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6478228C3B3 for ; Fri, 22 Feb 2008 11:08:49 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1MJ8gL08126 for ; Fri, 22 Feb 2008 19:08:43 GMT Received: from KCHAN-2K3.nortel.com ([47.130.81.209] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 14:08:20 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Feb 2008 14:08:18 -0500 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 22 Feb 2008 19:08:20.0305 (UTC) FILETIME=[49B9F410:01C87586] Subject: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all: Following up on Toby's E-Mail, I would like to bring out the possible choices for usage of '01' and '10' bit patterns (of the 2 bit ECN field in the IP Header) for PCN. For ECN: '01' = ECT(1), '10' = ECT(0). Meaning Not Congested, and ECN Capable Transport, and ECN nonce usage. Toby's encoding suggest the NOT using of '01' and '10'. It is a good suggestion if we have more bits to use. But we don't, and the use of additional DSCPs have other affects and trade-offs. Alternative is to use both '01' and '10' to indicate the packet is PCN capable (in another words belong to a PCN capable flow). The benefit of using '01' and '10' is allowing it to be used for PCN purpose. We have agreed to use a DSCP to indicate PCN Capable packets (flows), hence the PCN Capable notion (encoding state) is taken care of. We still need to represent Not Pre-Congested notion (encoding state). IMHO, the '01' and '10' bit patterns are good choices for encoding the Not Pre-Congested encoding state. Lets visit the benefits of such use: 1. Allow the representation of a PCN encoding state using ECN bits. Minimizing the use of additional DSCPs. 2. If a PCN '01' or '10' encoded packet receives ECN router treatment: The ECN router will not change the encoding if it does not experience congestion. The ECN router will change the encoding to '11' (CE) if it experienced congestion, trusting the offered load to the congestion point will be reduced. If a PCN Edge Node receives the '11' encoding and if we choose it to mean Termination, then the offered load to the congestion point will be reduced. PCN terminates the flow, hence this should be ECN (at least ECN when used for TCP) friendly. Detailed discussions of how friendly should be an algorithm matter and will need to involve algorithm comparisons with ECN. If an ECN End Node receives the '11' encoding, it will mean interpret it as CE and will reduce the offered load as describe by RFC 3168. How friendly is this ECN flow to the PCN domain is a discussion of algorithms and will have to make assumptions of using ECN for TCP and which PCN algorithm. The how friendly discussions should be part of the algorithm discussions. 3. When ECN packets pass through PCN Interior Nodes with no Pre-Congestions, no affects to ECN and PCN. This includes ECN packets using ECN nonce. 4. When PCN packets pass through ECN routers with no Congestions, no affects to ECN and PCN. 5. If we don't have to worry about ECN nonce passing through PCN nodes, we can use one of the two bit patterns for another PCN encoding state. Point # 2 above discusses: 1. ECN packets entering PCN domain and then leaving the PCN domain back into ECN routers and endpoints. 2. PCN packets leaving the PCN domain and encounters ECN routers and PCN endpoints. Does it make sense to talk about PCN packets encountering ECN (TCP) endpoints? If the ECN endpoint handles this PCN packet, then it should reduce the flows offered load, the functionality PCN Interior Nodes expects. Based on the assumption of using PCN DSCP to separate PCN traffic and non PCN traffic: - When we talk about ECN packet entering PCN domain, we mean somehow the ECN packet uses the PCN DSCP. There are DiffServ methods to prevent this. - When we talk about PCN packet leaving PCN domain, we mean somehow the PCN packet encounters routers that does not understand the PCN DSCP and interpret the PCN encoding differently. The bad part of such use: 1. Making the PCN algorithms to handle how friendly they are with ECN algorithm. Please notice the information provided above are in: http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt I am adding the details of Toby's suggestions to the -03 of the draft. Please let us know if there are points or concerns not addressed. Thanks! Sorry that I have been sick with the flu (fever, aches, cough, etc) the past few days. Just got below 100 degree temperature with my fever this morning. -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Feb 23 03:48:42 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC53A3A6BAA; Sat, 23 Feb 2008 03:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.619 X-Spam-Level: * X-Spam-Status: No, score=1.619 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, 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 0ME6Z-k7g8g4; Sat, 23 Feb 2008 03:48:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EC93A69A6; Sat, 23 Feb 2008 03:48:35 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B523A69CA for ; Sat, 23 Feb 2008 03:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsltrACpWCcZ for ; Sat, 23 Feb 2008 03:48:32 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C54513A6A2C for ; Sat, 23 Feb 2008 03:47:17 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 04551198DE4; Sat, 23 Feb 2008 12:47:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EAB99198DE3; Sat, 23 Feb 2008 12:47:11 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5F5E0198DE0; Sat, 23 Feb 2008 12:47:06 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1NBl6V23395; Sat, 23 Feb 2008 12:47:06 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 8CDBBC8785; Sat, 23 Feb 2008 12:47:05 +0100 (CET) Message-ID: <47C0077D.202@informatik.uni-wuerzburg.de> Date: Sat, 23 Feb 2008 12:46:05 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C3@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C3@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, bob.briscoe@bt.com Subject: [PCN] Resetting ECT to non-ECT 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, >> resetting 01- and 10-marked packets to 00-marking does not conflict >> > with > >> RFC4774, only interchanging them is bad: >> > > don't agree. Swapping 01 & 10 breaks the ecn nonce. But setting ect [10 > or 01] to 00 turns off ECN 3168. since 3168 is a STD, this is a problem. > Yes, this turns off 3168, but why is that bad? I don't see that rfc4774 forbids it. Regards, Michael > >> A requirement for compatibility with end-nodes using default ECN is >> that if a packet that *could* be using default semantics is marked >> with the ECN codepoint "00", this marking must not be changed to >> "01", "10", or "11" in the network. This prevents the packet from >> being represented incorrectly to a default-ECN router downstream as >> ECN-Capable. Similarly, if a packet that *could* be using default >> semantics is marked with the ECN codepoint "01", then this >> > codepoint > >> should not be changed to "10" in the network (and a "10" codepoint >> should not be changed to "01"). This requirement is necessary to >> avoid interference with the transport protocol's use of the ECN >> > nonce > >> [RFC3540]. >> >> 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Feb 23 16:24:40 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407ED3A6BA2; Sat, 23 Feb 2008 16:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 NkkrZ4sJNq+6; Sat, 23 Feb 2008 16:24:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B9C3A6BAC; Sat, 23 Feb 2008 16:24:39 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E8E3A6B65 for ; Sat, 23 Feb 2008 16:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T13nDpn3N5Vf for ; Sat, 23 Feb 2008 16:24:37 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 38EDB3A6BA4 for ; Sat, 23 Feb 2008 16:24:36 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8CCA5198DE4; Sun, 24 Feb 2008 01:24:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7E8FA198DE1; Sun, 24 Feb 2008 01:24:31 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9F9AB198DDA; Sun, 24 Feb 2008 01:24:24 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1O0OOV28258; Sun, 24 Feb 2008 01:24:24 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 1743AC8785; Sun, 24 Feb 2008 01:24:23 +0100 (CET) Message-ID: <47C0B8FD.3090208@informatik.uni-wuerzburg.de> Date: Sun, 24 Feb 2008 01:23:25 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn , Frank Lehrieder , Jozef Babiarz , Philip Eardley , Anna Charny X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] Edge-Assisted Marked Flow Termination (EMFT) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, there is a new Internet draft on edge-assisted marked flow termination (EMFT) which terminates only marked flows but uses excess marking in the core. The PCN edge nodes have an algorithm that avoids overtermination when configured appropriately. http://www.ietf.org/internet-drafts/draft-menth-pcn-emft-00.txt In the 3sm draft http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt we have described core-assisted marked flow termination (CMFT). This name is new and not yet in the -01 version of that document, but the mechanism is the same. CMFT also terminates only marked flows but uses marking frequency reduction in the core to avoid overtermination. EMFT is the product of the fact that excess marking seems favorable since this marking behavior is already available and the insight that marked flow termination is favorable as it can deal with multipath routing such as ECMP. We have compared the termination behavior of EMFT and CMFT in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf Apart from that, this document also discusses end-to-end PCN-based admission control and flow termination and discusses requirements for PCN encoding to keep the door open for end-to-end PCN. Comments are welcome. 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 02:11:13 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C6B28C418; Mon, 25 Feb 2008 02:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Xe5Uk8qmH4om; Mon, 25 Feb 2008 02:11:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B5928C422; Mon, 25 Feb 2008 02:10:42 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6E728C35E for ; Mon, 25 Feb 2008 02:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Du7Oi7X8Ls for ; Mon, 25 Feb 2008 02:10:39 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 28F2928C555 for ; Mon, 25 Feb 2008 02:08:35 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 10:08:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 10:08:27 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding Option: '01' & '10' Encoding Thread-Index: Ach1hmVhN7LFW5NATHuciZvuOS3PWgCCfqfQ From: To: , X-OriginalArrivalTime: 25 Feb 2008 10:08:28.0438 (UTC) FILETIME=[5DE88B60:01C87796] Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Kwok Just wanted to clarify what your proposal is. I think it's: PCN Meaning ECN DSCP Admission Mark 00 PCN 1 PCN-capable 01 PCN 1 PCN-capable 10 PCN 1 Termination Mark 11 PCN 1 I think something like this is an option worth considering. Are these the pros & cons? Pros: o It only needs one DSCP, per PCN behaviour aggregate. In normal circumstances where the PCN-domain is configured correctly, then PCN-traffic is distinguished from non-PCN traffic by use of this DSCP. o For a router to classify a packet as PCN, it simply reads its DSCP. This is probably easier than checking both its DSCP & ECN fields. Unclear: o If the PCN-boundary-nodes are misconfigured so that PCN packets can sneak out of the PCN-domain, or non PCN-packets can sneak in, then it needs more analysis. (Kwok, your scheme is quite good from this point of view. '00' sneaking out?) Cons o Termination marking and admission marking are not independent - before a router writes TM is must check that the packet isn't already admission marked. (Note: Over-writing a TM with AM is not allowed for 3SM & CL, see draft-charny-pcn-comparison.) o It needs an extra DSCP, per PCN behaviour aggregate. o If a packet (in a PCN flow) arrives at the egress with its ECN = 01, 10 or 11 and it really is required to preserve this info across the PCN-domain, then some complexity is needed at the PCN-boundary-nodes (tunnelling) Hope you're de-fevered! phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Kwok-Ho Chan > Sent: 22 February 2008 19:08 > To: pcn@ietf.org > Subject: [PCN] Encoding Option: '01' & '10' Encoding > > Hi all: > Following up on Toby's E-Mail, I would like to bring out the possible > choices for > usage of '01' and '10' bit patterns (of the 2 bit ECN field in the IP > Header) for PCN. > > For ECN: '01' = ECT(1), '10' = ECT(0). Meaning Not Congested, and ECN > Capable > Transport, and ECN nonce usage. > > Toby's encoding suggest the NOT using of '01' and '10'. > It is a good suggestion if we have more bits to use. But we don't, and > the use > of additional DSCPs have other affects and trade-offs. > > Alternative is to use both '01' and '10' to indicate the packet is PCN > capable > (in another words belong to a PCN capable flow). > > The benefit of using '01' and '10' is allowing it to be used for PCN > purpose. > > We have agreed to use a DSCP to indicate PCN Capable packets (flows), > hence the PCN Capable notion (encoding state) is taken care of. > > We still need to represent Not Pre-Congested notion (encoding state). > IMHO, the '01' and '10' bit patterns are good choices for encoding the > Not Pre-Congested encoding state. > > Lets visit the benefits of such use: > 1. Allow the representation of a PCN encoding state using ECN bits. > Minimizing the use of additional DSCPs. > > 2. If a PCN '01' or '10' encoded packet receives ECN router treatment: > The ECN router will not change the encoding if it does not experience > congestion. > The ECN router will change the encoding to '11' (CE) if it > experienced > congestion, trusting the offered load to the congestion point > will be reduced. > If a PCN Edge Node receives the '11' encoding and if we choose it to > mean > Termination, then the offered load to the congestion point will > be reduced. > PCN terminates the flow, hence this should be ECN (at least ECN when > used for TCP) friendly. Detailed discussions of how friendly should > be > an algorithm matter and will need to involve algorithm > comparisons with ECN. > If an ECN End Node receives the '11' encoding, it will mean interpret > it > as CE and will reduce the offered load as describe by RFC 3168. > How friendly is this ECN flow to the PCN domain is a discussion > of algorithms > and will have to make assumptions of using ECN for TCP and which > PCN algorithm. > The how friendly discussions should be part of the algorithm > discussions. > > 3. When ECN packets pass through PCN Interior Nodes with no Pre- > Congestions, > no affects to ECN and PCN. This includes ECN packets using ECN > nonce. > > 4. When PCN packets pass through ECN routers with no Congestions, > no affects to ECN and PCN. > > 5. If we don't have to worry about ECN nonce passing through PCN nodes, > we can use one of the two bit patterns for another PCN encoding > state. > > Point # 2 above discusses: > 1. ECN packets entering PCN domain and then leaving the PCN domain > back into ECN routers and endpoints. > 2. PCN packets leaving the PCN domain and encounters ECN routers and > PCN endpoints. Does it make sense to talk about PCN packets > encountering > ECN (TCP) endpoints? If the ECN endpoint handles this PCN packet, > then > it should reduce the flows offered load, the functionality PCN > Interior Nodes expects. > > Based on the assumption of using PCN DSCP to separate PCN traffic and > non PCN traffic: > - When we talk about ECN packet entering PCN domain, we mean somehow > the ECN packet uses the PCN DSCP. There are DiffServ methods to > prevent this. > - When we talk about PCN packet leaving PCN domain, we mean somehow > the PCN packet encounters routers that does not understand the PCN DSCP > and interpret the PCN encoding differently. > > The bad part of such use: > 1. Making the PCN algorithms to handle how friendly they are with ECN > algorithm. > > Please notice the information provided above are in: > http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison- > 02.txt > > I am adding the details of Toby's suggestions to the -03 of the draft. > > Please let us know if there are points or concerns not addressed. > Thanks! > > Sorry that I have been sick with the flu (fever, aches, cough, etc) > the past few days. > Just got below 100 degree temperature with my fever this morning. > > -- Kwok -- > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 02:35:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A76428C410; Mon, 25 Feb 2008 02:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.386 X-Spam-Level: X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 KKeHTDXUHTb9; Mon, 25 Feb 2008 02:35:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742393A6CDD; Mon, 25 Feb 2008 02:34:42 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8CE3A6CB5 for ; Mon, 25 Feb 2008 02:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPqxq4tKGi+U for ; Mon, 25 Feb 2008 02:34:40 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 5E90528C410 for ; Mon, 25 Feb 2008 02:33:10 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2B6BCA063B for ; Mon, 25 Feb 2008 11:33:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1F732A0613 for ; Mon, 25 Feb 2008 11:33:04 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0CA32A0611 for ; Mon, 25 Feb 2008 11:33:03 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1PAX3V06655 for ; Mon, 25 Feb 2008 11:33:03 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DB95BC866B for ; Mon, 25 Feb 2008 11:33:03 +0100 (CET) Message-ID: <47C29923.30607@informatik.uni-wuerzburg.de> Date: Mon, 25 Feb 2008 11:32:03 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] "blind marking" not a big advantage 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I have seen that some encoding discussions underlined the benefit of "blind marking", i.e. the codepoint can be set without reading the ECN bits before. I just want to point out that this advantage is not so big because the meter needs to know the marking anyway to avoid that termination marked packets are metered. I just copied from the comparison draft http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt |-------------------------------------------------------------------| |Metering and | do not meter | meter all pkts | do not meter | |remarking of | AM-marked | for admission | TM-marked pkts | |previously | packets | and termination;| for termination | |marked | | do not re-mark | meter all pkts;| |packets | | TM-marked pkts | for admission, | | | | | do not re-mark | | | | | TM-marked pkts | |-------------------------------------------------------------------| 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 03:24:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10A23A6C9F; Mon, 25 Feb 2008 03:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.365 X-Spam-Level: X-Spam-Status: No, score=0.365 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 lJEGQpDNg1k9; Mon, 25 Feb 2008 03:24:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94F13A6C0B; Mon, 25 Feb 2008 03:24:22 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28EA3A6C0B for ; Mon, 25 Feb 2008 03:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgxEDm7dddHW for ; Mon, 25 Feb 2008 03:24:20 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id D31D43A67A7 for ; Mon, 25 Feb 2008 03:24:19 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 334BFA064C for ; Mon, 25 Feb 2008 12:24:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 26967A062C for ; Mon, 25 Feb 2008 12:24:14 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 13F37A0613 for ; Mon, 25 Feb 2008 12:24:13 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1PBODV07128; Mon, 25 Feb 2008 12:24:13 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DCDE3C81C4; Mon, 25 Feb 2008 12:24:13 +0100 (CET) Message-ID: <47C2A521.1000007@informatik.uni-wuerzburg.de> Date: Mon, 25 Feb 2008 12:23:13 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn , Frank Lehrieder X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] New draft on PCN performance 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, we updated our performance comparison draft: http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt New are studies on 1) the performance of several admission control (AC) algorithms (probe-based AC, observation-based AC, congestion level estimate based AC) in combination with excess and exhaustive marking. http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-AC.pdf The papers also discusses a two-layer architecture for PCN. 2) the performance of several flow termination (FT) algorithms http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf The paper also discusses the extension of edge-to-edge PCN (single domain) to end-to-end PCN and their coexistence. 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 03:35:08 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D48228C1A2; Mon, 25 Feb 2008 03:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 9+gCeeZJfQtB; Mon, 25 Feb 2008 03:35:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C2F28C40C; Mon, 25 Feb 2008 03:34:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A7528C3FE for ; Mon, 25 Feb 2008 03:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB0lbu4gfjSq for ; Mon, 25 Feb 2008 03:34: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 1241328C501 for ; Mon, 25 Feb 2008 03:33:34 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:33:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 11:33:27 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345CB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47C29923.30607@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "blind marking" not a big advantage Thread-Index: Ach3miultSJPd930ReiDgH1y8JUV6gABvGxw From: To: , X-OriginalArrivalTime: 25 Feb 2008 11:33:28.0896 (UTC) FILETIME=[3E04AC00:01C877A2] Subject: Re: [PCN] "blind marking" not a big advantage 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org In terms of 3SM edge behaviour [the 3rd of the 4 columns below), then termination marked packets are metered. For CL edge behaviour [the 4th of the 4 columns below), then including termination marked packets can lead to over-termination in multiple bottleneck scenarios. Possibly this is a trade-off work making? Ie simpler behaviour for PCN-interior-node for more complexity in edges or more uncertainty in outcome of termination? > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 25 February 2008 10:32 > To: pcn > Subject: [PCN] "blind marking" not a big advantage > > Hi, > > I have seen that some encoding discussions underlined the benefit of > "blind marking", i.e. the codepoint can be set without reading the ECN > bits before. I just want to point out that this advantage is not so big > because the meter needs to know the marking anyway to avoid that > termination marked packets are metered. I just copied from the > comparison draft > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt > > |-------------------------------------------------------------------| > |Metering and | do not meter | meter all pkts | do not meter | > |remarking of | AM-marked | for admission | TM-marked pkts | > |previously | packets | and termination;| for termination | > |marked | | do not re-mark | meter all pkts;| > |packets | | TM-marked pkts | for admission, | > | | | | do not re-mark | > | | | | TM-marked pkts | > |-------------------------------------------------------------------| > > > 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 > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 05:10:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BE328C338; Mon, 25 Feb 2008 05:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 iI4Oe5K0MteI; Mon, 25 Feb 2008 05:10:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D145928C359; Mon, 25 Feb 2008 05:10:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D31A28C1DC for ; Mon, 25 Feb 2008 05:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqJD7jowDGTV for ; Mon, 25 Feb 2008 05:10:42 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 44A2328C556 for ; Mon, 25 Feb 2008 05:08:33 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 796F0198EC3; Mon, 25 Feb 2008 14:08:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6B183198EBF; Mon, 25 Feb 2008 14:08:25 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 36090198EB9; Mon, 25 Feb 2008 14:08:24 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1PD8OV08321; Mon, 25 Feb 2008 14:08:24 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id CEF33C8709; Mon, 25 Feb 2008 14:08:23 +0100 (CET) Message-ID: <47C2BD8B.1030008@informatik.uni-wuerzburg.de> Date: Mon, 25 Feb 2008 14:07:23 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345CB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345CB@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] "blind marking" not a big advantage 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, yes, this issue boils down to the tradeoff implementation complexity vs. overtermination in multiple bottleneck scenarios. I can try to quantify the overtermination in future performance studies. Likewise, it would be good to have input from manufacturers about the complexity increase when going from "blind marking" to "stateful marking". Regards, Michael philip.eardley@bt.com wrote: > In terms of 3SM edge behaviour [the 3rd of the 4 columns below), then > termination marked packets are metered. > > For CL edge behaviour [the 4th of the 4 columns below), then including > termination marked packets can lead to over-termination in multiple > bottleneck scenarios. > Possibly this is a trade-off work making? Ie simpler behaviour for > PCN-interior-node for more complexity in edges or more uncertainty in > outcome of termination? > > > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Michael Menth >> Sent: 25 February 2008 10:32 >> To: pcn >> Subject: [PCN] "blind marking" not a big advantage >> >> Hi, >> >> I have seen that some encoding discussions underlined the benefit of >> "blind marking", i.e. the codepoint can be set without reading the ECN >> bits before. I just want to point out that this advantage is not so >> > big > >> because the meter needs to know the marking anyway to avoid that >> termination marked packets are metered. I just copied from the >> comparison draft >> http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt >> >> >> > |-------------------------------------------------------------------| > >> |Metering and | do not meter | meter all pkts | do not meter >> > | > >> |remarking of | AM-marked | for admission | TM-marked pkts >> > | > >> |previously | packets | and termination;| for termination >> > | > >> |marked | | do not re-mark | meter all >> > pkts;| > >> |packets | | TM-marked pkts | for admission, >> > | > >> | | | | do not re-mark >> > | > >> | | | | TM-marked pkts >> > | > > |-------------------------------------------------------------------| > >> 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 >> http://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 _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 08:14:03 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890F628C55D; Mon, 25 Feb 2008 08:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 t6DPJEWyewwn; Mon, 25 Feb 2008 08:14:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FE328C59C; Mon, 25 Feb 2008 08:12:34 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC4728C556 for ; Mon, 25 Feb 2008 08:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBwhrvsfTjqW for ; Mon, 25 Feb 2008 08:12:18 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id B8E473A6D6D for ; Mon, 25 Feb 2008 08:08:50 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1PG8g217358; Mon, 25 Feb 2008 16:08:42 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.66] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:08:19 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Feb 2008 11:08:18 -0500 To: From: "Kwok-Ho Chan" In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C4@E03MVZ1-UKDY.doma in1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345C4@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Feb 2008 16:08:19.0836 (UTC) FILETIME=[A3626BC0:01C877C8] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil and all: Please see response inline below. Thanks! -- Kwok -- At 05:08 AM 2/25/2008, philip.eardley@bt.com wrote: >Kwok > >Just wanted to clarify what your proposal is. I think it's: > >PCN Meaning ECN DSCP > >Admission Mark 00 PCN 1 >PCN-capable 01 PCN 1 >PCN-capable 10 PCN 1 >Termination Mark 11 PCN 1 Kwok: Want to clarify that the proposal I put forward with my original E-Mail is for the '01' and '10' encoding code points. AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding state. This is different from "PCN-capable" encoding state, which I believe we agree is handled by the use of the PCN DSCP, for example: "PCN 1". That proposal does not restrict if '00' or '11' encoding code points are used for "Admission Marked", or "Termination Marked", or "Affected Marked", or combinations of them. With their choices depending on the number of encoding states needed to be supported, etc. Which can be a separate discussion, decision. But I did used '11' to encode the "Termination Marked" encoding state as an example. And possibly used '00' to encode the "Admission Marked" encoding state as an example. But they are examples, they can be swapped, combined into one encoding code point. And should not affect the use of '01' and '10' code point to mean NOT PRE-CONGESTED encoding state. Using '00' and '11' to represent "Admission Marked" and "Termination Marked" encoding states as an example will match close to what you have indicated. But there are much more write up for Option 1 in http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt with Pros and Cons and with specific RFC 4774 discussions. I hope people will read those sections of the draft and use them as Pros and Cons and provide comments to the draft. I am using the discussions on the list to clarify options 3 and 4 of the draft. IMHO: I believe the use of the term "PCN-capable" is confusing and mis-leading when we really mean "Not Pre-Congested" or "No Pre-Congestion". With the use of any packet using DSCP "PCN 1" means the packet is PCN capable and should be treated using PCN treatment. How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? Notice ECN uses ECT to indicate both "ECN Capable Transport" and "Not Congested". Which we separated into 2 encoding states using 2 encoding code points. >I think something like this is an option worth considering. Are these >the pros & cons? This is currently in: http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt as options 1 and 2 in Figure 1 on page 10. As well as Toby (and your) proposal as options 3 and 4 in Figure 1 on page 10. This write-up is to indicate the differences between the usage of the '01' and '10' code points for options (1 and 2) and (3 and 4). >Pros: Kwok: Please notice this is only a summary of the Pros, please read the draft for details. >o It only needs one DSCP, per PCN behaviour aggregate. In normal >circumstances where the PCN-domain is configured correctly, then >PCN-traffic is distinguished from non-PCN traffic by use of this DSCP. Kwok: I believe this is indicated by the current PCN charter (at least one interpretation of it). I think it should be one point of discussion to clarify how the current charter should be interpreted. >o For a router to classify a packet as PCN, it simply reads its DSCP. >This is probably easier than checking both its DSCP & ECN fields. Kwok: This also allows easy use of PCN with VPNs. One can even think of a PCN domain being a PCN VPN across a provider network that the provider can sell. And apply strict rules on which packets can use the PCN VPN (for example only real-time traffic that subscribed to the PCN service). And any other traffic just does not get to use the PCN VPN/Domain (for example packets that are non-real-time that can afford the delay/jitter of packet queuing and TCP and drops that may want to use ECN). >Unclear: >o If the PCN-boundary-nodes are misconfigured so that PCN packets can >sneak out of the PCN-domain, or non PCN-packets can sneak in, then it >needs more analysis. >(Kwok, your scheme is quite good from this point of view. '00' sneaking >out?) Kwok: This depends on what encoding state the '00' code point may be used for, or used at all. >Cons > o Termination marking and admission marking are not independent - >before a router writes TM is must check that the packet isn't already >admission marked. (Note: Over-writing a TM with AM is not allowed for >3SM & CL, see draft-charny-pcn-comparison.) Kwok: Again, this depends on how '00' and '11' code points may be used. For the example you provided (similar to draft's Option 1), this may be true. But for draft's Option 2, this may not be true. >o It needs an extra DSCP, per PCN behaviour aggregate. Kwok: Yes, and I believe we are currently thinking of one PCN BA, for real-time traffic. >o If a packet (in a PCN flow) arrives at the egress with its ECN = 01, >10 or 11 and it really is required to preserve this info across the >PCN-domain, then some complexity is needed at the PCN-boundary-nodes >(tunnelling) Kwok: Not totally understanding your point. If the packets arrive without the DSCP=PCN_1, then they are not part of the PCN domain and should not receive PCN treatments. They can receive ECN treatments or any other treatment types, this is out of scope for us. I think we just have to say they are not part of the PCN domain. If DSCP=PCN_1, I think there are 2 cases, 1. a packet arriving at an PCN Ingress Node with DSCP=PCN_1 and ECN='01' or '10'. 2. a packet arriving at an PCN Egress Node with DSCP=PCN_1 and ECN='01' or '10'. I believe we should let the DiffServ part (and possibly the VPN part) do its job and explore the damage if it didn't (the safe/unsafe leakage considerations). >Hope you're de-fevered! My temperature dropped from 103/102 F of last week to about 100 F today. Running hot working on the next version of the draft. :) >phil > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Kwok-Ho Chan > > Sent: 22 February 2008 19:08 > > To: pcn@ietf.org > > Subject: [PCN] Encoding Option: '01' & '10' Encoding > > > > Hi all: > > Following up on Toby's E-Mail, I would like to bring out the possible > > choices for > > usage of '01' and '10' bit patterns (of the 2 bit ECN field in the IP > > Header) for PCN. > > > > For ECN: '01' = ECT(1), '10' = ECT(0). Meaning Not Congested, and >ECN > > Capable > > Transport, and ECN nonce usage. > > > > Toby's encoding suggest the NOT using of '01' and '10'. > > It is a good suggestion if we have more bits to use. But we don't, >and > > the use > > of additional DSCPs have other affects and trade-offs. > > > > Alternative is to use both '01' and '10' to indicate the packet is PCN > > capable > > (in another words belong to a PCN capable flow). > > > > The benefit of using '01' and '10' is allowing it to be used for PCN > > purpose. > > > > We have agreed to use a DSCP to indicate PCN Capable packets (flows), > > hence the PCN Capable notion (encoding state) is taken care of. > > > > We still need to represent Not Pre-Congested notion (encoding state). > > IMHO, the '01' and '10' bit patterns are good choices for encoding the > > Not Pre-Congested encoding state. > > > > Lets visit the benefits of such use: > > 1. Allow the representation of a PCN encoding state using ECN bits. > > Minimizing the use of additional DSCPs. > > > > 2. If a PCN '01' or '10' encoded packet receives ECN router treatment: > > The ECN router will not change the encoding if it does not >experience > > congestion. > > The ECN router will change the encoding to '11' (CE) if it > > experienced > > congestion, trusting the offered load to the congestion point > > will be reduced. > > If a PCN Edge Node receives the '11' encoding and if we choose it >to > > mean > > Termination, then the offered load to the congestion point will > > be reduced. > > PCN terminates the flow, hence this should be ECN (at least ECN >when > > used for TCP) friendly. Detailed discussions of how friendly >should > > be > > an algorithm matter and will need to involve algorithm > > comparisons with ECN. > > If an ECN End Node receives the '11' encoding, it will mean >interpret > > it > > as CE and will reduce the offered load as describe by RFC 3168. > > How friendly is this ECN flow to the PCN domain is a discussion > > of algorithms > > and will have to make assumptions of using ECN for TCP and which > > PCN algorithm. > > The how friendly discussions should be part of the algorithm > > discussions. > > > > 3. When ECN packets pass through PCN Interior Nodes with no Pre- > > Congestions, > > no affects to ECN and PCN. This includes ECN packets using ECN > > nonce. > > > > 4. When PCN packets pass through ECN routers with no Congestions, > > no affects to ECN and PCN. > > > > 5. If we don't have to worry about ECN nonce passing through PCN >nodes, > > we can use one of the two bit patterns for another PCN encoding > > state. > > > > Point # 2 above discusses: > > 1. ECN packets entering PCN domain and then leaving the PCN domain > > back into ECN routers and endpoints. > > 2. PCN packets leaving the PCN domain and encounters ECN routers and > > PCN endpoints. Does it make sense to talk about PCN packets > > encountering > > ECN (TCP) endpoints? If the ECN endpoint handles this PCN >packet, > > then > > it should reduce the flows offered load, the functionality PCN > > Interior Nodes expects. > > > > Based on the assumption of using PCN DSCP to separate PCN traffic and > > non PCN traffic: > > - When we talk about ECN packet entering PCN domain, we mean somehow > > the ECN packet uses the PCN DSCP. There are DiffServ methods to > > prevent this. > > - When we talk about PCN packet leaving PCN domain, we mean somehow > > the PCN packet encounters routers that does not understand the PCN >DSCP > > and interpret the PCN encoding differently. > > > > The bad part of such use: > > 1. Making the PCN algorithms to handle how friendly they are with ECN > > algorithm. > > > > Please notice the information provided above are in: > > >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison- > > 02.txt > > > > I am adding the details of Toby's suggestions to the -03 of the draft. > > > > Please let us know if there are points or concerns not addressed. > > Thanks! > > > > Sorry that I have been sick with the flu (fever, aches, cough, etc) > > the past few days. > > Just got below 100 degree temperature with my fever this morning. > > > > -- Kwok -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 09:10:29 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620153A6D73; Mon, 25 Feb 2008 09:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 xHKUpymZ3HFr; Mon, 25 Feb 2008 09:10:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565443A6A10; Mon, 25 Feb 2008 09:09:57 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABFD728C5FC for ; Mon, 25 Feb 2008 09:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95e4OHzfS26i for ; Mon, 25 Feb 2008 09:09:55 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id E3FD528C814 for ; Mon, 25 Feb 2008 09:08:01 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m1PH7u7g031831 for ; Mon, 25 Feb 2008 11:07:56 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:07:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 11:07:54 -0600 Message-ID: In-Reply-To: <47C2BD8B.1030008@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LC-PCN version 03 uploaded Thread-Index: Ach3zeYtA9e7+neQRDGq/2GWwZ1JlQAAs/+Q References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345CB@E03MVZ1-UKDY.domain1.systemhost.net> <47C2BD8B.1030008@informatik.uni-wuerzburg.de> From: "Anurag Bhargava" To: X-OriginalArrivalTime: 25 Feb 2008 17:07:55.0682 (UTC) FILETIME=[F6C13820:01C877D0] Subject: [PCN] LC-PCN version 03 uploaded 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org http://www.ietf.org/proceedings/staging/draft-westberg-pcn-load-control- 03.txt BR, -Anurag Bhargava _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 09:15:10 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDC63A6DA6; Mon, 25 Feb 2008 09:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 m7QfbLkfX0H6; Mon, 25 Feb 2008 09:15:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CB03A6D66; Mon, 25 Feb 2008 09:15:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A669428C1C7 for ; Mon, 25 Feb 2008 09:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phkFjEQoPxLv for ; Mon, 25 Feb 2008 09:14:54 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 1B2E53A6D79 for ; Mon, 25 Feb 2008 09:12:13 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 17:12:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 17:12:20 -0000 Message-ID: In-Reply-To: <1203694150.3476.2.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 thread-index: Ach1Z7bVVirwHtSnR3+Mvyw/Bp9dXgCWIR3g From: To: , X-OriginalArrivalTime: 25 Feb 2008 17:12:08.0375 (UTC) FILETIME=[8D5F1C70:01C877D1] Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I support this moving to working group last call in its current form Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 22 February 2008 15:29 > To: pcn > Subject: [PCN] draft-ietf-pcn-architecture-03 > > The chairs would like input on whether the working group has read > draft-ietf-pcn-architecture-03, and believes that it is ready for > working group last call. Please send your comments to this list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 10:06:12 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF5B3A6CDF; Mon, 25 Feb 2008 10:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 2pXnH1Rx0kbR; Mon, 25 Feb 2008 10:06:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7E928C659; Mon, 25 Feb 2008 10:02:26 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5C128C642 for ; Mon, 25 Feb 2008 10:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94GO6VXYUdHC for ; Mon, 25 Feb 2008 10:02:25 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A3C7C28C7DE for ; Mon, 25 Feb 2008 09:58:13 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1PHw7Ve025405 for ; Mon, 25 Feb 2008 11:58:07 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 11:58:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 11:58:06 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] LC-PCN version 03 uploaded Thread-Index: Ach3zeYtA9e7+neQRDGq/2GWwZ1JlQAAs/+QAAHOpLA= References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345CB@E03MVZ1-UKDY.domain1.systemhost.net><47C2BD8B.1030008@informatik.uni-wuerzburg.de> From: "Anurag Bhargava" To: "Anurag Bhargava" , X-OriginalArrivalTime: 25 Feb 2008 17:58:07.0514 (UTC) FILETIME=[F9F24FA0:01C877D7] Subject: Re: [PCN] LC-PCN version 03 uploaded 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org FYI, http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.t xt -Anurag Bhargava >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >Behalf Of Anurag Bhargava >Sent: Monday, February 25, 2008 12:08 PM >To: pcn@ietf.org >Subject: [PCN] LC-PCN version 03 uploaded > >http://www.ietf.org/proceedings/staging/draft-westberg-pcn-load -control- >03.txt > >BR, >-Anurag Bhargava >_______________________________________________ >PCN mailing list >PCN@ietf.org >http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 10:06:35 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC0F28C55C; Mon, 25 Feb 2008 10:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-1.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, 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 kspS6fMPcm-7; Mon, 25 Feb 2008 10:06:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F793A6D35; Mon, 25 Feb 2008 10:04:01 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5CB28C6B0 for ; Mon, 25 Feb 2008 10:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGyrmTwjKu+b for ; Mon, 25 Feb 2008 10:04:00 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 65B7A3A6D71 for ; Mon, 25 Feb 2008 10:01:26 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 18:01:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 18:01:19 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D1@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding Option: '01' & '10' Encoding Thread-Index: Ach3yLOlNnOPa2UURUW7JMe2osXYNwACIthg From: To: X-OriginalArrivalTime: 25 Feb 2008 18:01:20.0393 (UTC) FILETIME=[6CE94F90:01C877D8] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Some follow-ups below Thanks phil > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: 25 February 2008 16:08 > AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding state. > This is different from "PCN-capable" encoding state, which I believe we > agree is handled by the use of the PCN DSCP, for example: "PCN 1". Good point, PCN-capable is not the optimum term. > How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? Suggested Unmarked (UM), to keep it similar to AM & TM (and also I think NP is easy to wrongly guess as Not PCN-capable - in a draft which somewhere does have this as a codepoint, if I remember right) > >I think something like this is an option worth considering. Are these > >the pros & cons? > > This is currently in: > http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison- > 02.txt > > as options 1 and 2 in Figure 1 on page 10. > Please notice this is only a summary of the Pros, please read the > draft for details. I did look at that and tried to extract the pros and cons (S3.1.1-S3.1.3). I don't think I missed any pros. I also added 2 cons. I think we need to narrow down to just a few choices on the table & understand them fully. Personally I find there are too many options in the draft (in addition to the 9 that get an Option number, there are several other unnumbered variants mentioned) S3.1.4 I just re-read - there are some detailed bits I don't follow. We should make it crystal clear that the technique to meet 4774 concerns is separate dscp + configuration that all PCN-routers are configured with pcn. > > >o For a router to classify a packet as PCN, it simply reads its DSCP. > >This is probably easier than checking both its DSCP & ECN fields. > > Kwok: > This also allows easy use of PCN with VPNs. Please explain, don't understand. > Again, this depends on how '00' and '11' code points may be used. > For the example you provided (similar to draft's Option 1), this may be > true. > But for draft's Option 2, this may not be true. I re-read the paragraph under Fig 1 where you explain what option 2 is & I don't understand it. I think it may be the idea that both 01 & 10 mean Unmarked (ie not Pre-congested) and: AM is indicated by setting the codepoint of a 01 pkt to 11 TM is indicated by setting the codepoint of a 10 pkt to 11 If so, this is clearly an option that needs some careful discussion of potential Cons, as there are new types of consideration compared with Option 1. for example: - how do you ensure a regular supply of 01 & 10 at every PCN-router? - is this still guaranteed to work if the - what are the implications on reaction time of the overall system to pre-congestion? Perhaps the answers are just setting alternate pkts to 01 & 10 at the ingress node, and accepting the reaction time doubles. Perhaps something nasty can happen. You do no mention whether there are any pros to this approach. > > > >o If a packet (in a PCN flow) arrives at the egress with its ECN = 01, > >10 or 11 and it really is required to preserve this info across the > >PCN-domain, then some complexity is needed at the PCN-boundary-nodes > >(tunnelling) > > Kwok: > Not totally understanding your point. Sorry, I made a very confusing typo. Meant: > >o If a packet (in a PCN flow) arrives at the *ingress* with its ECN = 01, .... _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 25 10:42:12 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACFE3A6CF2; Mon, 25 Feb 2008 10:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.469 X-Spam-Level: X-Spam-Status: No, score=0.469 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, MANGLED_TOOL=2.3, 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 GQZOMh8zBf5z; Mon, 25 Feb 2008 10:42:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5363A6D14; Mon, 25 Feb 2008 10:41:23 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DA33A6A3B for ; Mon, 25 Feb 2008 10:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z+nlwhWwPcB for ; Mon, 25 Feb 2008 10:41:18 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 25A5728C3D5 for ; Mon, 25 Feb 2008 10:40:23 -0800 (PST) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m1PIa3j12409; Mon, 25 Feb 2008 18:36:03 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.66] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 13:39:29 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Feb 2008 13:39:29 -0500 To: From: "Kwok-Ho Chan" In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D1@E03MVZ1-UKDY.doma in1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D1@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Feb 2008 18:39:29.0930 (UTC) FILETIME=[C194EEA0:01C877DD] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil: I will try to provide the responses for the short answers below. For the long ones, I will try to add them into the draft. Thanks! -- Kwok -- At 01:01 PM 2/25/2008, philip.eardley@bt.com wrote: >Some follow-ups below >Thanks >phil > > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: 25 February 2008 16:08 > > > > AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding >state. > > This is different from "PCN-capable" encoding state, which I believe >we > > agree is handled by the use of the PCN DSCP, for example: "PCN 1". > >Good point, PCN-capable is not the optimum term. > > > How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? >Suggested Unmarked (UM), to keep it similar to AM & TM (and also I think >NP is easy to wrongly guess as Not PCN-capable - in a draft which >somewhere does have this as a codepoint, if I remember right) Kwok: OK, I will change them to "UM" for UnMarked to indicate No Pre-congestion detected. > > >I think something like this is an option worth considering. Are these > > >the pros & cons? > > > > This is currently in: > > >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison- > > 02.txt > > > > as options 1 and 2 in Figure 1 on page 10. > > Please notice this is only a summary of the Pros, please read the > > draft for details. > >I did look at that and tried to extract the pros and cons >(S3.1.1-S3.1.3). I don't think I missed any pros. I also added 2 cons. I >think we need to narrow down to just a few choices on the table & >understand them fully. Personally I find there are too many options in >the draft (in addition to the 9 that get an Option number, there are >several other unnumbered variants mentioned) Kwok: I am trying to use the notion of similarities (with similar pros and cons) and differences (with different pros and cons) to minimize the number of options. And the length of the draft. > >S3.1.4 I just re-read - there are some detailed bits I don't follow. We >should make it crystal clear that the technique to meet 4774 concerns is >separate dscp + configuration that all PCN-routers are configured with >pcn. I will try to make the clarification in the draft. > > > > >o For a router to classify a packet as PCN, it simply reads its >DSCP. > > >This is probably easier than checking both its DSCP & ECN fields. > > > > Kwok: > > This also allows easy use of PCN with VPNs. > >Please explain, don't understand. Kwok: I have a short sub section on this in the draft as a pro for using DSCP+ECN. > > Again, this depends on how '00' and '11' code points may be used. > > For the example you provided (similar to draft's Option 1), this may >be > > true. > > But for draft's Option 2, this may not be true. > >I re-read the paragraph under Fig 1 where you explain what option 2 is & >I don't understand it. >I think it may be the idea that both 01 & 10 mean Unmarked (ie not >Pre-congested) and: >AM is indicated by setting the codepoint of a 01 pkt to 11 >TM is indicated by setting the codepoint of a 10 pkt to 11 >If so, this is clearly an option that needs some careful discussion of >potential Cons, as there are new types of consideration compared with >Option 1. for example: >- how do you ensure a regular supply of 01 & 10 at every PCN-router? >- is this still guaranteed to work if the >- what are the implications on reaction time of the overall system to >pre-congestion? >Perhaps the answers are just setting alternate pkts to 01 & 10 at the >ingress node, and accepting the reaction time doubles. Perhaps something >nasty can happen. >You do no mention whether there are any pros to this approach. Kwok: OK, some clarification is in order. > > > > > > >o If a packet (in a PCN flow) arrives at the egress with its ECN = >01, > > >10 or 11 and it really is required to preserve this info across the > > >PCN-domain, then some complexity is needed at the PCN-boundary-nodes > > >(tunnelling) > > > > Kwok: > > Not totally understanding your point. > >Sorry, I made a very confusing typo. Meant: > > >o If a packet (in a PCN flow) arrives at the *ingress* with its ECN >= 01, .... Kwok: Got it. I am thinking of pushing the determination of which packet should be allowed to use the PCN DSCP (hence the entering of the PCN domain) as a function of the PCN Ingress Node. Notice this will also give the function of Inter-PCN-Domain setup, etc to the PCN Ingress Node. With the encoding to explain the corner cases of the un-intended "leaking" of packets into and out of the PCN domain. _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 01:34:42 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A9D3A6B5A; Tue, 26 Feb 2008 01:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 SoGfttICjRSl; Tue, 26 Feb 2008 01:34:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F593A6BDD; Tue, 26 Feb 2008 01:34:41 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55683A6BDD for ; Tue, 26 Feb 2008 01:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbAgSX0fzJXF for ; Tue, 26 Feb 2008 01:34:39 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id B4D3E3A6B5A for ; Tue, 26 Feb 2008 01:34:38 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 75504198E19; Tue, 26 Feb 2008 10:34:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6980D198E0E; Tue, 26 Feb 2008 10:34:32 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 265BC198DFF; Tue, 26 Feb 2008 10:34:30 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1Q9YUV17442; Tue, 26 Feb 2008 10:34:30 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D5271C7F1A; Tue, 26 Feb 2008 10:34:29 +0100 (CET) Message-ID: <47C3DCEC.9080409@informatik.uni-wuerzburg.de> Date: Tue, 26 Feb 2008 10:33:32 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kwok-Ho Chan References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D1@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, >>> How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? >>> >> Suggested Unmarked (UM), to keep it similar to AM & TM (and also I think >> NP is easy to wrongly guess as Not PCN-capable - in a draft which >> somewhere does have this as a codepoint, if I remember right) >> > > Kwok: > OK, I will change them to "UM" for UnMarked to indicate No > Pre-congestion detected. > Sorry to be picky on nomenclature again! Any codepoint is a marking. Therefore, "unmarked" is not a good term. I strongly prefer "no pre-congestion" or "not pre-congested" (NP). This is more precise than the colloquial "unmarked" which has no relation to its semantics within PCN. Having good nomenclature is important for novices to easily catch up with the system. 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 http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 02:33:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D77428C1B5; Tue, 26 Feb 2008 02:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 9JfB4NfwhQRi; Tue, 26 Feb 2008 02:33:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8E73A6C46; Tue, 26 Feb 2008 02:33:14 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269573A6C46 for ; Tue, 26 Feb 2008 02:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA0a2Ydsujf0 for ; Tue, 26 Feb 2008 02:33:13 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id AECD53A6C1F for ; Tue, 26 Feb 2008 02:33:12 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 26 Feb 2008 11:33:05 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Feb 2008 11:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 11:33:52 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8C5E6@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7bVVirwHtSnR3+Mvyw/Bp9dXgCWIR3gACgB/9A= References: <1203694150.3476.2.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 26 Feb 2008 10:32:50.0883 (UTC) FILETIME=[F001B130:01C87862] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, based on contents I agree that the architecture is in good shape and can move to last call. I'd expect comments from last call on formulations, not on content. Examples: - there's no figure explaining the functionalities and interfaces. - the term "signaling" is used in different sections to refer to * indication of pre-congestion. * feedback of measured pre-congestion (or admission/termination). * transfer per flow information at boundary nodes. The WG is well aware of the context when "signaling" pops up somewhere, but a new reader probably isn't and may loose track on some occasions. I'll comment details later. Regards, Rudiger > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 22 February 2008 15:29 > To: pcn > Subject: [PCN] draft-ietf-pcn-architecture-03 > > The chairs would like input on whether the working group has read > draft-ietf-pcn-architecture-03, and believes that it is ready for > working group last call. Please send your comments to this list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 03:22:31 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A07928C292; Tue, 26 Feb 2008 03:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, 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 eu+ZxOQ6aHUX; Tue, 26 Feb 2008 03:22:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D563728C24B; Tue, 26 Feb 2008 03:22:30 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAF828C25F for ; Tue, 26 Feb 2008 03:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DmfuVQqYOd5 for ; Tue, 26 Feb 2008 03:22:29 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id DC7C828C153 for ; Tue, 26 Feb 2008 03:22:27 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 11:22:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 11:22:20 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D6@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding Option: '01' & '10' Encoding Thread-Index: Ach33eBIHSJzolbmT4WxXU4DU6dknQAi1sWg From: To: X-OriginalArrivalTime: 26 Feb 2008 11:22:20.0891 (UTC) FILETIME=[DA44F2B0:01C87869] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > > Kwok: > > > This also allows easy use of PCN with VPNs. > > > >Please explain, don't understand. > > Kwok: > I have a short sub section on this in the draft as a pro for using > DSCP+ECN. Where? {I searched for vp, but this didn't find any] > I am thinking of pushing the determination of which packet should > be allowed to use the PCN DSCP (hence the entering of the PCN domain) > as a function of the PCN Ingress Node. Notice this will also give the S5.2 of the architecture draft [PCN-ingress-node functions] already says " o Packet classify - decide whether an incoming packet is part of a previously admitted microflow, by using a filter spec (eg DSCP, source and destination addresses and port numbers) " _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 04:17:52 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CC428C2E0; Tue, 26 Feb 2008 04:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.508 X-Spam-Level: * X-Spam-Status: No, score=1.508 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, MANGLED_TOOL=2.3, 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 2Hi0YA7GmRR7; Tue, 26 Feb 2008 04:17:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F483A6CF2; Tue, 26 Feb 2008 04:17:51 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F52C28C133 for ; Tue, 26 Feb 2008 04:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enKYeMAVjxxJ for ; Tue, 26 Feb 2008 04:17:48 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4A9E03A6D5B for ; Tue, 26 Feb 2008 04:17:15 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26FFA21997; Tue, 26 Feb 2008 12:49:41 +0100 (CET) X-AuditID: c1b4fb3e-aa9ffbb000000b15-dd-47c3fcd5a6a9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 05FE82134F; Tue, 26 Feb 2008 12:49:41 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 12:49:40 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 12:49:39 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E1E1@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding Option: '01' & '10' Encoding Thread-Index: Ach33+ANVomXZqkSTOKahzi2+TK7FgAhyZaA References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345D1@E03MVZ1-UKDY.domain1.systemhost.net> From: "Ingemar Johansson S" To: "Kwok-Ho Chan" , X-OriginalArrivalTime: 26 Feb 2008 11:49:40.0557 (UTC) FILETIME=[AB961FD0:01C8786D] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Trying to understand Option 2 in figure 1 in the PCN encoding comparison draft. As I understand it this option seems to be relatively transparent to end to end ECN. What confuses me a bit is the idea that AM is indicated by setting the codepoint of a 01 pkt to 11 TM is indicated by setting the codepoint of a 10 pkt to 11 My question is how do we know that the "11" is to be interpreted as AM or TM as we don't know if it was "01" or "10" before being remarked to "11" in a PCN node at least in the ECT pattern is random (as the nonce in RFC3540)? Is the idea that the PCN ingress node will override the ECT pattern to a deterministic "01" "10" "01" .... pattern ? /Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Kwok-Ho Chan > Sent: den 25 februari 2008 19:39 > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding > > Phil: > I will try to provide the responses for the short answers below. > For the long ones, I will try to add them into the draft. > Thanks! > -- Kwok -- > > At 01:01 PM 2/25/2008, philip.eardley@bt.com wrote: > >Some follow-ups below > >Thanks > >phil > > > > > -----Original Message----- > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > Sent: 25 February 2008 16:08 > > > > > > > AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding > >state. > > > This is different from "PCN-capable" encoding state, > which I believe > >we > > > agree is handled by the use of the PCN DSCP, for example: "PCN 1". > > > >Good point, PCN-capable is not the optimum term. > > > > > How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? > >Suggested Unmarked (UM), to keep it similar to AM & TM (and also I > >think NP is easy to wrongly guess as Not PCN-capable - in a > draft which > >somewhere does have this as a codepoint, if I remember right) > > Kwok: > OK, I will change them to "UM" for UnMarked to indicate No > Pre-congestion detected. > > > > > >I think something like this is an option worth > considering. Are these > > > >the pros & cons? > > > > > > This is currently in: > > > > >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-c > omparison- > > > 02.txt > > > > > > as options 1 and 2 in Figure 1 on page 10. > > > Please notice this is only a summary of the Pros, please read the > > > draft for details. > > > >I did look at that and tried to extract the pros and cons > >(S3.1.1-S3.1.3). I don't think I missed any pros. I also > added 2 cons. I > >think we need to narrow down to just a few choices on the table & > >understand them fully. Personally I find there are too many > options in > >the draft (in addition to the 9 that get an Option number, there are > >several other unnumbered variants mentioned) > > Kwok: > I am trying to use the notion of similarities (with similar > pros and cons) > and differences (with different pros and cons) to minimize the number > of options. And the length of the draft. > > > > >S3.1.4 I just re-read - there are some detailed bits I don't > follow. We > >should make it crystal clear that the technique to meet 4774 > concerns is > >separate dscp + configuration that all PCN-routers are > configured with > >pcn. > > I will try to make the clarification in the draft. > > > > > > > > > >o For a router to classify a packet as PCN, it simply reads its > >DSCP. > > > >This is probably easier than checking both its DSCP & ECN fields. > > > > > > Kwok: > > > This also allows easy use of PCN with VPNs. > > > >Please explain, don't understand. > > Kwok: > I have a short sub section on this in the draft as a pro for > using DSCP+ECN. > > > > > Again, this depends on how '00' and '11' code points may be used. > > > For the example you provided (similar to draft's Option > 1), this may > >be > > > true. > > > But for draft's Option 2, this may not be true. > > > >I re-read the paragraph under Fig 1 where you explain what > option 2 is & > >I don't understand it. > >I think it may be the idea that both 01 & 10 mean Unmarked (ie not > >Pre-congested) and: > >AM is indicated by setting the codepoint of a 01 pkt to 11 > >TM is indicated by setting the codepoint of a 10 pkt to 11 > >If so, this is clearly an option that needs some careful > discussion of > >potential Cons, as there are new types of consideration compared with > >Option 1. for example: > >- how do you ensure a regular supply of 01 & 10 at every PCN-router? > >- is this still guaranteed to work if the > >- what are the implications on reaction time of the overall system to > >pre-congestion? > >Perhaps the answers are just setting alternate pkts to 01 & 10 at the > >ingress node, and accepting the reaction time doubles. > Perhaps something > >nasty can happen. > >You do no mention whether there are any pros to this approach. > > Kwok: > OK, some clarification is in order. > > > > > > > > > > > >o If a packet (in a PCN flow) arrives at the egress > with its ECN = > >01, > > > >10 or 11 and it really is required to preserve this info > across the > > > >PCN-domain, then some complexity is needed at the > PCN-boundary-nodes > > > >(tunnelling) > > > > > > Kwok: > > > Not totally understanding your point. > > > >Sorry, I made a very confusing typo. Meant: > > > >o If a packet (in a PCN flow) arrives at the *ingress* > with its ECN > >= 01, .... > > Kwok: > Got it. > I am thinking of pushing the determination of which packet should > be allowed to use the PCN DSCP (hence the entering of the PCN domain) > as a function of the PCN Ingress Node. Notice this will also give the > function of Inter-PCN-Domain setup, etc to the PCN Ingress Node. > With the encoding to explain the corner cases of the > un-intended "leaking" > of packets into and out of the PCN domain. > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 05:42:33 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767563A68F0; Tue, 26 Feb 2008 05:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[AWL=-2.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, MANGLED_TOOL=2.3, 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 BrCVRP6jqCn2; Tue, 26 Feb 2008 05:42:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC76D28C381; Tue, 26 Feb 2008 05:42:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4EC3A682E for ; Tue, 26 Feb 2008 05:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YC-SSBu3PRR for ; Tue, 26 Feb 2008 05:42:25 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 8B0D43A6BCA for ; Tue, 26 Feb 2008 05:42:24 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 13:42:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 13:42:17 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345DC@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1E1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding Option: '01' & '10' Encoding Thread-Index: Ach33+ANVomXZqkSTOKahzi2+TK7FgAhyZaAAAV/UHA= From: To: , X-OriginalArrivalTime: 26 Feb 2008 13:42:17.0975 (UTC) FILETIME=[67524870:01C8787D] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > Is the idea that the PCN ingress node will override the ECT pattern to a > deterministic "01" "10" "01" .... pattern ? it isnt overwriting as - if ect is running end to end it's tunnelled. That basically means the pcn ingress can set these bits as it likes so I think the idea is that (eg) ingress sets say alternate 01 & 10. egress then measures the ratio of 01, 10 & 11 in order to deduce % AM & TM. phil > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 26 February 2008 11:50 > To: Kwok-Ho Chan; Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Encoding Option: '01' & '10' Encoding > > Hi > > Trying to understand Option 2 in figure 1 in the PCN encoding comparison > draft. > As I understand it this option seems to be relatively transparent to end > to end ECN. What confuses me a bit is the idea that > AM is indicated by setting the codepoint of a 01 pkt to 11 > TM is indicated by setting the codepoint of a 10 pkt to 11 > > My question is how do we know that the "11" is to be interpreted as AM > or TM as we don't know if it was "01" or "10" before being remarked to > "11" in a PCN node at least in the ECT pattern is random (as the nonce > in RFC3540)? > > Is the idea that the PCN ingress node will override the ECT pattern to a > deterministic "01" "10" "01" .... pattern ? > > > > /Ingemar > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of Kwok-Ho Chan > > Sent: den 25 februari 2008 19:39 > > To: philip.eardley@bt.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding > > > > Phil: > > I will try to provide the responses for the short answers below. > > For the long ones, I will try to add them into the draft. > > Thanks! > > -- Kwok -- > > > > At 01:01 PM 2/25/2008, philip.eardley@bt.com wrote: > > >Some follow-ups below > > >Thanks > > >phil > > > > > > > -----Original Message----- > > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > > Sent: 25 February 2008 16:08 > > > > > > > > > > AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding > > >state. > > > > This is different from "PCN-capable" encoding state, > > which I believe > > >we > > > > agree is handled by the use of the PCN DSCP, for example: "PCN 1". > > > > > >Good point, PCN-capable is not the optimum term. > > > > > > > How about the use of "NP" to denote "NOT PRE-CONGESTED" ?? > > >Suggested Unmarked (UM), to keep it similar to AM & TM (and also I > > >think NP is easy to wrongly guess as Not PCN-capable - in a > > draft which > > >somewhere does have this as a codepoint, if I remember right) > > > > Kwok: > > OK, I will change them to "UM" for UnMarked to indicate No > > Pre-congestion detected. > > > > > > > > >I think something like this is an option worth > > considering. Are these > > > > >the pros & cons? > > > > > > > > This is currently in: > > > > > > >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-c > > omparison- > > > > 02.txt > > > > > > > > as options 1 and 2 in Figure 1 on page 10. > > > > Please notice this is only a summary of the Pros, please read the > > > > draft for details. > > > > > >I did look at that and tried to extract the pros and cons > > >(S3.1.1-S3.1.3). I don't think I missed any pros. I also > > added 2 cons. I > > >think we need to narrow down to just a few choices on the table & > > >understand them fully. Personally I find there are too many > > options in > > >the draft (in addition to the 9 that get an Option number, there are > > >several other unnumbered variants mentioned) > > > > Kwok: > > I am trying to use the notion of similarities (with similar > > pros and cons) > > and differences (with different pros and cons) to minimize the number > > of options. And the length of the draft. > > > > > > > >S3.1.4 I just re-read - there are some detailed bits I don't > > follow. We > > >should make it crystal clear that the technique to meet 4774 > > concerns is > > >separate dscp + configuration that all PCN-routers are > > configured with > > >pcn. > > > > I will try to make the clarification in the draft. > > > > > > > > > > > > > > >o For a router to classify a packet as PCN, it simply reads its > > >DSCP. > > > > >This is probably easier than checking both its DSCP & ECN fields. > > > > > > > > Kwok: > > > > This also allows easy use of PCN with VPNs. > > > > > >Please explain, don't understand. > > > > Kwok: > > I have a short sub section on this in the draft as a pro for > > using DSCP+ECN. > > > > > > > > Again, this depends on how '00' and '11' code points may be used. > > > > For the example you provided (similar to draft's Option > > 1), this may > > >be > > > > true. > > > > But for draft's Option 2, this may not be true. > > > > > >I re-read the paragraph under Fig 1 where you explain what > > option 2 is & > > >I don't understand it. > > >I think it may be the idea that both 01 & 10 mean Unmarked (ie not > > >Pre-congested) and: > > >AM is indicated by setting the codepoint of a 01 pkt to 11 > > >TM is indicated by setting the codepoint of a 10 pkt to 11 > > >If so, this is clearly an option that needs some careful > > discussion of > > >potential Cons, as there are new types of consideration compared with > > >Option 1. for example: > > >- how do you ensure a regular supply of 01 & 10 at every PCN-router? > > >- is this still guaranteed to work if the > > >- what are the implications on reaction time of the overall system to > > >pre-congestion? > > >Perhaps the answers are just setting alternate pkts to 01 & 10 at the > > >ingress node, and accepting the reaction time doubles. > > Perhaps something > > >nasty can happen. > > >You do no mention whether there are any pros to this approach. > > > > Kwok: > > OK, some clarification is in order. > > > > > > > > > > > > > > > > >o If a packet (in a PCN flow) arrives at the egress > > with its ECN = > > >01, > > > > >10 or 11 and it really is required to preserve this info > > across the > > > > >PCN-domain, then some complexity is needed at the > > PCN-boundary-nodes > > > > >(tunnelling) > > > > > > > > Kwok: > > > > Not totally understanding your point. > > > > > >Sorry, I made a very confusing typo. Meant: > > > > >o If a packet (in a PCN flow) arrives at the *ingress* > > with its ECN > > >= 01, .... > > > > Kwok: > > Got it. > > I am thinking of pushing the determination of which packet should > > be allowed to use the PCN DSCP (hence the entering of the PCN domain) > > as a function of the PCN Ingress Node. Notice this will also give the > > function of Inter-PCN-Domain setup, etc to the PCN Ingress Node. > > With the encoding to explain the corner cases of the > > un-intended "leaking" > > of packets into and out of the PCN domain. > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > http://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 07:13:22 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C921128C325; Tue, 26 Feb 2008 07:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 6bkGN581+b0p; Tue, 26 Feb 2008 07:13:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BAD3A6C46; Tue, 26 Feb 2008 07:13:21 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3F53A6C46 for ; Tue, 26 Feb 2008 07:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2blMWHLkDhhW for ; Tue, 26 Feb 2008 07:13:20 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id ECB493A68B5 for ; Tue, 26 Feb 2008 07:13: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 m1QFCsgS023105; Tue, 26 Feb 2008 16:13:01 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , References: <1203694150.3476.2.camel@neutrino> Date: Tue, 26 Feb 2008 16:12:49 +0100 Message-ID: <004901c8788a$1221bcc0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1203694150.3476.2.camel@neutrino> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJA 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]); Tue, 26 Feb 2008 16:13:01 +0100 (MET) Cc: 'pcn' Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, Hi Phil I have read the draft! In my opinion it is ready for Working Group Last Call! However, I have a comment regarding bullet 4 in Section 7.2: * Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets "must be handled" the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN- marking. In the above text please change "must be handled" to "should be handled". The reason of this request, is related to the fact that in some scenarios the probe packet is used before a flow is admitted and therefore it can be handled differently than other data packets that are sent during the duration of a flow. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: vrijdag 22 februari 2008 16:29 > To: pcn > Subject: [PCN] draft-ietf-pcn-architecture-03 > > The chairs would like input on whether the working group has > read draft-ietf-pcn-architecture-03, and believes that it is > ready for working group last call. Please send your comments > to this list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 07:35:00 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2423A6B8B; Tue, 26 Feb 2008 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 ihD+Y1usvG+D; Tue, 26 Feb 2008 07:34:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871513A6CAB; Tue, 26 Feb 2008 07:34:56 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0233A6CBC for ; Tue, 26 Feb 2008 07:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzSX7OcT4skZ for ; Tue, 26 Feb 2008 07:34:50 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AB7C43A6CFA for ; Tue, 26 Feb 2008 07:34:48 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 15:34:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:34:39 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345DE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <004901c8788a$1221bcc0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuA= From: To: , X-OriginalArrivalTime: 26 Feb 2008 15:34:40.0645 (UTC) FILETIME=[1A441350:01C8788D] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > However, I have a comment regarding bullet 4 in Section 7.2: > > > * Forward probe packets - as far as PCN-interior-nodes are > concerned, probe packets "must be handled" the same as (ordinary > data) PCN-packets, in terms of routing, scheduling and PCN- > marking. > > In the above text please change "must be handled" to "should be handled". > The reason of this request, is related to the fact that in some scenarios > the probe packet is used before a flow is admitted yes, probe is sent before flow admitted > and therefore it can be > handled differently than other data packets that are sent during the > duration of a flow. 'therefore...' - I don't understand how this follows. I thought [1] probe pkts look the same as data pkts, how can the interior node distinguish them? [2] if probe pkts weren't handled the same way, then it would be dangerous for the egress to use the probe to make an admission decision. _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 07:51:47 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C1A28C51A; Tue, 26 Feb 2008 07:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 TseT0R8wsJAp; Tue, 26 Feb 2008 07:51:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF2F3A6BA0; Tue, 26 Feb 2008 07:51:46 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E257B28C3AE for ; Tue, 26 Feb 2008 07:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvr3faLutVUe for ; Tue, 26 Feb 2008 07:51:44 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C115F28C1BA for ; Tue, 26 Feb 2008 07:51:43 -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 m1QFpNFh026634; Tue, 26 Feb 2008 16:51:35 +0100 (MET) From: "Georgios Karagiannis" To: , References: <004901c8788a$1221bcc0$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345DE@E03MVZ1-UKDY.domain1.systemhost.net> Date: Tue, 26 Feb 2008 16:51:18 +0100 Message-ID: <000101c8788f$756c7e00$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345DE@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawA== 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]); Tue, 26 Feb 2008 16:51:36 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil > I thought [1] probe pkts look the same as data pkts, how can > the interior node distinguish them? Georgios: By using e.g., a Router Alert option, A RSVP PATH message carries a Router Alert option! For more details see Section 3.1.2.1 and 4.2.1 in: http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.txt > [2] if probe pkts weren't > handled the same way, then it would be dangerous for the > egress to use the probe to make an admission decision. Georgios: please see Section 3.1.2.2 and 4.2.2 in http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.txt Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 februari 2008 16:35 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > However, I have a comment regarding bullet 4 in Section 7.2: > > > > > > * Forward probe packets - as far as PCN-interior-nodes are > > concerned, probe packets "must be handled" the same > as (ordinary > > data) PCN-packets, in terms of routing, scheduling and PCN- > > marking. > > > > In the above text please change "must be handled" to "should be > handled". > > The reason of this request, is related to the fact that in some > scenarios > > the probe packet is used before a flow is admitted > > yes, probe is sent before flow admitted > > > and therefore it can be > > handled differently than other data packets that are sent > during the > > duration of a flow. > > 'therefore...' - I don't understand how this follows. > I thought [1] probe pkts look the same as data pkts, how can > the interior node distinguish them? [2] if probe pkts weren't > handled the same way, then it would be dangerous for the > egress to use the probe to make an admission decision. > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 08:11:10 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7106828C354; Tue, 26 Feb 2008 08:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 NvipXpSiKAxc; Tue, 26 Feb 2008 08:11:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932A63A6D20; Tue, 26 Feb 2008 08:11:06 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D1C28C2FD for ; Tue, 26 Feb 2008 08:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw9Zw8oETYb3 for ; Tue, 26 Feb 2008 08:11:05 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BE9883A6D20 for ; Tue, 26 Feb 2008 08:11:04 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 16:10:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 16:10:56 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E0@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000101c8788f$756c7e00$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+A From: To: , X-OriginalArrivalTime: 26 Feb 2008 16:10:58.0042 (UTC) FILETIME=[2C187DA0:01C87892] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios I checked these sections. They say things like "Thus if a PCN- interior-node receives a probe packet then, due to the Router Alert option it has to handle it differently then the user packets. " what I couldn't find is what " handle it differently" actually means (and why the interior node is handling them differently) thanks phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 26 February 2008 15:51 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Hi Phil > > > I thought [1] probe pkts look the same as data pkts, how can > > the interior node distinguish them? > > Georgios: By using e.g., a Router Alert option, > A RSVP PATH message carries a Router Alert option! > For more details see Section 3.1.2.1 and 4.2.1 in: > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.t xt > > > > [2] if probe pkts weren't > > handled the same way, then it would be dangerous for the > > egress to use the probe to make an admission decision. > > Georgios: please see Section 3.1.2.2 and 4.2.2 in > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.t xt > > Best regards, > Georgios > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: dinsdag 26 februari 2008 16:35 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > However, I have a comment regarding bullet 4 in Section 7.2: > > > > > > > > > * Forward probe packets - as far as PCN-interior-nodes are > > > concerned, probe packets "must be handled" the same > > as (ordinary > > > data) PCN-packets, in terms of routing, scheduling and PCN- > > > marking. > > > > > > In the above text please change "must be handled" to "should be > > handled". > > > The reason of this request, is related to the fact that in some > > scenarios > > > the probe packet is used before a flow is admitted > > > > yes, probe is sent before flow admitted > > > > > and therefore it can be > > > handled differently than other data packets that are sent > > during the > > > duration of a flow. > > > > 'therefore...' - I don't understand how this follows. > > I thought [1] probe pkts look the same as data pkts, how can > > the interior node distinguish them? [2] if probe pkts weren't > > handled the same way, then it would be dangerous for the > > egress to use the probe to make an admission decision. > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 08:18:06 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F146828C360; Tue, 26 Feb 2008 08:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 ZJ+HfXtu3+Pn; Tue, 26 Feb 2008 08:18:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC713A6D20; Tue, 26 Feb 2008 08:18:00 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42393A6D20 for ; Tue, 26 Feb 2008 08:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K06oeuDSoXrO for ; Tue, 26 Feb 2008 08:17:54 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id D769728C47A for ; Tue, 26 Feb 2008 08:17:22 -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 m1QGHCAr028901; Tue, 26 Feb 2008 17:17:14 +0100 (MET) From: "Georgios Karagiannis" To: , References: <000101c8788f$756c7e00$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E0@E03MVZ1-UKDY.domain1.systemhost.net> Date: Tue, 26 Feb 2008 17:17:07 +0100 Message-ID: <000501c87893$0b95c730$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E0@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCA= 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]); Tue, 26 Feb 2008 17:17:15 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil In general, when a packet carries a Router Alert option, then it is handled differently than other packets. In particular, it is taken out the fast forwarding path. Now if the packet is a PCN aware packet, i.e., it is marked as a not congested PCN packet or PCN_marking or PCN_Affected_Marking encoded, and carries a Router Alert option, then the PCN-interior node will able to distinguish it from the other PCN aware packets. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 februari 2008 17:11 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Georgios > > I checked these sections. They say things like "Thus if a PCN- > interior-node receives a probe packet then, due to the Router Alert > option it has to handle it differently then the user packets. " > > what I couldn't find is what " handle it differently" > actually means (and why the interior node is handling them > differently) > > thanks > phil > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 26 February 2008 15:51 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi Phil > > > > > I thought [1] probe pkts look the same as data pkts, how can the > > > interior node distinguish them? > > > > Georgios: By using e.g., a Router Alert option, A RSVP PATH message > > carries a Router Alert option! > > For more details see Section 3.1.2.1 and 4.2.1 in: > > > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-co ntrol-03.t > xt > > > > > > > [2] if probe pkts weren't > > > handled the same way, then it would be dangerous for the > egress to > > > use the probe to make an admission decision. > > > > Georgios: please see Section 3.1.2.2 and 4.2.2 in > > > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-co ntrol-03.t > xt > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: dinsdag 26 februari 2008 16:35 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > > > However, I have a comment regarding bullet 4 in Section 7.2: > > > > > > > > > > > > * Forward probe packets - as far as PCN-interior-nodes are > > > > concerned, probe packets "must be handled" the same > > > as (ordinary > > > > data) PCN-packets, in terms of routing, > scheduling and PCN- > > > > marking. > > > > > > > > In the above text please change "must be handled" to "should be > > > handled". > > > > The reason of this request, is related to the fact that in some > > > scenarios > > > > the probe packet is used before a flow is admitted > > > > > > yes, probe is sent before flow admitted > > > > > > > and therefore it can be > > > > handled differently than other data packets that are sent > > > during the > > > > duration of a flow. > > > > > > 'therefore...' - I don't understand how this follows. > > > I thought [1] probe pkts look the same as data pkts, how can the > > > interior node distinguish them? [2] if probe pkts weren't handled > > > the same way, then it would be dangerous for the egress > to use the > > > probe to make an admission decision. > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 08:45:41 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B1F28C5E5; Tue, 26 Feb 2008 08:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 RX9M2GIvo6qS; Tue, 26 Feb 2008 08:45:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF45028C4C3; Tue, 26 Feb 2008 08:45:37 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DA328C4C3 for ; Tue, 26 Feb 2008 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf3TmodcrHpe for ; Tue, 26 Feb 2008 08:45:32 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4A1FA28C55D for ; Tue, 26 Feb 2008 08:45:32 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 16:45:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 16:45:24 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E2@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000501c87893$0b95c730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCAAAMoNQA== From: To: , X-OriginalArrivalTime: 26 Feb 2008 16:45:26.0014 (UTC) FILETIME=[FCB3F9E0:01C87896] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org But why would the interior node *need* to distinguish it from other pcn pkts? And even if you have got router alert, the architecture draft says: "must be handled the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN-marking." Even though your router alert's got it in slow path, will it handle it any differently in terms of routing scehdulign & pcn-marking? _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 08:59:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F5428C4C3; Tue, 26 Feb 2008 08:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 mN4LwjcdhjRi; Tue, 26 Feb 2008 08:59:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C2D28C4A9; Tue, 26 Feb 2008 08:59:51 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B8F28C4A9 for ; Tue, 26 Feb 2008 08:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xUCB1FL1Vbv for ; Tue, 26 Feb 2008 08:59:48 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id ED17F28C3EE for ; Tue, 26 Feb 2008 08:59:47 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1QGxZnH032725; Tue, 26 Feb 2008 18:59:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:59:37 +0200 Received: from [10.180.41.9] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:59:37 +0200 Message-Id: From: Lars Eggert To: ext Steven Blake In-Reply-To: <1203694150.3476.2.camel@neutrino> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 18:59:34 +0200 References: <1203694150.3476.2.camel@neutrino> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 26 Feb 2008 16:59:37.0819 (UTC) FILETIME=[F86B1AB0:01C87898] X-Nokia-AV: Clean Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 2008-2-22, at 17:29, ext Steven Blake wrote: > The chairs would like input on whether the working group has read > draft-ietf-pcn-architecture-03, and believes that it is ready for > working group last call. Please send your comments to this list. The document does a tremendous job of outlining the PCN architecture - nice job. I don't think it is ready for WGLC yet, however. This is, because there are still several places where it simply lists options for doing things that are still under discussion, and for which the WG needs to come to consensus on *one* option. I'm not faulting the document or the authors; this is merely a reflection of the WG not having come to consensus yet. Lars Detailed comments: Section 1., paragraph 9: > o The PCN-egress-nodes make separate measurements, operating on the > aggregate PCN-traffic from each PCN-ingress-node, ie not per flow. > Similarly, signalling by the PCN-egress-node of PCN-feedback- > information (which is used for flow admission and termination > decisions) is at the granularity of the ingress-egress- aggregate. > An alternative approach is that the PCN-egress-nodes monitor the > PCN-traffic and signal PCN-feedback-information (which is used for > flow admission and termination decisions) at the granularity of > one (or a few) PCN-marks. I don't understand what the "alternative approach" is doing - please elaborate. Section 1., paragraph 19: > o Depending on the deployment scenario, the decision-making > functionality (about flow admission and termination) could reside > at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at > some central control node in the PCN-domain. It is important to discuss somewhere that some choices here are less optimal than others. A good decision-making location is where PCN information naturally accumulates, e.g. at the egress. Any relocation of that decision-making requires additional communication, which increases the delay of the control loop and makes the system more brittle, because correct operation now requires dependable communication between the egress and the decision-making point. I'd like to suggest that we attempt to come to consensus on whether we can focus on a single decision point for PCN. Section 1., paragraph 21: > o The PCN-domain extends to the end users. The scenario is > described in [I-D.babiarz-pcn-sip-cap]. A variant is that the > PCN-domain extends out as far as the LAN edge switch. This deployment model may not be possible under the initial charter, or maybe even under an extended charter, because it is not clear that sufficient statistical multiplexing exists on the links near the edge to make PCN work, which is a *fundamental* assumption of PCN (see assumption 3 in Section 3). Listing this deployment scenario here when we aren't sure how to support it raises false expectations - I'd hence propose to drop this bullet item. Section 1., paragraph 27: > From the perspective of the outside world, a PCN-domain essentially > looks like a DiffServ domain. PCN-traffic is either transported > across it transparently or policed at the PCN-ingress-node (ie > dropped or carried at a lower QoS). A couple of differences are > that: PCN-traffic has better QoS guarantees than normal DiffServ > traffic (because PCN's mechanisms better protect the QoS of admitted > flows); and in rare circumstances (failures), on the one hand some > PCN-flows may get terminated, but on the other hand other flows will > get their QoS restored. Non PCN-traffic is treated transparently, ie > the PCN-domain is a normal DiffServ domain. This paragraph would make more sense earlier in the intro. Section 3.5., paragraph 2: > The following two assumptions apply if the PCN WG decides to encode > PCN-marking in the ECN-field. Please add that any such encoding needs to conform to RFC4774. Section 4.1., paragraph 4: > NOTE: Two main categories of algorithm have been proposed: if the > algorithm uses threshold-marking then all PCN-packets are marked if > the current rate exceeds the PCN-lower-rate, whereas if the algorithm > uses excess-rate-marking the amount marked is equal to the amount in > excess of the PCN-lower-rate. However, note that this description > reflects the overall intent of the algorithm rather than its > instantaneous behaviour, since the rate measured at a particular > moment depends on the detailed algorithm, its implementation and the > traffic's variance as well as its rate (eg marking may well continue > after a recent overload even after the instantaneous rate has > dropped). It seems important that we come to consensus on which scheme will be used for PCN before we move forward with the architecture. Otherwise, we're merely postponing a difficult decision we'll have to tackle eventually anyway. Section 4.1., paragraph 7: > o if the PCN-egress-node receives one (or several) PCN-marked > packets, then a new flow is blocked, otherwise it is admitted. I don't understand this - please elaborate. (Is this related to my earlier comment about the "alternative approach"?) Section 4.2., paragraph 1: > At a high level, flow termination control works as follows. Each > PCN-node PCN-marks packets in a similar fashion to above, with all > proposals using an excess-rate-marking approach (Section 4.1). An > obvious approach is for the algorithm to use a second configured > parameter, PCN-upper-rate, and a second header encoding. However > there is also a proposal to use the same rate and the same encoding. Are we coming to consensus on which to pick moving forward? As before, I'd like us to avoid postponing difficult decisions. Section 4.3., paragraph 4: > A different possibility is to configure only the PCN-lower-rate and > hence only do one type of PCN-marking, but generate admission and > flow termination responses from different levels of marking. This is > suggested in [I-D.charny-pcn-single-marking] which gives some of the > pros and cons of this approach. draft-charny is at odds with the second paragraph of the intro, which says that each link has a PCN-lower-rate and a PCN-upper-rate. If the intent of the architecture is to permit a proposal like draft-charny, those concepts need to be re-defined. Section 4.5., paragraph 2: > o There needs to be a way for a PCN-node to distinguish PCN- traffic > from non PCN-traffic. They may be distinguished using the DSCP > field and/or ECN field. Please refer to RFC4774 again. Section 5.3., paragraph 5: > Another PCN WG document, about boundary mechanisms, will describe > PCN-metering in more detail. As described in Section 4.1 and Section > 4.2, at present there are two alternative proposals: to measure as an > aggregate (ie not per flow) all PCN-packets from a particular PCN- > ingress-node; or to monitor the PCN-traffic and react to one (or > several) PCN-marks. We refer to these approaches as "measuring PCN- > traffic" and "monitoring PCN-marks". The PCN-metering functionality > also depends on whether the measurement is targeted at admission > control or flow termination. It also depends on what encoding and > PCN-marking algorithms are specified by the PCN WG. OK, this clarifies the "alternative approach that I had two comments about above a bit more. I'd suggest to move some of that explanation earlier in the document. (But we do need to decide on which option to go with, too.) Section 5.4., paragraph 8: > The decision needs to be passed to the application layer so that it > can take the appropriate action. The application layer at what node? And define "appropriate". Section 5.6., paragraph 4: > o Use a probe packet that includes as payload the address of the > PCN-ingress-node. I don't understand how a probe packet can be used by the egress to determine the address of the ingress, if the egress needs to know this address to send the probe packet. (But see my comment on probing below; this may be moot.) Section 5.8., paragraph 0: > 5.8. Fault handling It may be a good idea to add a paragraph that describes that re-routing must be constrained in a way that upholds the boundary of the PCN domain. In other words, re-routing MUST NOT cause traffic to enter the domain without going through a PCN ingress. Section 7., paragraph 0: > 7. Probing I am still opposed to probing as part of the PCN architecture. It is a *very* complex mechanism with lots of open issues surrounding how it could actually be implemenented that in the end serves only one purpose: to slightly increase capacity utilization in a PCN domain. However, PCN was never meant to remove the need for sufficient overprovisioning. A second reason is that probing is only really needed to extend PCN into scenarios where some of the assumptions (sufficient multiplexing, etc.) are no longer true. We already have a boatload of explicitly-signalled QoS architectures that were designed for just such scenarios. I see no reason to complicate PCN into yet another signalled-QoS system. We already had consensus in Vancouver to stop discussing probing until after work on the initial milestones has finished. I'd like to propose to remove the discussion of probing from the architecture at least until that time. ------------------------------------------ NITS (only of interest to the authors) Nit: eliminate use of first person (throughout the document) Nit: s/ie/i.e.,/ (everywhere) Nit: s/eg/e.g.,/ (everywhere) Section 2., paragraph 1: > nodes that perform DiffServ scheduling; the compete set of PCN- Nit: s/compete/complete/ Section 4.3., paragraph 2: > sessions end, existing microflows naturally depart from the system Nit: s/microflow/flow/ (or else define what a microflow is; also elsewhere in the document) _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 09:06:09 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA43A6C19; Tue, 26 Feb 2008 09:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 kRQG4JZTLVA0; Tue, 26 Feb 2008 09:06:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BEA28C6D0; Tue, 26 Feb 2008 09:06:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794F028C720 for ; Tue, 26 Feb 2008 09:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEkLe7Ha4p1o for ; Tue, 26 Feb 2008 09:06:01 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 4F8B03A6D69 for ; Tue, 26 Feb 2008 09:05:59 -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 m1QH5ifZ002376; Tue, 26 Feb 2008 18:05:51 +0100 (MET) From: "Georgios Karagiannis" To: , References: <000501c87893$0b95c730$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E2@E03MVZ1-UKDY.domain1.systemhost.net> Date: Tue, 26 Feb 2008 18:05:43 +0100 Message-ID: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E2@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCAAAMoNQAAAbpBg 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]); Tue, 26 Feb 2008 18:05:52 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil * Regarding Routing NOT, * Regarding scheduling, NOT * Regarding PCN_marking, it could be handled differently: ** if excess rate marking is used AND the PCN-interior-node is congested AND the probe packet contains the ROUTER ALERT option THEN the probe packet can be distinguished from the other PCN packets, and therefore it will be for sure PCN_marking encoded. ** if excess rate marking is used AND the PCN-interior-node is congested AND the probe packet DOES NOT contain the ROUTER ALERT option THEN this MIGHT be PCN_marking encoded, or it MIGHT not be PCN_marking encoded. This depends on whether this probe packet is selected to represent the excess rate, or is not selected. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 februari 2008 17:45 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > But why would the interior node *need* to distinguish it from > other pcn pkts? > > And even if you have got router alert, the architecture draft says: > "must be handled the same as (ordinary data) PCN-packets, in > terms of routing, scheduling and PCN-marking." > Even though your router alert's got it in slow path, will it > handle it any differently in terms of routing scehdulign & > pcn-marking? > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 09:16:28 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2252728C47A; Tue, 26 Feb 2008 09:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 O6La1DMdpr4d; Tue, 26 Feb 2008 09:16:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ABC3A6C64; Tue, 26 Feb 2008 09:16:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DADB3A6C2A for ; Tue, 26 Feb 2008 09:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71oJnJSBvdQZ for ; Tue, 26 Feb 2008 09:16:25 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id F16AE3A6C11 for ; Tue, 26 Feb 2008 09:16:23 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 17:16:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 17:16:15 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCAAAMoNQAAAbpBgAADcaAA= From: To: , X-OriginalArrivalTime: 26 Feb 2008 17:16:16.0600 (UTC) FILETIME=[4BBCFD80:01C8789B] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Sorry, to repeat: I still have not the foggiest idea why on earth someone would want or need or be interested in the interior node handling probe pkts differently from the way it handles probe pkts. So far you have answered a different question, about whether it would be possible for someone to devise pcn so that an interior node could distinguish probe pkts from data pkts. As you say, a router alert option could indeed be used. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 26 February 2008 17:06 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Hi Phil > > * Regarding Routing NOT, > * Regarding scheduling, NOT > * Regarding PCN_marking, it could be handled differently: > > ** if excess rate marking is used AND the PCN-interior-node is congested > AND > the probe packet contains the ROUTER ALERT option THEN > the probe packet can be distinguished from the other PCN packets, > and therefore it will be for sure PCN_marking encoded. > > ** if excess rate marking is used AND the PCN-interior-node is congested > AND > the probe packet DOES NOT contain the ROUTER ALERT option > THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > PCN_marking > encoded. This depends > on whether this probe packet is selected to represent the excess > rate, > or is not selected. > > Best regards, > Georgios > > > > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: dinsdag 26 februari 2008 17:45 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > But why would the interior node *need* to distinguish it from > > other pcn pkts? > > > > And even if you have got router alert, the architecture draft says: > > "must be handled the same as (ordinary data) PCN-packets, in > > terms of routing, scheduling and PCN-marking." > > Even though your router alert's got it in slow path, will it > > handle it any differently in terms of routing scehdulign & > > pcn-marking? > > > > > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 26 09:38:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3EB28C209; Tue, 26 Feb 2008 09:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 cbZD80bN4R-F; Tue, 26 Feb 2008 09:38:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3092A3A6B86; Tue, 26 Feb 2008 09:38:04 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9035228C135 for ; Tue, 26 Feb 2008 09:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn7bCS55sLnU for ; Tue, 26 Feb 2008 09:38:01 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 88CDF28C3B7 for ; Tue, 26 Feb 2008 09:37:11 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 17:37:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 17:37:17 -0000 Message-ID: In-Reply-To: <1203694349.3476.6.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN IETF 71 agenda thread-index: Ach1aE8fOPbJuFDjRSiJIWnl0PDodgDNYQew From: To: , X-OriginalArrivalTime: 26 Feb 2008 17:37:04.0646 (UTC) FILETIME=[33A1B260:01C8789E] Subject: Re: [PCN] PCN IETF 71 agenda 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I would like some agenda time to progress the discussion on the encoding draft according to the proposal below. I would present the main 3 options that we have on the table, only considering those that require 3 encoding states (No pre-congestion, admission marked, termination marked):- The first uses 1 DSCP (to indicate PCN BA) & the ECN field (see email chain started by Kwok) The second uses 2 DSCPs & only 2 of the ECN codepoints (00 for No pre-congestion; 11 for AM & TM, depending on the DSCP) The third uses 3 DSCPs & doesn't use the ECN field I would also summarise the arguments made to date for and against each of these options. The floor would then be opened for full discussion of each of the options. The purpose would be to understand the proposals better & hopefully move towards building consensus round one of them, since the WG must standardise exactly one encoding. Yours, Toby. ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 22 February 2008 15:32 > To: pcn > Subject: [PCN] PCN IETF 71 agenda > > PCN currently has two meeting slots scheduled for IETF 71 - > Philidelphia: > > Tuesday 1520-1720 > Thursday 0900-1130 > > Please send your requests for agenda time to the chairs. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 00:40:49 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944C93A6DCE; Wed, 27 Feb 2008 00:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 yUrLbClS+jNt; Wed, 27 Feb 2008 00:40:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FF93A6DD2; Wed, 27 Feb 2008 00:40:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626DC3A6DCE for ; Wed, 27 Feb 2008 00:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YpkVh2vbdhk for ; Wed, 27 Feb 2008 00:40:42 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id F2C7E3A6DCB for ; Wed, 27 Feb 2008 00:40:41 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Wed, 27 Feb 2008 09:40:23 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 09:40:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 09:41:26 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8C973@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCAAAMoNQAAAbpBgAADcaAAAIGJWUA== References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: , , X-OriginalArrivalTime: 27 Feb 2008 08:40:23.0071 (UTC) FILETIME=[64690AF0:01C8791C] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, Georgios, wasn't there a decision in Vancouver to stop work on probing and leave the description in the architecture document as it is? Regards, Rudiger | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | Sent: Tuesday, February 26, 2008 6:16 PM | To: karagian@cs.utwente.nl; steven.blake@ericsson.com | Cc: pcn@ietf.org | Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | | Sorry, to repeat: | | I still have not the foggiest idea why on earth someone would | want or need or be interested in the interior node handling | probe pkts differently from the way it handles probe pkts. | | So far you have answered a different question, about whether | it would be possible for someone to devise pcn so that an | interior node could distinguish probe pkts from data pkts. As | you say, a router alert option could indeed be used. | | > -----Original Message----- | > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > Sent: 26 February 2008 17:06 | > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com | > Cc: pcn@ietf.org | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > Hi Phil | > | > * Regarding Routing NOT, | > * Regarding scheduling, NOT | > * Regarding PCN_marking, it could be handled differently: | > | > ** if excess rate marking is used AND the PCN-interior-node is | congested | > AND | > the probe packet contains the ROUTER ALERT option THEN | > the probe packet can be distinguished from the other | PCN packets, | > and therefore it will be for sure PCN_marking encoded. | > | > ** if excess rate marking is used AND the PCN-interior-node is | congested | > AND | > the probe packet DOES NOT contain the ROUTER ALERT option | > THEN this MIGHT be PCN_marking encoded, or it MIGHT not be | > PCN_marking encoded. This depends | > on whether this probe packet is selected to represent | the excess | > rate, or is not selected. | > | > Best regards, | > Georgios | > | > | > | > | > | > > -----Original Message----- | > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > > Sent: dinsdag 26 februari 2008 17:45 | > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > > Cc: pcn@ietf.org | > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > > | > > But why would the interior node *need* to distinguish it | from other | > > pcn pkts? | > > | > > And even if you have got router alert, the architecture | draft says: | > > "must be handled the same as (ordinary data) PCN-packets, | in terms | > > of routing, scheduling and PCN-marking." | > > Even though your router alert's got it in slow path, will | it handle | > > it any differently in terms of routing scehdulign & pcn-marking? | > > | > > | > | | _______________________________________________ | PCN mailing list | PCN@ietf.org | http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 00:45:31 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65993A69B0; Wed, 27 Feb 2008 00:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 PVhNVghK2lAA; Wed, 27 Feb 2008 00:45:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728F428C526; Wed, 27 Feb 2008 00:45:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFA73A69B0 for ; Wed, 27 Feb 2008 00:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAKQLAIUCDrC for ; Wed, 27 Feb 2008 00:45:06 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 17C0428C435 for ; Wed, 27 Feb 2008 00:45:04 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 27 Feb 2008 09:44:56 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 09:44:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 09:45:59 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach4mR2YyI2bUIYES/KGXO2oFv4N1wAeLKSA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 27 Feb 2008 08:44:56.0340 (UTC) FILETIME=[074A9540:01C8791D] Cc: pcn@ietf.org Subject: [PCN] FW: draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Lars, some remarks marked [RG] in line. Regards, Rudiger -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Tuesday, February 26, 2008 6:00 PM To: ext Steven Blake Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 On 2008-2-22, at 17:29, ext Steven Blake wrote: > The chairs would like input on whether the working group has read > draft-ietf-pcn-architecture-03, and believes that it is ready for > working group last call. Please send your comments to this list. The document does a tremendous job of outlining the PCN architecture - nice job. I don't think it is ready for WGLC yet, however. This is, because there are still several places where it simply lists options for doing things that are still under discussion, and for which the WG needs to come to consensus on *one* option. I'm not faulting the document or the authors; this is merely a reflection of the WG not having come to consensus yet. Lars Detailed comments: Section 1., paragraph 9: [snip, no comment on that one from me here] Section 1., paragraph 19: > o Depending on the deployment scenario, the decision-making > functionality (about flow admission and termination) could reside > at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at > some central control node in the PCN-domain. [Lars] It is important to discuss somewhere that some choices here are less optimal than others. A good decision-making location is where PCN information naturally accumulates, e.g. at the egress. Any relocation of that decision-making requires additional communication, which increases the delay of the control loop and makes the system more brittle, because correct operation now requires dependable communication between the egress and the decision-making point. I'd like to suggest that we attempt to come to consensus on whether we can focus on a single decision point for PCN. [RG] The per flow signaling must reside at the ingress by our actual specification (see section 1, first bullet point) and to make admission control work, the egress must signal to the ingress anyway. It is Section 1., paragraph 21: > o The PCN-domain extends to the end users. The scenario is > described in [I-D.babiarz-pcn-sip-cap]. A variant is that the > PCN-domain extends out as far as the LAN edge switch. [Lars] This deployment model may not be possible under the initial charter, or maybe even under an extended charter, because it is not clear that sufficient statistical multiplexing exists on the links near the edge to make PCN work, which is a *fundamental* assumption of PCN (see assumption 3 in Section 3). Listing this deployment scenario here when we aren't sure how to support it raises false expectations - I'd hence propose to drop this bullet item. [RG] Lars, here two approaches must be differentiated: - application of PCN marking to support MBAC, which isn't working on links where MBAC can't be supported. Bad idea. - Forwarding packets which have been marked as pre-congested within a PCN domain to an end system to signal network pre-congestion status to it (similar to ECN). This is usefuls and may be feasible and should be an option for an extended charter. Section 1., paragraph 27: > From the perspective of the outside world, a PCN-domain essentially > looks like a DiffServ domain. PCN-traffic is either transported > across it transparently or policed at the PCN-ingress-node (ie > dropped or carried at a lower QoS). A couple of differences are > that: PCN-traffic has better QoS guarantees than normal DiffServ > traffic (because PCN's mechanisms better protect the QoS of admitted > flows); and in rare circumstances (failures), on the one hand some > PCN-flows may get terminated, but on the other hand other flows will > get their QoS restored. Non PCN-traffic is treated transparently, ie > the PCN-domain is a normal DiffServ domain. This paragraph would make more sense earlier in the intro. Section 3.5., paragraph 2: > The following two assumptions apply if the PCN WG decides to encode > PCN-marking in the ECN-field. Please add that any such encoding needs to conform to RFC4774. Section 4.1., paragraph 4: > NOTE: Two main categories of algorithm have been proposed: if the > algorithm uses threshold-marking then all PCN-packets are marked if > the current rate exceeds the PCN-lower-rate, whereas if the algorithm > uses excess-rate-marking the amount marked is equal to the amount in > excess of the PCN-lower-rate. However, note that this description > reflects the overall intent of the algorithm rather than its > instantaneous behaviour, since the rate measured at a particular > moment depends on the detailed algorithm, its implementation and the > traffic's variance as well as its rate (eg marking may well continue > after a recent overload even after the instantaneous rate has > dropped). [Lars] It seems important that we come to consensus on which scheme will be used for PCN before we move forward with the architecture. Otherwise, we're merely postponing a difficult decision we'll have to tackle eventually anyway. [RG] You are right. But is the architecture the document to have that decision or should the architecture state that the PCN WG will standardise just one of these alternatives and tell the reader where to find this decision?. Section 4.1., paragraph 7: > o if the PCN-egress-node receives one (or several) PCN-marked > packets, then a new flow is blocked, otherwise it is admitted. [Lars] I don't understand this - please elaborate. (Is this related to my earlier comment about the "alternative approach"?) [RG] The section should apply the terminology defined and used earlier to express that if the rate of PCN marked packets in a measured ingress egress aggregate is above an "admission stop threshold", then new flows for this aggregate are not admitted. Section 4.2., paragraph 1: > At a high level, flow termination control works as follows. Each > PCN-node PCN-marks packets in a similar fashion to above, with all > proposals using an excess-rate-marking approach (Section 4.1). An > obvious approach is for the algorithm to use a second configured > parameter, PCN-upper-rate, and a second header encoding. However > there is also a proposal to use the same rate and the same encoding. [Lars] Are we coming to consensus on which to pick moving forward? As before, I'd like us to avoid postponing difficult decisions. [RG] We MUST have different deployment options. Two points: - if your network is MPLS based, it's single codepoint marking. - if you don't want to support termination, you just need single codepoint marking. IP based networks aiming on termination may fare better with the second codepoint/threshold. But that applies just in the case of an IP based network. If PCN makes the two thresholds a requirement, then it won't see deployment in carrier backbones, it's a corporate network feature. I don't think, that's a good choice. Section 4.3., paragraph 4: > A different possibility is to configure only the PCN-lower-rate and > hence only do one type of PCN-marking, but generate admission and > flow termination responses from different levels of marking. This is > suggested in [I-D.charny-pcn-single-marking] which gives some of the > pros and cons of this approach. [Lars] draft-charny is at odds with the second paragraph of the intro, which says that each link has a PCN-lower-rate and a PCN-upper-rate. If the intent of the architecture is to permit a proposal like draft-charny, those concepts need to be re-defined. [RG] Would it be sufficient to make the PCN-upper-rate an optional feature (with mandatory requirements, if activated)? Or would the way to go be also to list different deployment scenarios? Section 4.5., paragraph 2: > o There needs to be a way for a PCN-node to distinguish PCN-traffic > from non PCN-traffic. They may be distinguished using the DSCP > field and/or ECN field. Please refer to RFC4774 again. Section 5.3., paragraph 5: > Another PCN WG document, about boundary mechanisms, will describe > PCN-metering in more detail. As described in Section 4.1 and Section > 4.2, at present there are two alternative proposals: to measure as an > aggregate (ie not per flow) all PCN-packets from a particular PCN- > ingress-node; or to monitor the PCN-traffic and react to one (or > several) PCN-marks. We refer to these approaches as "measuring PCN- > traffic" and "monitoring PCN-marks". The PCN-metering functionality > also depends on whether the measurement is targeted at admission > control or flow termination. It also depends on what encoding and > PCN-marking algorithms are specified by the PCN WG. OK, this clarifies the "alternative approach that I had two comments about above a bit more. I'd suggest to move some of that explanation earlier in the document. (But we do need to decide on which option to go with, too.) Section 5.4., paragraph 8: > The decision needs to be passed to the application layer so that it > can take the appropriate action. [Lars] The application layer at what node? And define "appropriate". [RG] You are right, I had the same question. Additionally, the information for the application layer is missing at the following section, describing termination. This should be defined for both, admission and termination, or fo none. Section 5.6., paragraph 4: > o Use a probe packet that includes as payload the address of the > PCN-ingress-node. [Lars] I don't understand how a probe packet can be used by the egress to determine the address of the ingress, if the egress needs to know this address to send the probe packet. (But see my comment on probing below; this may be moot.) [RG] There's probably some additional thought behind that on tunneling. A description to when this method is applicable should be added. Section 5.8., paragraph 0: > 5.8. Fault handling [Lars] It may be a good idea to add a paragraph that describes that re-routing must be constrained in a way that upholds the boundary of the PCN domain. In other words, re-routing MUST NOT cause traffic to enter the domain without going through a PCN ingress. [RG] No, we shouldn't touch routing, because we'll end up nowhere. We should describe however what happens in the case of a re-routing resulting in a new ingress node (that's eg standard RSVP behaviour). Section 7., paragraph 0: > 7. Probing [Lars] I am still opposed to probing as part of the PCN architecture. It is a *very* complex mechanism with lots of open issues surrounding how it could actually be implemenented that in the end serves only one purpose: to slightly increase capacity utilization in a PCN domain. However, PCN was never meant to remove the need for sufficient overprovisioning. A second reason is that probing is only really needed to extend PCN into scenarios where some of the assumptions (sufficient multiplexing, etc.) are no longer true. We already have a boatload of explicitly-signalled QoS architectures that were designed for just such scenarios. I see no reason to complicate PCN into yet another signalled-QoS system. [Lars] We already had consensus in Vancouver to stop discussing probing until after work on the initial milestones has finished. I'd like to propose to remove the discussion of probing from the architecture at least until that time. [RG] I share your doubts about probing but I must admit that we largely stopped to discuss it. To move forward, I dropped my already written concerns about probing from my mail on a possible WGLC yesterday. I can live with probing as an optional mechanism which can be activated if desired. Would that be a way forward? _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 01:18:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8675E28C547; Wed, 27 Feb 2008 01:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 U1iKElb2-MUj; Wed, 27 Feb 2008 01:18:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB74B3A6C19; Wed, 27 Feb 2008 01:18:07 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4F03A67F9 for ; Wed, 27 Feb 2008 01:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOQQ3aaXceBT for ; Wed, 27 Feb 2008 01:18:06 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C0B6D3A6976 for ; Wed, 27 Feb 2008 01:17:29 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1R9GcoT021488; Wed, 27 Feb 2008 11:17:20 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:17:12 +0200 Received: from [10.180.41.1] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:17:11 +0200 Message-Id: <52E7634C-8713-496C-BE3D-B13F04E0B0A7@nokia.com> From: Lars Eggert To: "ext Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 27 Feb 2008 11:17:08 +0200 References: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 27 Feb 2008 09:17:11.0970 (UTC) FILETIME=[89044820:01C87921] X-Nokia-AV: Clean Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, On 2008-2-27, at 10:45, ext Geib, Ruediger wrote: > [Lars] It is important to discuss somewhere that some choices here > are less > optimal than others. A good decision-making location is where PCN > information naturally accumulates, e.g. at the egress. Any > relocation > of that decision-making requires additional communication, which > increases the delay of the control loop and makes the system more > brittle, because correct operation now requires dependable > communication between the egress and the decision-making point. I'd > like to suggest that we attempt to come to consensus on whether we > can > focus on a single decision point for PCN. > > [RG] The per flow signaling must reside at the ingress by our actual > specification (see section 1, first bullet point) and to make > admission > control work, the egress must signal to the ingress anyway. It is (Sentence truncated?) I see your point. Thinking about this some more, I believe my comment was based on a different understanding on something that the architecture document currently doesn't discuss much, but probably should: What information is signaled from the egress to the ingress? We agree that the egress looks at the volume of PCN marks compared to the volume of total PCN traffic to determine the level of congestion on an ingress-egress pair. The ingress then admits or terminates flows in a way that is somehow based on that information. But what gets signaled from egress to ingress? Is it some sort of load indication? Or is it a desired behavior, i.e., "stop admit" or "start preempt"? Or something else? > Section 1., paragraph 21: >> o The PCN-domain extends to the end users. The scenario is >> described in [I-D.babiarz-pcn-sip-cap]. A variant is that the >> PCN-domain extends out as far as the LAN edge switch. > > [Lars] This deployment model may not be possible under the initial > charter, > or maybe even under an extended charter, because it is not clear > that > sufficient statistical multiplexing exists on the links near the > edge > to make PCN work, which is a *fundamental* assumption of PCN (see > assumption 3 in Section 3). Listing this deployment scenario here > when > we aren't sure how to support it raises false expectations - I'd > hence > propose to drop this bullet item. > > [RG] Lars, here two approaches must be differentiated: > - application of PCN marking to support MBAC, which isn't > working on > links where MBAC can't be supported. Bad idea. > - Forwarding packets which have been marked as pre-congested > within > a PCN domain to an end system to signal network pre-congestion > status to it (similar to ECN). This is usefuls and may be > feasible > and should be an option for an extended charter. Agreed. But the current text isn't clear as to which of these PCN will support. > Section 4.1., paragraph 4: >> NOTE: Two main categories of algorithm have been proposed: if the >> algorithm uses threshold-marking then all PCN-packets are marked if >> the current rate exceeds the PCN-lower-rate, whereas if the >> algorithm >> uses excess-rate-marking the amount marked is equal to the amount >> in >> excess of the PCN-lower-rate. However, note that this description >> reflects the overall intent of the algorithm rather than its >> instantaneous behaviour, since the rate measured at a particular >> moment depends on the detailed algorithm, its implementation and >> the >> traffic's variance as well as its rate (eg marking may well >> continue >> after a recent overload even after the instantaneous rate has >> dropped). > > [Lars] It seems important that we come to consensus on which scheme > will be > used for PCN before we move forward with the architecture. > Otherwise, > we're merely postponing a difficult decision we'll have to tackle > eventually anyway. > > [RG] You are right. But is the architecture the document to have that > decision or should the architecture state that the PCN WG will > standardise > just one of these alternatives and tell the reader where to find this > decision?. Since the WG needs to come to consensus on this at some point anyhow, I'd prefer to have this discussion earlier rather than later and document it in the architecture draft. It also seems odd to have an architecture draft that basically says "we don't know yet what this piece will look like." > Section 4.1., paragraph 7: >> o if the PCN-egress-node receives one (or several) PCN-marked >> packets, then a new flow is blocked, otherwise it is admitted. > > [Lars] I don't understand this - please elaborate. (Is this related > to my > earlier comment about the "alternative approach"?) > > [RG] The section should apply the terminology defined and used > earlier to > express that if the rate of PCN marked packets in a measured ingress > egress aggregate is above an "admission stop threshold", then new > flows > for this aggregate are not admitted. _That_ I understand :-) > Section 4.2., paragraph 1: >> At a high level, flow termination control works as follows. Each >> PCN-node PCN-marks packets in a similar fashion to above, with all >> proposals using an excess-rate-marking approach (Section 4.1). An >> obvious approach is for the algorithm to use a second configured >> parameter, PCN-upper-rate, and a second header encoding. However >> there is also a proposal to use the same rate and the same >> encoding. > > [Lars] Are we coming to consensus on which to pick moving forward? > As before, > I'd like us to avoid postponing difficult decisions. > > [RG] We MUST have different deployment options. Two points: > - if your network is MPLS based, it's single codepoint marking. > - if you don't want to support termination, you just need single > codepoint marking. > IP based networks aiming on termination may fare better with the > second codepoint/threshold. But that applies just in the case of > an IP based network. If PCN makes the two thresholds a > requirement, > then it won't see deployment in carrier backbones, it's a > corporate > network feature. I don't think, that's a good choice. OK. I think I need to rethink this point. > Section 4.3., paragraph 4: >> A different possibility is to configure only the PCN-lower-rate and >> hence only do one type of PCN-marking, but generate admission and >> flow termination responses from different levels of marking. This >> is >> suggested in [I-D.charny-pcn-single-marking] which gives some of >> the >> pros and cons of this approach. > > [Lars] draft-charny is at odds with the second paragraph of the > intro, which > says that each link has a PCN-lower-rate and a PCN-upper-rate. If > the > intent of the architecture is to permit a proposal like draft- > charny, > those concepts need to be re-defined. > > [RG] Would it be sufficient to make the PCN-upper-rate an optional > feature > (with mandatory requirements, if activated)? Or would the way to go be > also to list different deployment scenarios? I think that making the PCN-upper-rate an optional feature in this way would be the cleanest way of allowing draft-charny as well as the other options, but will require some careful editing across the entire document. > Section 5.8., paragraph 0: >> 5.8. Fault handling > > [Lars] It may be a good idea to add a paragraph that describes that > re-routing must be constrained in a way that upholds the boundary of > the PCN domain. In other words, re-routing MUST NOT cause traffic to > enter the domain without going through a PCN ingress. > > [RG] No, we shouldn't touch routing, because we'll end up nowhere. We > should describe however what happens in the case of a re-routing > resulting in a new ingress node (that's eg standard RSVP behaviour). OK. Re-reading what I wrote, this point is probably implied by the definition of PCN boundary anyway. > Section 7., paragraph 0: >> 7. Probing > > [Lars] I am still opposed to probing as part of the PCN > architecture. It is a > *very* complex mechanism with lots of open issues surrounding how it > could actually be implemenented that in the end serves only one > purpose: to slightly increase capacity utilization in a PCN domain. > However, PCN was never meant to remove the need for sufficient > overprovisioning. A second reason is that probing is only really > needed to extend PCN into scenarios where some of the assumptions > (sufficient multiplexing, etc.) are no longer true. We already > have a > boatload of explicitly-signalled QoS architectures that were > designed > for just such scenarios. I see no reason to complicate PCN into yet > another signalled-QoS system. > > [Lars] We already had consensus in Vancouver to stop discussing > probing until > after work on the initial milestones has finished. I'd like to > propose > to remove the discussion of probing from the architecture at least > until > that time. > > [RG] I share your doubts about probing but I must admit that we > largely > stopped to discuss it. To move forward, I dropped my already written > concerns about probing from my mail on a possible WGLC yesterday. I > can > live with probing as an optional mechanism which can be activated if > desired. Would that be a way forward? Even optional components of an architecture need to be fully described so they can be implemented, if so desired. I simply don't think we are at a point were we can do that for probing. And having the architecture draft say "and there's this optional mechanism that we don't quite know how to build and how to integrate with the rest of PCN" doesn't strike me as a good idea. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 02:50:13 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5053A6DB6; Wed, 27 Feb 2008 02:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 HN8uoP3VwBlO; Wed, 27 Feb 2008 02:50:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A2F3A690E; Wed, 27 Feb 2008 02:50:12 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5602C3A6A13 for ; Wed, 27 Feb 2008 02:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyo-fprdlJjm for ; Wed, 27 Feb 2008 02:50:03 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id C8B9D3A6870 for ; Wed, 27 Feb 2008 02:50:02 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 10:49:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 10:49:54 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach4mQBIaL7p7PTmRYSHvTwNloLxMAAjoT5w From: To: , X-OriginalArrivalTime: 27 Feb 2008 10:49:55.0840 (UTC) FILETIME=[7D577800:01C8792E] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Lars, Thanks for the detailed pointers on what we need to come to consensus on. And the other detailed comments. Thanks for the follow-up Rudiger. Summary:- 1. I think we have consensus on the admission marking behaviour, I'll send a separate email on this shortly. 2. I think we have consensus on the termination marking behaviour, I'll send a separate email on this shortly. Assuming that Joe is convinced by Michael's EMFT i-d. 3. in terms of edge behaviour for admission & termination, do we need consensus on one solution? Since the Charter I thought that the approach was that edge behaviour is in Info docs and that there could be more than one edge behaviour (but a single Std for interior behaviour). Anyway, there are two approaches suggested for admission (level of congestion & probing) and two for termination (measuring rates and termination based on flow being marked). I don't know how to reach consensus on doing one of each - perhaps we could have consensus on which to do first??? 4. in terms of where the decision making functionality resides, the ingress is probably more natural - since it polices flows and understands any other flow requirements that might impact the decision (such as relative importance). As to what is signalled, I guess that partly depends on what approach is being taken in point 3. the centralised node is also possible for decision making, but it's clearly understood that this is out of scope. 5. you asked about single marking. I don't know if we have consensus. My view is that the single marking approach isn't accurate enough for admission control, except perhaps as a migration step. allowing this possibility would require a bit more complexity in the edge behaviour Info doc (extra parameter configured same for all boundary nodes, tweak to termination behaviour at edges). A few follow-ups below (the rest I'll just work in). Thanks phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars > Eggert > Sent: 26 February 2008 17:00 > To: ext Steven Blake > Cc: pcn > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > Section 1., paragraph 21: > > o The PCN-domain extends to the end users. The scenario is > > described in [I-D.babiarz-pcn-sip-cap]. A variant is that the > > PCN-domain extends out as far as the LAN edge switch. > > This deployment model may not be possible under the initial charter, > or maybe even under an extended charter, because it is not clear that > sufficient statistical multiplexing exists on the links near the edge > to make PCN work, which is a *fundamental* assumption of PCN (see > assumption 3 in Section 3). Listing this deployment scenario here > when > we aren't sure how to support it raises false expectations - I'd > hence > propose to drop this bullet item. Yes, it assumes that the links near the edge have sufficient stat multiplexing. I'll move it to the Appendix, with a note that if there is sufficient stat multiplexing then it's in scope. > Section 4.3., paragraph 4: > > A different possibility is to configure only the PCN-lower-rate > and > > hence only do one type of PCN-marking, but generate admission and > > flow termination responses from different levels of marking. > This is > > suggested in [I-D.charny-pcn-single-marking] which gives some of > the > > pros and cons of this approach. > > draft-charny is at odds with the second paragraph of the intro, which > says that each link has a PCN-lower-rate and a PCN-upper-rate. If the > intent of the architecture is to permit a proposal like draft-charny, > those concepts need to be re-defined. > I'll try & clarify this. I think S4.3. (Flow admission and flow termination) needs to be clarified, and to clarify in Intro that PCN-domain doesn't have to do admission & termination, but could just do one of them. > > > Section 5.4., paragraph 8: > > The decision needs to be passed to the application layer so that > it > > can take the appropriate action. > > The application layer at what node? And define "appropriate". I think this sentence can be deleted, as it's already covered by the earlier para in S5.4: " o Communicate decision about admission " > > > Section 5.6., paragraph 4: > > o Use a probe packet that includes as payload the address of the > > PCN-ingress-node. > > I don't understand how a probe packet can be used by the egress to > determine the address of the ingress, if the egress needs to know > this > address to send the probe packet. (But see my comment on probing > below; > this may be moot.) "if the egress..." not sure I understand, it's the ingress that sends the probe pkt. The idea was that when the ingress sends the probe, it inserts into the pkt its address (ie the ingress address) - which the egress then extracts when it gets the probe. > > Section 7., paragraph 0: > > 7. Probing > > I am still opposed to probing as part of the PCN architecture. It > is a > *very* complex mechanism with lots of open issues surrounding how it > could actually be implemenented that in the end serves only one > purpose: to slightly increase capacity utilization in a PCN domain. > However, PCN was never meant to remove the need for sufficient > overprovisioning. A second reason is that probing is only really > needed to extend PCN into scenarios where some of the assumptions > (sufficient multiplexing, etc.) are no longer true. We already have a > boatload of explicitly-signalled QoS architectures that were designed > for just such scenarios. I see no reason to complicate PCN into yet > another signalled-QoS system. > > We already had consensus in Vancouver to stop discussing probing > until > after work on the initial milestones has finished. I'd like to > propose > to remove the discussion of probing from the architecture at least > until > that time. I can move the Probing section to an Appendix. Of course I could also delete it, although I guess there'll be objections to that. > > ------------------------------------------ > > NITS (only of interest to the authors) > > Nit: eliminate use of first person (throughout the document) > Nit: s/ie/i.e.,/ (everywhere) > Nit: s/eg/e.g.,/ (everywhere) they can be spelt with or without the dots. I read somewhere that without dots is the modern usage & have been a convert ever since! > > Section 2., paragraph 1: > > nodes that perform DiffServ scheduling; the compete set of PCN- > > Nit: s/compete/complete/ > > Section 4.3., paragraph 2: > > sessions end, existing microflows naturally depart from the system > > Nit: s/microflow/flow/ (or else define what a microflow is; also > elsewhere in the document) thanks, I managed to miss some. They mostly should be flow. Where it means microflow I added ref to RFC2475 (eg in the PCN-traffic definition in S2) > > _______________________________________________ > PCN mailing list > PCN@ietf.org > http://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 03:03:21 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261C828C1BB; Wed, 27 Feb 2008 03:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.239 X-Spam-Level: * X-Spam-Status: No, score=1.239 tagged_above=-999 required=5 tests=[AWL=-2.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yp7yS5ZwWSM; Wed, 27 Feb 2008 03:03:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A5A3A6CBC; Wed, 27 Feb 2008 03:03:14 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D0D3A682C for ; Wed, 27 Feb 2008 03:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj+-pgzVzBev for ; Wed, 27 Feb 2008 03:03:02 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C15DA3A6A42 for ; Wed, 27 Feb 2008 03:02:15 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:02:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 11:02:07 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EC@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN admission marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVA= From: To: X-OriginalArrivalTime: 27 Feb 2008 11:02:08.0058 (UTC) FILETIME=[31C711A0:01C87930] Subject: [PCN] PCN admission marking algorithm - consensus? 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: , Content-Type: multipart/mixed; boundary="===============2079384352==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2079384352== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87930.312ADE84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87930.312ADE84 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we have consensus on the admission marking behaviour. This is a first attempt to capture that in Stds language, is it any use? =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. =20 Meter function: Note: The meter is described as a 'token bucket with threshold', however the implementation is not standardised. For example, it could equally well be implemented as a virtual queue (which operates with negative tokens). =20 A packet classified as a PCN-packet MUST be metered as follows.=20 The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 a token bucket, which=20 1A tokens are added at the PCN-lower-rate, to a maximum TB.size 1B tokens are removed equal to the size of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" to the Mark function =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 =20 If TB.fill < size of the PCN-packet, then the meter MAY: a. leave TB.fill unaltered and indicate "admission mark" to the Mark function b. set TB.fill =3D 0 and indicate "admission mark" to the Mark function c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and if it is, then indicate "admission mark" to the Mark function =20 Note: Option a is expected to be the simplest to implement.=20 =20 =20 Mark function: If the meter indicates to "admission mark" a PCN-packet, then: [1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously "admission marked" and "termination marked": If the PCN-packet's codepoint is already "termination mark" then it MUST NOT be altered, ie the following step is not performed. [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "admission marked", as defined in [RFC-encoding] =20 =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87930.312ADE84 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think we have consensus on the = admission marking behaviour. This is a first attempt to capture that in Stds = language, is it any use?

 

 

If an interface of the PCN-domain performs =
PCN Admission Marking then it performs three functions, which are =
outlined in draft-ietf-pcn-architecture as =
follows:
 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a ‘token bucket with threshold’, however the implementation is not standardised. For = example, it could equally well be implemented as a virtual queue (which operates = with negative tokens).

 

A packet classified as a PCN-packet MUST be metered as follows. =

The interface MUST have:

[1] a configured bit rate, termed = PCN-lower-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

 

a token bucket, which

1A tokens are added at the PCN-lower-rate, to a maximum = TB.size

1B tokens are removed equal to the size of the PCN-packet, to a = minimum TB.size=3D0

2 if TB.fill < TB.threshold, then the meter indicates “admission mark” to the Mark function

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step 1

 

If TB.fill < size of the PCN-packet, then the meter = MAY:

a. leave TB.fill unaltered and indicate “admission = mark” to the Mark function

b. set TB.fill =3D 0 and indicate “admission mark” = to the Mark function    

c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and = if it is, then indicate “admission mark” to the Mark function       

Note: Option a is expected to be the simplest to implement. =

 

 

Mark function:

If the meter indicates to “admission mark” a = PCN-packet, then:

[1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously “admission marked” and “termination marked”:

If the PCN-packet’s codepoint is already = “termination mark” then it MUST NOT be altered, ie the following step is not performed.

[2] the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “admission marked”, as defined in = [RFC-encoding]

 

 

we could also add an example = algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-= comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87930.312ADE84-- --===============2079384352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============2079384352==-- From pcn-bounces@ietf.org Wed Feb 27 03:33:26 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AF93A6A65; Wed, 27 Feb 2008 03:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 ooaD8kGzatKB; Wed, 27 Feb 2008 03:33:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3570D28C250; Wed, 27 Feb 2008 03:33:21 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090FC3A6A39; Wed, 27 Feb 2008 03:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BjVGmTJblEM; Wed, 27 Feb 2008 03:33:19 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C843B3A69E7; Wed, 27 Feb 2008 03:33:18 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1RBWnIC014593; Wed, 27 Feb 2008 13:33:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:32:40 +0200 Received: from [10.180.41.1] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:32:40 +0200 Cc: Message-Id: <8FB5F525-5037-4A39-942F-FF85D7B09E39@nokia.com> From: Lars Eggert To: "ext pcn-bounces@ietf.org" In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EC@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 27 Feb 2008 13:32:30 +0200 References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EC@E03MVZ1-UKDY.domain1.systemhost.net> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 27 Feb 2008 11:32:40.0387 (UTC) FILETIME=[75EE4930:01C87934] X-Nokia-AV: Clean Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I think this is a very useful attempt at formalizing things! A few comments on specific things below. On 2008-2-27, at 13:02, ext pcn-bounces@ietf.org wrote: > Note: The PCN-node MAY implement these three functions on either its > ingoing or outgoing interfaces. The same choice MUST be made for every > PCN-node in one PCN-domain. Is there any difference in functionality or any other reason why we wouldn't just decide on one? Leaving this open means that potential users of PCN need to buy matching equipment or at least configure one more thing correctly. > Meter function: Can we agree to always add the units of the various rates and counters, i.e., whether they are in bits or packets? Some of them are already clearly identified, but not all. Doing this would improve the description. > Mark function: > > If the meter indicates to "admission mark" a PCN-packet, then: > > [1] this step is REQUIRED, unless [RFC-encoding] standardises an > encoding that allows a PCN-packet to be simultaneously "admission > marked" and "termination marked": Do you think it would make sense to wait with the architecture until a few key decisions have been reached on the encoding? That would allow us to simplify the description by avoiding constructs like "REQUIRED, unless". Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 04:33:48 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B286D28C70A; Wed, 27 Feb 2008 04:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 lWg7SbM1KKnj; Wed, 27 Feb 2008 04:33:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E4828C6A7; Wed, 27 Feb 2008 04:33:47 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704AA28C4FA; Wed, 27 Feb 2008 04:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjfP7aWSc2Ty; Wed, 27 Feb 2008 04:33:41 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id A153828C5A2; Wed, 27 Feb 2008 04:33:39 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 12:33:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 12:33:30 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <8FB5F525-5037-4A39-942F-FF85D7B09E39@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach5NI8tFaUhY3UxQsSRcFpjD+SkrAAAOUYw From: To: , X-OriginalArrivalTime: 27 Feb 2008 12:33:31.0573 (UTC) FILETIME=[F6350E50:01C8793C] Cc: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars > Eggert > Sent: 27 February 2008 11:33 > To: ext pcn-bounces@ietf.org > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN admission marking algorithm - consensus? > > Hi, > > I think this is a very useful attempt at formalizing things! > > A few comments on specific things below. > > On 2008-2-27, at 13:02, ext pcn-bounces@ietf.org wrote: > > Note: The PCN-node MAY implement these three functions on either its > > ingoing or outgoing interfaces. The same choice MUST be made for every > > PCN-node in one PCN-domain. > > Is there any difference in functionality or any other reason why we > wouldn't just decide on one? Leaving this open means that potential > users of PCN need to buy matching equipment or at least configure one > more thing correctly. No difference in functionality & I agree it would be nice to have fewer configurables. Egress seems more natural to me (if it's a real queue then naturally it's done at the egress). However, I know of existing kit where it looks like you can easily configure it to do PCN marking on the ingress interface but not on egress interface (still trying to clarify this). Not sure if this is a relevant consideration. > > > Meter function: > > Can we agree to always add the units of the various rates and > counters, i.e., whether they are in bits or packets? Some of them are > already clearly identified, but not all. Doing this would improve the > description. Yes, and should check this in terms of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 .txt Which I think means that it should meter in terms of bits (virtual queue is concerned about congestion of the line (ie bit/sec)) and mark irrespective of the pkt size. I had a quick chat with bob & believe this is what his byte-pkt-mark draft says (with the exception that if the machine architecture pads to the MTU size, then you have to interpret 'size of pkt' to mean 'size after padding'). > > > Mark function: > > > > If the meter indicates to "admission mark" a PCN-packet, then: > > > > [1] this step is REQUIRED, unless [RFC-encoding] standardises an > > encoding that allows a PCN-packet to be simultaneously "admission > > marked" and "termination marked": > > Do you think it would make sense to wait with the architecture until a > few key decisions have been reached on the encoding? That would allow > us to simplify the description by avoiding constructs like "REQUIRED, > unless". Don't think it impacts the architecture, but yes it makes sense to me that key encoding decisions are made first in order to avoid this construct. > > Lars > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Feb 27 04:58:14 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB773A6896; Wed, 27 Feb 2008 04:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 2x9qXBeiGJlR; Wed, 27 Feb 2008 04:58:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841313A689C; Wed, 27 Feb 2008 04:58:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583AB3A6A39 for ; Wed, 27 Feb 2008 04:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqmlYf1E1ViD for ; Wed, 27 Feb 2008 04:58:11 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 1057B3A68AD for ; Wed, 27 Feb 2008 04:58:11 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D2212198E27; Wed, 27 Feb 2008 13:58:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C4D75198E1E; Wed, 27 Feb 2008 13:58:03 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 61B9B198E19; Wed, 27 Feb 2008 13:58:00 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1RCw0V30523; Wed, 27 Feb 2008 13:58:00 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 18746C813A; Wed, 27 Feb 2008 13:58:00 +0100 (CET) Message-ID: <47C55E1A.4050608@informatik.uni-wuerzburg.de> Date: Wed, 27 Feb 2008 13:56:59 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EB@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, philip.eardley@bt.com wrote: > Lars, > Thanks for the detailed pointers on what we need to come to consensus > on. And the other detailed comments. > Thanks for the follow-up Rudiger. > > Summary:- > > 1. I think we have consensus on the admission marking behaviour, I'll > send a separate email on this shortly. > > 2. I think we have consensus on the termination marking behaviour, I'll > send a separate email on this shortly. Assuming that Joe is convinced by > Michael's EMFT i-d. > > 3. in terms of edge behaviour for admission & termination, do we need > consensus on one solution? Since the Charter I thought that the approach > was that edge behaviour is in Info docs and that there could be more > than one edge behaviour (but a single Std for interior behaviour). > Anyway, there are two approaches suggested for admission (level of > congestion & probing) and two for termination (measuring rates and > termination based on flow being marked). I don't know how to reach > consensus on doing one of each - perhaps we could have consensus on > which to do first??? > I think consensus is that probe based AC methods (PBAC) has lower priority than AC methods for ingress-egress aggregates. But even there we have two candidates: congestion level estimate based AC (CLEBAC, CL, 3sm) and observation based AC (OBAC, 3sm). The following document compares these methods: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-AC.pdf > 4. in terms of where the decision making functionality resides, the > ingress is probably more natural - since it polices flows and > understands any other flow requirements that might impact the decision > (such as relative importance). The ingress node is just the right place to enforce the decision. Concerning admission control (AC), it is rather simple to implement different AC decision algorithms at the egress when the egress node only signals decisions like "admission-stop" or "admission-continue" to the ingress node and the ingress node acts accordingly. Concerning flow termination (FT), this is different. With indirect measured rate termination (IMRT, CL, SM, see also Section 3 of http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth07-PCN-Eval.pdf ) only the ingress node can take decisions. With direct MRT (DMRT), either the ingress or the egress node can take the FT decision without a lot of signalling across the PCN domain. With edge-assisted marked flow termination (EMFT), only the egress node can efficiently take FT decisions. Thus, the question of the decision making location depends on the exact algorithm when we want to avoid that many parameters are signalled across the PCN domain. > As to what is signalled, I guess that > partly depends on what approach is being taken in point 3. > I agree. 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 pcn-bounces@ietf.org Wed Feb 27 05:14:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5E03A6912; Wed, 27 Feb 2008 05:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYf9Qqi74zZt; Wed, 27 Feb 2008 05:14:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D69928C199; Wed, 27 Feb 2008 05:14:08 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773F23A67F9 for ; Wed, 27 Feb 2008 05:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEZWfYm5OlBP for ; Wed, 27 Feb 2008 05:13:55 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id AA1AE3A68C8 for ; Wed, 27 Feb 2008 05:13:07 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 13:13:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Feb 2008 13:12:59 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EF@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN termination marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4A== From: To: X-OriginalArrivalTime: 27 Feb 2008 13:13:00.0599 (UTC) FILETIME=[7A41BC70:01C87942] Subject: [PCN] PCN termination marking algorithm - consensus? 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: , Content-Type: multipart/mixed; boundary="===============2044023834==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2044023834== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87942.7999FEFD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87942.7999FEFD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here also is an attempt for consensus on the termination marking behaviour. =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 [Lars has commented: do we need to allow this choice?] =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. =20 Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. =20 A packet classified as a PCN-packet MUST be metered as follows.=20 The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 a token bucket, operating in bits:=20 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill =3D 0, then the meter indicates "termination mark" to the Mark function =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 =20 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain.=20 Note: Step 1B above is still performed.=20 =20 =20 Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] =20 =20 (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. =20 (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 -PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 .txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87942.7999FEFD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here also is an attempt for consensus on the = termination marking behaviour.

 

 

 If an interface of the PCN-domain performs PCN Admission = Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows:

 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

[Lars has commented: do we need to allow this = choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if = the PCN-packet is already “termination marked”, as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. = (*)

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a ‘token bucket’, = however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST be metered as follows. =

The interface MUST have:

[1] a configured bit rate, termed = PCN-upper-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

 

a token bucket, operating in bits:

1A tokens are added at the PCN-upper-rate, to a maximum = TB.size

1B tokens are removed equal to the size in bits of the = PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter indicates “termination mark” to the Mark function

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step = 1

 

The following SHOULD be done (**) instead of Step 2 above (Step = 2 is then superfluous).

if TB.fill < maximum size of PCN-packet, then the meter = indicates “termination mark” to the Mark function

The “maximum size of PCN-packet” is the MTU in bits = of any PCN-packets in the PCN-domain.

Note: Step 1B above is still performed. =

 

 

Mark function:

If the meter indicates to “termination mark” a = PCN-packet, then:

the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “termination marked”, as defined in = [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie the termination based on = rates, rather than the 3SM termination based on marked pkts), if the meter = counts pkts that are already termination marked then there’ll be = over-termination in the event of multiple bottlenecks. However, since this option = is probably more complicated to implement than a normal classifier (?), I suggest it = is a SHOULD.

 

(**) Explanation: this captures the point that Michael = makes in http://www3.informatik.uni-wuerzburg.de/staff/= menth/Publications/Menth08-PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-bris= coe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small = pkts. However, since this option is more complicated to implement than a = normal token bucket, I suggest it is a SHOULD.

 

we could also add an example algorithm, such as that = in http://www.ietf.org/internet-drafts/draft-char= ny-pcn-comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87942.7999FEFD-- --===============2044023834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============2044023834==-- From pcn-bounces@ietf.org Wed Feb 27 05:45:31 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237D13A6CDC; Wed, 27 Feb 2008 05:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, 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 2xVvs+BE6haV; Wed, 27 Feb 2008 05:45:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3613A6A1A; Wed, 27 Feb 2008 05:45:29 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886253A6911 for ; Wed, 27 Feb 2008 05:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q51ZFf7UBMa2 for ; Wed, 27 Feb 2008 05:45:22 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 3282A28C1C0 for ; Wed, 27 Feb 2008 05:45:17 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1F405A0665; Wed, 27 Feb 2008 14:45:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 13245A0660; Wed, 27 Feb 2008 14:45:10 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D5892A065E; Wed, 27 Feb 2008 14:45:08 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1RDj8V31021; Wed, 27 Feb 2008 14:45:08 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id AD074C88D8; Wed, 27 Feb 2008 14:45:08 +0100 (CET) Message-ID: <47C56927.6030406@informatik.uni-wuerzburg.de> Date: Wed, 27 Feb 2008 14:44:07 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EF@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] PCN termination marking algorithm - consensus? 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: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > > Here also is an attempt for consensus on the termination marking = > behaviour. > > If an interface of the PCN-domain performs PCN Admission Marking then = > it performs three functions, which are outlined in = > draft-ietf-pcn-architecture as follows: > > = > o Packet classify - decide whether an incoming packet is a PCN- > packet or not. Another PCN WG document will specify encoding, > using the DSCP and/or ECN fields. > = > o PCN-meter - measure the 'amount of PCN-traffic'. The measurement > is made as an aggregate of all PCN-packets, and not per flow. > = > o PCN-mark - algorithms determine whether to PCN-mark PCN-packets > and what packet encoding is used (as specified in another PCN WG > document). > > These functions are now described in more detail. > > Note: The PCN-node MAY implement these three functions on either its = > ingoing or outgoing interfaces. The same choice MUST be made for every = > PCN-node in one PCN-domain. > > [Lars has commented: do we need to allow this choice?] > > Classify function: > > If a packet=92s ECN/DSCP fields have the value PCN, as defined in = > [RFC-encoding], then it MUST be classified as a PCN-packet. However, = > if the PCN-packet is already =93termination marked=94, as defined in = > [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) > > If a packet=92s ECN/DSCP fields do not have the value PCN, as defined in = > [RFC-encoding], then it MUST NOT be classified as a PCN-packet. > > Meter function: > > Note: The meter is described as a =91token bucket=92, however the = > implementation is not standardised. > > A packet classified as a PCN-packet MUST be metered as follows. > > The interface MUST have: > > [1] a configured bit rate, termed PCN-upper-rate > > [2] a meter for PCN-packets, which MUST have the following behaviour: > > a token bucket, operating in bits: > > 1A tokens are added at the PCN-upper-rate, to a maximum TB.size > > 1B tokens are removed equal to the size in bits of the PCN-packet, to = > a minimum TB.size=3D0 > > 2 if TB.fill =3D 0, then the meter indicates =93termination mark=94 to th= e = > Mark function > I think this is buggy because when packets are marked, they may have = already reduced the number of tokens in the bucket. The invariant of = excess marking is that the size of all non-marked packets is removed = from the token bucket but not the size of marked packets. Therefore, = this algorithm marks more packets than necessary. Correct: 1B if TB.fill Note: Step 1A can be triggered by a packet and so can be done at the = > same time as Step 1B. > > Note: Step 2 can be performed before or after step 1 > > The following SHOULD be done (**) instead of Step 2 above (Step 2 is = > then superfluous). > > if TB.fill < maximum size of PCN-packet, then the meter indicates = > =93termination mark=94 to the Mark function > > The =93maximum size of PCN-packet=94 is the MTU in bits of any PCN-packet= s = > in the PCN-domain. > > Note: Step 1B above is still performed. > > Mark function: > > If the meter indicates to =93termination mark=94 a PCN-packet, then: > > the PCN-packet=92s ECN/DSCP fields MUST be set to the codepoint = > =93termination marked=94, as defined in [RFC-encoding] > > (*) Explanation: for CL termination (ie the termination based on = > rates, rather than the 3SM termination based on marked pkts), if the = > meter counts pkts that are already termination marked then there=92ll be = > over-termination in the event of multiple bottlenecks. However, since = > this option is probably more complicated to implement than a normal = > classifier (?), I suggest it is a SHOULD. > > (**) Explanation: this captures the point that Michael makes in = > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-= PCN-MFT.pdf = > & Bob makes in = > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.= txt = > Otherwise flows with big pkts get marked more than flows with small = > pkts. However, since this option is more complicated to implement than = > a normal token bucket, I suggest it is a SHOULD. > > we could also add an example algorithm, such as that in = > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt = > Fig 10.1 = > = > on page 21. > > Comments? > > phil > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/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 pcn-bounces@ietf.org Wed Feb 27 05:51:23 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C773F28C284; Wed, 27 Feb 2008 05:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 JpGCn3E1aggd; Wed, 27 Feb 2008 05:51:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744BA3A6D6D; Wed, 27 Feb 2008 05:51:22 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2493A6D6D; Wed, 27 Feb 2008 05:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSSBBU-fRYZT; Wed, 27 Feb 2008 05:51:15 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 2CB303A68EC; Wed, 27 Feb 2008 05:51:14 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EABB9198E16; Wed, 27 Feb 2008 14:51:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DE5E4198E02; Wed, 27 Feb 2008 14:51:07 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 72544198E29; Wed, 27 Feb 2008 14:51:04 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1RDp4V31190; Wed, 27 Feb 2008 14:51:04 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 2B97EC7F1A; Wed, 27 Feb 2008 14:51:04 +0100 (CET) Message-ID: <47C56A8B.4000305@informatik.uni-wuerzburg.de> Date: Wed, 27 Feb 2008 14:50:03 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EE@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, pcn-bounces@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, philip.eardley@bt.com wrote: > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> > Lars > >> Eggert >> Sent: 27 February 2008 11:33 >> To: ext pcn-bounces@ietf.org >> Cc: pcn@ietf.org >> Subject: Re: [PCN] PCN admission marking algorithm - consensus? >> >> Hi, >> >> I think this is a very useful attempt at formalizing things! >> >> A few comments on specific things below. >> >> On 2008-2-27, at 13:02, ext pcn-bounces@ietf.org wrote: >> >>> Note: The PCN-node MAY implement these three functions on either its >>> ingoing or outgoing interfaces. The same choice MUST be made for >>> > every > >>> PCN-node in one PCN-domain. >>> >> Is there any difference in functionality or any other reason why we >> wouldn't just decide on one? Leaving this open means that potential >> users of PCN need to buy matching equipment or at least configure one >> more thing correctly. >> > > No difference in functionality & I agree it would be nice to have fewer > configurables. > Egress seems more natural to me (if it's a real queue then naturally > it's done at the egress). However, I know of existing kit where it looks > like you can easily configure it to do PCN marking on the ingress > interface but not on egress interface (still trying to clarify this). > Not sure if this is a relevant consideration. > The rational behind this was to give more freedom to possibly existing hardware when only one meter and marker per in/outgoing interface is feasible. > >>> Meter function: >>> >> Can we agree to always add the units of the various rates and >> counters, i.e., whether they are in bits or packets? Some of them are >> already clearly identified, but not all. Doing this would improve the >> description. >> > > Yes, and should check this in terms of > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 > .txt > > Which I think means that it should meter in terms of bits (virtual queue > is concerned about congestion of the line (ie bit/sec)) and mark > irrespective of the pkt size. > That's also my view: packet size dependent metering (bits/bytes) and packet size independent marking (packets of different size have the same marking probability). Regards, Michael > I had a quick chat with bob & believe this is what his byte-pkt-mark > draft says (with the exception that if the machine architecture pads to > the MTU size, then you have to interpret 'size of pkt' to mean 'size > after padding'). > > >>> Mark function: >>> >>> If the meter indicates to "admission mark" a PCN-packet, then: >>> >>> [1] this step is REQUIRED, unless [RFC-encoding] standardises an >>> encoding that allows a PCN-packet to be simultaneously "admission >>> marked" and "termination marked": >>> >> Do you think it would make sense to wait with the architecture until a >> few key decisions have been reached on the encoding? That would allow >> us to simplify the description by avoiding constructs like "REQUIRED, >> unless". >> > > Don't think it impacts the architecture, but yes it makes sense to me > that key encoding decisions are made first in order to avoid this > construct. > >> Lars >> _______________________________________________ >> 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 > -- 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 pcn-bounces@ietf.org Wed Feb 27 07:40:54 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0EA28C327; Wed, 27 Feb 2008 07:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 GjECVyQracRq; Wed, 27 Feb 2008 07:40:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8176E3A6E3C; Wed, 27 Feb 2008 07:40:50 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7423A68A6 for ; Wed, 27 Feb 2008 07:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvUxNuj6XRAF for ; Wed, 27 Feb 2008 07:40:48 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 1D76F3A6E37 for ; Wed, 27 Feb 2008 07:40:48 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m1RFee3X000632; Wed, 27 Feb 2008 09:40:41 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 09:40:40 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 09:40:40 -0600 From: Steven Blake To: "Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> References: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> Organization: Ericsson IP Infrastructure Date: Wed, 27 Feb 2008 10:40:40 -0500 Message-Id: <1204126840.3044.7.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 27 Feb 2008 15:40:40.0511 (UTC) FILETIME=[1B2D04F0:01C87957] Cc: pcn@ietf.org Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Wed, 2008-02-27 at 09:45 +0100, Geib, Ruediger wrote: > [RG] We MUST have different deployment options. Two points: > - if your network is MPLS based, it's single codepoint marking. > - if you don't want to support termination, you just need single > codepoint marking. > IP based networks aiming on termination may fare better with the > second codepoint/threshold. But that applies just in the case of > an IP based network. If PCN makes the two thresholds a requirement, > then it won't see deployment in carrier backbones, it's a corporate > network feature. I don't think, that's a good choice. Ruediger, I don't follow your comment regarding MPLS and single codepoint marking. EXP bits are scarce, but I don't see what it is that precludes using EXP codepoint to indicate three or more encoding states, perhaps through use of L-LSPs. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 27 09:46:41 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5A528C3B9; Wed, 27 Feb 2008 09:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 E9n7G95CHk1X; Wed, 27 Feb 2008 09:46:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADACD28C34F; Wed, 27 Feb 2008 09:46:40 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A418828C38F for ; Wed, 27 Feb 2008 09:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXczcnLnCd0c for ; Wed, 27 Feb 2008 09:46:33 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 27C5F28C26C for ; Wed, 27 Feb 2008 09:46:33 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m1RHkQXl028833 for ; Wed, 27 Feb 2008 11:46:26 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:46:25 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 11:46:25 -0600 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-r/ACm27lZnmumTUbxAmT" Organization: Ericsson IP Infrastructure Date: Wed, 27 Feb 2008 12:46:25 -0500 Message-Id: <1204134385.3044.15.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 27 Feb 2008 17:46:25.0834 (UTC) FILETIME=[AC89F0A0:01C87968] Subject: [PCN] IETF71 **DRAFT** Agenda 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: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --=-r/ACm27lZnmumTUbxAmT Content-Type: text/plain Content-Transfer-Encoding: 7bit This is the draft working group agenda I plan to submit this afternoon, based on the documents that we need to close on ASAP, as well as the agenda slot requests received by the chairs. Note that there is open time at the end of the second session. The goal for this IETF meeting is to finalize a design direction for PCN so that we can meet the rest of our charter milestones. It has been my experience that 20 minute slots in IETF meetings are not the best venue to review simulation results. If the best arguments in favor of a particular PCN scheme rely on simulation results, then I suggest that you get a discussion going on the list prior to the meeting. Please send comments ASAP. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-r/ACm27lZnmumTUbxAmT Content-Disposition: attachment; filename=pcn-ietf71-agenda.txt Content-Type: text/plain; name=pcn-ietf71-agenda.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF71 **DRAFT** Agenda CHAIRs: Scott Bradner Steven Blake TUESDAY, March 11, 2008 1520-1720 Afternoon Session II Franklin 5 ==================================== AGENDA: o Administrivia chairs 10 min - Blue sheets - Scribe - Agenda bash - Milestones status o Discuss open issues in draft-chan-pcn-encoding-comparison-02 Chan 20 min o Discuss encoding options Moncaster 40 min o Discuss open issues in draft-ietf-pcn-architecture-03 Eardley 50 min THURSDAY, March 13, 2008 0900-1130 Morning Session I Salon I ==================================== AGENDA: o Administrivia chairs 5 min - Blue sheets - Scribe o PCN Comparison draft-charny-pcn-comparison-00 Charny 20 min o Performance of admission control methods Menth 20 min draft-menth-pcn-performance-02 o Edge-assisted marked flow termination (EMFT) Menth 30 min draft-menth-pcn-emft-00 o Single Marking Charny 20 min draft-charny-pcn-single-marking-03 draft-zhang-pcn-performance-evaluation-02 --=-r/ACm27lZnmumTUbxAmT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --=-r/ACm27lZnmumTUbxAmT-- From pcn-bounces@ietf.org Thu Feb 28 02:20:31 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F4828C47F; Thu, 28 Feb 2008 02:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 lpwTZ-9AKKsB; Thu, 28 Feb 2008 02:20:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333E73A6B34; Thu, 28 Feb 2008 02:20:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37DD3A6B34 for ; Thu, 28 Feb 2008 02:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wiwb5haz+N3M for ; Thu, 28 Feb 2008 02:20:20 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id BA9E63A6B28 for ; Thu, 28 Feb 2008 02:20:19 -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 m1SAJl5O015459; Thu, 28 Feb 2008 11:19:58 +0100 (MET) From: "Georgios Karagiannis" To: , References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 11:19:42 +0100 Message-ID: <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach1Z7gM77lV/EzxQtSYxi1uWOTabwDIToJAAADZYuAAAEQawAABHn+AAAAbKCAAAMoNQAAAbpBgAADcaAAAVMJ5EA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 11:19:59 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Sorry for not being clear! As you know if ECMP routing is used then this might cause problems on the way of how admission control and flow termination algorithms are operating. The ECMP problem is related to the fact that flows can belong to a certain ingress-egress-aggregate, which is maintained at the ingress adn egress and that operates in admission control state or flow termination state, but that due to the ECMP routing they are not passing through the congested node. Any measures that are taken on such flows will not solve the congestion problem, since such flows are not contributing and causing the congestion in the PCN-interior-node. Now when probing is used this problem can be solved as follows. When a PCN-interior-node is congested it MUST PCN_marking encode a probe packet. Thus if an egress operates, for a certain ingress-egress-agrregate in admission control state and it receives a probe packet which belongs to a flow associated with the same ingress-egress-agrregate AND the probe packet is PCN_marking encoded, then the egress knows for sure that the probe packet passed through one or more congested PCN-interior-nodes. In this case the probe packet, and thus also the requiesting flow can be rejected. If an egress operates, for a certain ingress-egress-agrregate in admission control state and it receives a probe packet which belongs to a flow associated with the same ingress-egress-agrregate AND the probe packet is marked as not congested PCN, then the egress knows for sure that the probe packet HAS NOT PASSED through a congested PCN-interior-node due to e.g., used ECMP routing. In this case the probe packet can be accepted, since this flow, even it belongs to the ingress-egress-aggergate that operates in admission control, is not contributing and causing the congestion in the PCN-interior-node. Okay, but why one should provide the possibility to PCN-interior-nodes to distinguish between probe packets and other PCN aware user packets? This is related to which admission control and flow termination algorithms and encodings are used in the PCN-interior-nodes. If an algorithm uses one encoding state for admission control and another encoding state for flow termination then probably it is not required to provide the possibility to PC_interior-node to distinguish between probe packets and PCN aware user packets. This is because when the PCN-interior-node that operates in admission control state will AM (admission control encoding state) encode all packets, i.e., probe packets and user packets. If an algorithm uses only one encoding state for admission control and flow termionation, such as the ones used in the single marking (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to distinguish between probe packets and user data packets. This is because both algorithms SM and LC-PCN are encoding packets proportionaly to the excess rate. This means that when the PCN-interior-node opetrates in admission control state it will not SM mark all packets that are passing through the node, but only a proportion that is needed to represent the excess rate. Thus if the PCN-interior-node will not distinguish between the probe packets and other PCN aware packets, then it is not certain that the probe packet will be SM marked when the PCN-interior-node operates in admission control state. Now, if the probe packets carry a Router Alert option, and when in Admission control state, the PCN-interior-node marks all packets that are carrying a Router Alert option, then the probe packet will be for sure marked. Hope that this clarifies your question! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 februari 2008 18:16 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Sorry, to repeat: > > I still have not the foggiest idea why on earth someone would > want or need or be interested in the interior node handling > probe pkts differently from the way it handles probe pkts. > > So far you have answered a different question, about whether > it would be possible for someone to devise pcn so that an > interior node could distinguish probe pkts from data pkts. As > you say, a router alert option could indeed be used. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 26 February 2008 17:06 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi Phil > > > > * Regarding Routing NOT, > > * Regarding scheduling, NOT > > * Regarding PCN_marking, it could be handled differently: > > > > ** if excess rate marking is used AND the PCN-interior-node is > congested > > AND > > the probe packet contains the ROUTER ALERT option THEN > > the probe packet can be distinguished from the other > PCN packets, > > and therefore it will be for sure PCN_marking encoded. > > > > ** if excess rate marking is used AND the PCN-interior-node is > congested > > AND > > the probe packet DOES NOT contain the ROUTER ALERT option > > THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > > PCN_marking encoded. This depends > > on whether this probe packet is selected to represent > the excess > > rate, or is not selected. > > > > Best regards, > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: dinsdag 26 februari 2008 17:45 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > > But why would the interior node *need* to distinguish it > from other > > > pcn pkts? > > > > > > And even if you have got router alert, the architecture > draft says: > > > "must be handled the same as (ordinary data) PCN-packets, > in terms > > > of routing, scheduling and PCN-marking." > > > Even though your router alert's got it in slow path, will > it handle > > > it any differently in terms of routing scehdulign & pcn-marking? > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 02:28:26 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5210928C531; Thu, 28 Feb 2008 02:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 wEzVE9Oa33tE; Thu, 28 Feb 2008 02:28:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12A728C42E; Thu, 28 Feb 2008 02:28:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1060528C565 for ; Thu, 28 Feb 2008 02:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Jg42tEBTXr for ; Thu, 28 Feb 2008 02:28:19 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C57E73A6B6E for ; Thu, 28 Feb 2008 02:27:30 -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 m1SARHfV016186; Thu, 28 Feb 2008 11:27:20 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , "'pcn'" References: <1204134385.3044.15.camel@neutrino> Date: Thu, 28 Feb 2008 11:27:12 +0100 Message-ID: <001201c879f4$7e5240c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1204134385.3044.15.camel@neutrino> Thread-Index: Ach5aMgO807XltzAR4+1oMACRZdErgAi3kWA X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 11:27:21 +0100 (MET) Subject: Re: [PCN] IETF71 **DRAFT** Agenda 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Sorry, maybe something went wrong in communicating this, but we would also like to get a time slot (20 minutes) to present the 03 version of the LC-PCN draft. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: woensdag 27 februari 2008 18:46 > To: pcn > Subject: [PCN] IETF71 **DRAFT** Agenda > > This is the draft working group agenda I plan to submit this > afternoon, based on the documents that we need to close on > ASAP, as well as the agenda slot requests received by the > chairs. Note that there is open time at the end of the > second session. > > The goal for this IETF meeting is to finalize a design > direction for PCN so that we can meet the rest of our charter > milestones. It has been my experience that 20 minute slots > in IETF meetings are not the best venue to review simulation > results. If the best arguments in favor of a particular PCN > scheme rely on simulation results, then I suggest that you > get a discussion going on the list prior to the meeting. > > Please send comments ASAP. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 02:29:37 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F7B28C50F; Thu, 28 Feb 2008 02:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 NSWUl43TQ6NN; Thu, 28 Feb 2008 02:29:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980FE3A6B36; Thu, 28 Feb 2008 02:29:33 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09773A6A94 for ; Thu, 28 Feb 2008 02:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRTF8mtMOboq for ; Thu, 28 Feb 2008 02:29:28 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 08FD63A6B59 for ; Thu, 28 Feb 2008 02:29:28 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B603D198DAF; Thu, 28 Feb 2008 11:29:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A8CDB198DAC; Thu, 28 Feb 2008 11:29:20 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3E4E7198D98; Thu, 28 Feb 2008 11:29:17 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1SATHV08776; Thu, 28 Feb 2008 11:29:17 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DD41CC8707; Thu, 28 Feb 2008 11:29:16 +0100 (CET) Message-ID: <47C68CBF.7060408@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 11:28:15 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Georgios Karagiannis References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, is it that you want to use excess rate marking for admission control, i.e. only some of the packets are marked, but at the same time you want to guarantee that all probe packets are marked? You realize that by simple excess rate marking of data packets and by using a router alert option for probe packets to make sure that PCN nodes always mark them when corresponding links are pre-congested with regard to the admissible rate? Regards, Michael Georgios Karagiannis wrote: > Hi Phil > > Sorry for not being clear! > > As you know if ECMP routing is used then > this might cause problems on the way of how > admission control and flow termination algorithms are operating. > > The ECMP problem is related to the fact that flows can belong to a > certain ingress-egress-aggregate, which is maintained at the ingress adn > egress > and that operates in admission control state or flow termination state, but > that > due to the ECMP routing they are not passing through the congested node. > > Any measures that are taken on such flows will not solve the > congestion problem, since such flows are not contributing and causing > the congestion in the PCN-interior-node. > > Now when probing is used this problem can be solved as follows. > When a PCN-interior-node is congested it MUST PCN_marking encode a probe > packet. > > > Thus if an egress operates, for a certain ingress-egress-agrregate in > admission control > state and it receives a probe packet which belongs to a flow associated with > the same > ingress-egress-agrregate AND the probe packet is PCN_marking encoded, then > the > egress knows for sure that the probe packet passed through one or > more congested PCN-interior-nodes. In this case the probe packet, and thus > also the requiesting flow > can be rejected. > > If an egress operates, for a certain ingress-egress-agrregate in admission > control > state and it receives a probe packet which belongs to a flow associated with > the same > ingress-egress-agrregate AND the probe packet is marked as not congested > PCN, then the > egress knows for sure that the probe packet HAS NOT PASSED through a > congested PCN-interior-node > due to e.g., used ECMP routing. In this case the probe packet can be > accepted, since this flow, > even it belongs to the ingress-egress-aggergate that operates in admission > control, is > not contributing and causing the congestion in the PCN-interior-node. > > > Okay, but why one should provide the possibility to PCN-interior-nodes to > distinguish between probe packets and other PCN aware user packets? > > This is related to which admission control and flow termination > algorithms and encodings are used in the PCN-interior-nodes. > > If an algorithm uses one encoding state for admission control and another > encoding state > for flow termination then probably it is not required to > provide the possibility to PC_interior-node to distinguish between probe > packets and PCN aware user packets. > This is because when the PCN-interior-node that operates in admission > control state > will AM (admission control encoding state) > encode all packets, i.e., probe packets and user packets. > > If an algorithm uses only one encoding state for admission control and > flow termionation, such as the ones used in the single marking (SM) and > LC-PCN drafts, > then the PCN-interior-node msut be able to distinguish between probe > packets and user data packets. > > This is because both algorithms SM and LC-PCN are encoding packets > proportionaly to the excess rate. > This means that when the PCN-interior-node opetrates in admission control > state it will not SM mark > all packets that are passing through the node, but only a proportion that is > needed to > represent the excess rate. Thus if the PCN-interior-node will not > distinguish between the probe packets and other PCN aware > packets, then it is not certain that the probe packet will be SM marked when > the PCN-interior-node operates > in admission control state. > Now, if the probe packets carry a Router Alert option, and when in Admission > control state, > the PCN-interior-node marks all packets that are carrying a Router Alert > option, then the probe packet will > be for sure marked. > > Hope that this clarifies your question! > > Best regards, > Georgios > > > > > > > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: dinsdag 26 februari 2008 18:16 >> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >> Cc: pcn@ietf.org >> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >> >> Sorry, to repeat: >> >> I still have not the foggiest idea why on earth someone would >> want or need or be interested in the interior node handling >> probe pkts differently from the way it handles probe pkts. >> >> So far you have answered a different question, about whether >> it would be possible for someone to devise pcn so that an >> interior node could distinguish probe pkts from data pkts. As >> you say, a router alert option could indeed be used. >> >> >>> -----Original Message----- >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> Sent: 26 February 2008 17:06 >>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com >>> Cc: pcn@ietf.org >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>> >>> Hi Phil >>> >>> * Regarding Routing NOT, >>> * Regarding scheduling, NOT >>> * Regarding PCN_marking, it could be handled differently: >>> >>> ** if excess rate marking is used AND the PCN-interior-node is >>> >> congested >> >>> AND >>> the probe packet contains the ROUTER ALERT option THEN >>> the probe packet can be distinguished from the other >>> >> PCN packets, >> >>> and therefore it will be for sure PCN_marking encoded. >>> >>> ** if excess rate marking is used AND the PCN-interior-node is >>> >> congested >> >>> AND >>> the probe packet DOES NOT contain the ROUTER ALERT option >>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be >>> PCN_marking encoded. This depends >>> on whether this probe packet is selected to represent >>> >> the excess >> >>> rate, or is not selected. >>> >>> Best regards, >>> Georgios >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>> Sent: dinsdag 26 februari 2008 17:45 >>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>> Cc: pcn@ietf.org >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>> >>>> But why would the interior node *need* to distinguish it >>>> >> from other >> >>>> pcn pkts? >>>> >>>> And even if you have got router alert, the architecture >>>> >> draft says: >> >>>> "must be handled the same as (ordinary data) PCN-packets, >>>> >> in terms >> >>>> of routing, scheduling and PCN-marking." >>>> Even though your router alert's got it in slow path, will >>>> >> it handle >> >>>> it any differently in terms of routing scehdulign & pcn-marking? >>>> >>>> >>>> > > > _______________________________________________ > 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 02:31:24 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211313A6A94; Thu, 28 Feb 2008 02:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 wfPK91D0F668; Thu, 28 Feb 2008 02:31:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7943A67E2; Thu, 28 Feb 2008 02:31:18 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3993A6A94 for ; Thu, 28 Feb 2008 02:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq1Kd5dhdaoO for ; Thu, 28 Feb 2008 02:31:15 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 728C33A67E2 for ; Thu, 28 Feb 2008 02:31: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 m1SAV17j016476; Thu, 28 Feb 2008 11:31:06 +0100 (MET) From: "Georgios Karagiannis" To: References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> <47C68CBF.7060408@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 11:30:56 +0100 Message-ID: <001301c879f5$04ed0610$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47C68CBF.7060408@informatik.uni-wuerzburg.de> Thread-Index: Ach59M2xLSR4j76nQ/Kozw4M3anENAAABrAg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 11:31:07 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael Yes to all your questions! Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: donderdag 28 februari 2008 11:28 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; steven.blake@ericsson.com; pcn@ietf.org > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi Georgios, > > is it that you want to use excess rate marking for admission > control, i.e. only some of the packets are marked, but at the > same time you want to guarantee that all probe packets are > marked? You realize that by simple excess rate marking of > data packets and by using a router alert option for probe > packets to make sure that PCN nodes always mark them when > corresponding links are pre-congested with regard to the > admissible rate? > > Regards, > > Michael > > Georgios Karagiannis wrote: > > Hi Phil > > > > Sorry for not being clear! > > > > As you know if ECMP routing is used then this might cause > problems on > > the way of how admission control and flow termination > algorithms are > > operating. > > > > The ECMP problem is related to the fact that flows can belong to a > > certain ingress-egress-aggregate, which is maintained at > the ingress > > adn egress and that operates in admission control state or flow > > termination state, but that due to the ECMP routing they are not > > passing through the congested node. > > > > Any measures that are taken on such flows will not solve the > > congestion problem, since such flows are not contributing > and causing > > the congestion in the PCN-interior-node. > > > > Now when probing is used this problem can be solved as follows. > > When a PCN-interior-node is congested it MUST PCN_marking encode a > > probe packet. > > > > > > Thus if an egress operates, for a certain > ingress-egress-agrregate in > > admission control state and it receives a probe packet > which belongs > > to a flow associated with the same > ingress-egress-agrregate AND the > > probe packet is PCN_marking encoded, then the egress knows for sure > > that the probe packet passed through one or more congested > > PCN-interior-nodes. In this case the probe packet, and thus > also the > > requiesting flow can be rejected. > > > > If an egress operates, for a certain ingress-egress-agrregate in > > admission control state and it receives a probe packet > which belongs > > to a flow associated with the same > ingress-egress-agrregate AND the > > probe packet is marked as not congested PCN, then the > egress knows for > > sure that the probe packet HAS NOT PASSED through a congested > > PCN-interior-node due to e.g., used ECMP routing. In this case the > > probe packet can be accepted, since this flow, even it > belongs to the > > ingress-egress-aggergate that operates in admission control, is not > > contributing and causing the congestion in the PCN-interior-node. > > > > > > Okay, but why one should provide the possibility to > PCN-interior-nodes > > to distinguish between probe packets and other PCN aware > user packets? > > > > This is related to which admission control and flow termination > > algorithms and encodings are used in the PCN-interior-nodes. > > > > If an algorithm uses one encoding state for admission control and > > another encoding state for flow termination then probably it is not > > required to provide the possibility to PC_interior-node to > distinguish > > between probe packets and PCN aware user packets. > > This is because when the PCN-interior-node that operates in > admission > > control state will AM (admission control encoding state) encode all > > packets, i.e., probe packets and user packets. > > > > If an algorithm uses only one encoding state for admission > control and > > flow termionation, such as the ones used in the single marking (SM) > > and LC-PCN drafts, then the PCN-interior-node msut be able to > > distinguish between probe packets and user data packets. > > > > This is because both algorithms SM and LC-PCN are encoding packets > > proportionaly to the excess rate. > > This means that when the PCN-interior-node opetrates in admission > > control state it will not SM mark all packets that are > passing through > > the node, but only a proportion that is needed to represent > the excess > > rate. Thus if the PCN-interior-node will not distinguish > between the > > probe packets and other PCN aware packets, then it is not > certain that > > the probe packet will be SM marked when the > PCN-interior-node operates > > in admission control state. > > Now, if the probe packets carry a Router Alert option, and when in > > Admission control state, the PCN-interior-node marks all > packets that > > are carrying a Router Alert option, then the probe packet > will be for > > sure marked. > > > > Hope that this clarifies your question! > > > > Best regards, > > Georgios > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: dinsdag 26 februari 2008 18:16 > >> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >> Cc: pcn@ietf.org > >> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >> > >> Sorry, to repeat: > >> > >> I still have not the foggiest idea why on earth someone > would want or > >> need or be interested in the interior node handling probe pkts > >> differently from the way it handles probe pkts. > >> > >> So far you have answered a different question, about > whether it would > >> be possible for someone to devise pcn so that an interior > node could > >> distinguish probe pkts from data pkts. As you say, a router alert > >> option could indeed be used. > >> > >> > >>> -----Original Message----- > >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>> Sent: 26 February 2008 17:06 > >>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > >>> Cc: pcn@ietf.org > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>> > >>> Hi Phil > >>> > >>> * Regarding Routing NOT, > >>> * Regarding scheduling, NOT > >>> * Regarding PCN_marking, it could be handled differently: > >>> > >>> ** if excess rate marking is used AND the PCN-interior-node is > >>> > >> congested > >> > >>> AND > >>> the probe packet contains the ROUTER ALERT option THEN > >>> the probe packet can be distinguished from the other > >>> > >> PCN packets, > >> > >>> and therefore it will be for sure PCN_marking encoded. > >>> > >>> ** if excess rate marking is used AND the PCN-interior-node is > >>> > >> congested > >> > >>> AND > >>> the probe packet DOES NOT contain the ROUTER ALERT option > >>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > >>> PCN_marking encoded. This depends > >>> on whether this probe packet is selected to represent > >>> > >> the excess > >> > >>> rate, or is not selected. > >>> > >>> Best regards, > >>> Georgios > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>> Sent: dinsdag 26 februari 2008 17:45 > >>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>>> Cc: pcn@ietf.org > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>> > >>>> But why would the interior node *need* to distinguish it > >>>> > >> from other > >> > >>>> pcn pkts? > >>>> > >>>> And even if you have got router alert, the architecture > >>>> > >> draft says: > >> > >>>> "must be handled the same as (ordinary data) PCN-packets, > >>>> > >> in terms > >> > >>>> of routing, scheduling and PCN-marking." > >>>> Even though your router alert's got it in slow path, will > >>>> > >> it handle > >> > >>>> it any differently in terms of routing scehdulign & pcn-marking? > >>>> > >>>> > >>>> > > > > > > _______________________________________________ > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 02:45:28 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD17A28C50F; Thu, 28 Feb 2008 02:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 eNX2agQJbgxd; Thu, 28 Feb 2008 02:45:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDEF3A6B36; Thu, 28 Feb 2008 02:45:27 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE413A68CF for ; Thu, 28 Feb 2008 02:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kYDNaCbp65q for ; Thu, 28 Feb 2008 02:45:13 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6F6BF3A6BD8 for ; Thu, 28 Feb 2008 02:45:12 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1SAi0gl014062; Thu, 28 Feb 2008 12:44:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:44:41 +0200 Received: from [10.180.41.5] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 12:44:40 +0200 Message-Id: <34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com> From: Lars Eggert To: ext Georgios Karagiannis In-Reply-To: <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 12:44:35 +0200 References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 28 Feb 2008 10:44:41.0111 (UTC) FILETIME=[EC296270:01C879F6] X-Nokia-AV: Clean Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I'm not sure if I have fully digested this yet, but it seems like this proposal defines different semantics for what the PCN marks mean to both the interior and egress nodes, depending on whether a packet is a probe packet or not. That seems to add significant complexity. Lars On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > Hi Phil > > Sorry for not being clear! > > As you know if ECMP routing is used then > this might cause problems on the way of how > admission control and flow termination algorithms are operating. > > The ECMP problem is related to the fact that flows can belong to a > certain ingress-egress-aggregate, which is maintained at the ingress > adn > egress > and that operates in admission control state or flow termination > state, but > that > due to the ECMP routing they are not passing through the congested > node. > > Any measures that are taken on such flows will not solve the > congestion problem, since such flows are not contributing and causing > the congestion in the PCN-interior-node. > > Now when probing is used this problem can be solved as follows. > When a PCN-interior-node is congested it MUST PCN_marking encode a > probe > packet. > > > Thus if an egress operates, for a certain ingress-egress-agrregate in > admission control > state and it receives a probe packet which belongs to a flow > associated with > the same > ingress-egress-agrregate AND the probe packet is PCN_marking > encoded, then > the > egress knows for sure that the probe packet passed through one or > more congested PCN-interior-nodes. In this case the probe packet, > and thus > also the requiesting flow > can be rejected. > > If an egress operates, for a certain ingress-egress-agrregate in > admission > control > state and it receives a probe packet which belongs to a flow > associated with > the same > ingress-egress-agrregate AND the probe packet is marked as not > congested > PCN, then the > egress knows for sure that the probe packet HAS NOT PASSED through a > congested PCN-interior-node > due to e.g., used ECMP routing. In this case the probe packet can be > accepted, since this flow, > even it belongs to the ingress-egress-aggergate that operates in > admission > control, is > not contributing and causing the congestion in the PCN-interior-node. > > > Okay, but why one should provide the possibility to PCN-interior- > nodes to > distinguish between probe packets and other PCN aware user packets? > > This is related to which admission control and flow termination > algorithms and encodings are used in the PCN-interior-nodes. > > If an algorithm uses one encoding state for admission control and > another > encoding state > for flow termination then probably it is not required to > provide the possibility to PC_interior-node to distinguish between > probe > packets and PCN aware user packets. > This is because when the PCN-interior-node that operates in admission > control state > will AM (admission control encoding state) > encode all packets, i.e., probe packets and user packets. > > If an algorithm uses only one encoding state for admission control and > flow termionation, such as the ones used in the single marking (SM) > and > LC-PCN drafts, > then the PCN-interior-node msut be able to distinguish between probe > packets and user data packets. > > This is because both algorithms SM and LC-PCN are encoding packets > proportionaly to the excess rate. > This means that when the PCN-interior-node opetrates in admission > control > state it will not SM mark > all packets that are passing through the node, but only a proportion > that is > needed to > represent the excess rate. Thus if the PCN-interior-node will not > distinguish between the probe packets and other PCN aware > packets, then it is not certain that the probe packet will be SM > marked when > the PCN-interior-node operates > in admission control state. > Now, if the probe packets carry a Router Alert option, and when in > Admission > control state, > the PCN-interior-node marks all packets that are carrying a Router > Alert > option, then the probe packet will > be for sure marked. > > Hope that this clarifies your question! > > Best regards, > Georgios > > > > > > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: dinsdag 26 februari 2008 18:16 >> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >> Cc: pcn@ietf.org >> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >> >> Sorry, to repeat: >> >> I still have not the foggiest idea why on earth someone would >> want or need or be interested in the interior node handling >> probe pkts differently from the way it handles probe pkts. >> >> So far you have answered a different question, about whether >> it would be possible for someone to devise pcn so that an >> interior node could distinguish probe pkts from data pkts. As >> you say, a router alert option could indeed be used. >> >>> -----Original Message----- >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> Sent: 26 February 2008 17:06 >>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com >>> Cc: pcn@ietf.org >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>> >>> Hi Phil >>> >>> * Regarding Routing NOT, >>> * Regarding scheduling, NOT >>> * Regarding PCN_marking, it could be handled differently: >>> >>> ** if excess rate marking is used AND the PCN-interior-node is >> congested >>> AND >>> the probe packet contains the ROUTER ALERT option THEN >>> the probe packet can be distinguished from the other >> PCN packets, >>> and therefore it will be for sure PCN_marking encoded. >>> >>> ** if excess rate marking is used AND the PCN-interior-node is >> congested >>> AND >>> the probe packet DOES NOT contain the ROUTER ALERT option >>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be >>> PCN_marking encoded. This depends >>> on whether this probe packet is selected to represent >> the excess >>> rate, or is not selected. >>> >>> Best regards, >>> Georgios >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>> Sent: dinsdag 26 februari 2008 17:45 >>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>> Cc: pcn@ietf.org >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>> >>>> But why would the interior node *need* to distinguish it >> from other >>>> pcn pkts? >>>> >>>> And even if you have got router alert, the architecture >> draft says: >>>> "must be handled the same as (ordinary data) PCN-packets, >> in terms >>>> of routing, scheduling and PCN-marking." >>>> Even though your router alert's got it in slow path, will >> it handle >>>> it any differently in terms of routing scehdulign & pcn-marking? >>>> >>>> >>> >> > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Feb 28 02:50:56 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0323A6B9E; Thu, 28 Feb 2008 02:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 9XKk8u0luoKv; Thu, 28 Feb 2008 02:50:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113F328C15C; Thu, 28 Feb 2008 02:50:50 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AF53A6B6E for ; Thu, 28 Feb 2008 02:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztRxqj4o38EG for ; Thu, 28 Feb 2008 02:50:43 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A6E303A680F for ; Thu, 28 Feb 2008 02:50:42 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8929E198E1D; Thu, 28 Feb 2008 11:50:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7C803198E1A; Thu, 28 Feb 2008 11:50:35 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3D14B198E16; Thu, 28 Feb 2008 11:50:34 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1SAoYV09041; Thu, 28 Feb 2008 11:50:34 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 01BB8C8707; Thu, 28 Feb 2008 11:50:34 +0100 (CET) Message-ID: <47C691BC.7090407@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 11:49:32 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Lars Eggert References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl> <34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com> In-Reply-To: <34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Lars, I just want to point out that this complexity is not due to probing itself but due to the use of excess rate marking for admission control. There is no such increased complexity if probing is done in combination with exhaustive (threshold) marking for admission control. Regards, Michael Lars Eggert wrote: > Hi, > > I'm not sure if I have fully digested this yet, but it seems like this > proposal defines different semantics for what the PCN marks mean to > both the interior and egress nodes, depending on whether a packet is a > probe packet or not. That seems to add significant complexity. > > Lars > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > >> Hi Phil >> >> Sorry for not being clear! >> >> As you know if ECMP routing is used then >> this might cause problems on the way of how >> admission control and flow termination algorithms are operating. >> >> The ECMP problem is related to the fact that flows can belong to a >> certain ingress-egress-aggregate, which is maintained at the ingress >> adn >> egress >> and that operates in admission control state or flow termination >> state, but >> that >> due to the ECMP routing they are not passing through the congested >> node. >> >> Any measures that are taken on such flows will not solve the >> congestion problem, since such flows are not contributing and causing >> the congestion in the PCN-interior-node. >> >> Now when probing is used this problem can be solved as follows. >> When a PCN-interior-node is congested it MUST PCN_marking encode a >> probe >> packet. >> >> >> Thus if an egress operates, for a certain ingress-egress-agrregate in >> admission control >> state and it receives a probe packet which belongs to a flow >> associated with >> the same >> ingress-egress-agrregate AND the probe packet is PCN_marking >> encoded, then >> the >> egress knows for sure that the probe packet passed through one or >> more congested PCN-interior-nodes. In this case the probe packet, >> and thus >> also the requiesting flow >> can be rejected. >> >> If an egress operates, for a certain ingress-egress-agrregate in >> admission >> control >> state and it receives a probe packet which belongs to a flow >> associated with >> the same >> ingress-egress-agrregate AND the probe packet is marked as not >> congested >> PCN, then the >> egress knows for sure that the probe packet HAS NOT PASSED through a >> congested PCN-interior-node >> due to e.g., used ECMP routing. In this case the probe packet can be >> accepted, since this flow, >> even it belongs to the ingress-egress-aggergate that operates in >> admission >> control, is >> not contributing and causing the congestion in the PCN-interior-node. >> >> >> Okay, but why one should provide the possibility to PCN-interior- >> nodes to >> distinguish between probe packets and other PCN aware user packets? >> >> This is related to which admission control and flow termination >> algorithms and encodings are used in the PCN-interior-nodes. >> >> If an algorithm uses one encoding state for admission control and >> another >> encoding state >> for flow termination then probably it is not required to >> provide the possibility to PC_interior-node to distinguish between >> probe >> packets and PCN aware user packets. >> This is because when the PCN-interior-node that operates in admission >> control state >> will AM (admission control encoding state) >> encode all packets, i.e., probe packets and user packets. >> >> If an algorithm uses only one encoding state for admission control and >> flow termionation, such as the ones used in the single marking (SM) >> and >> LC-PCN drafts, >> then the PCN-interior-node msut be able to distinguish between probe >> packets and user data packets. >> >> This is because both algorithms SM and LC-PCN are encoding packets >> proportionaly to the excess rate. >> This means that when the PCN-interior-node opetrates in admission >> control >> state it will not SM mark >> all packets that are passing through the node, but only a proportion >> that is >> needed to >> represent the excess rate. Thus if the PCN-interior-node will not >> distinguish between the probe packets and other PCN aware >> packets, then it is not certain that the probe packet will be SM >> marked when >> the PCN-interior-node operates >> in admission control state. >> Now, if the probe packets carry a Router Alert option, and when in >> Admission >> control state, >> the PCN-interior-node marks all packets that are carrying a Router >> Alert >> option, then the probe packet will >> be for sure marked. >> >> Hope that this clarifies your question! >> >> Best regards, >> Georgios >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: dinsdag 26 februari 2008 18:16 >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>> Cc: pcn@ietf.org >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>> >>> Sorry, to repeat: >>> >>> I still have not the foggiest idea why on earth someone would >>> want or need or be interested in the interior node handling >>> probe pkts differently from the way it handles probe pkts. >>> >>> So far you have answered a different question, about whether >>> it would be possible for someone to devise pcn so that an >>> interior node could distinguish probe pkts from data pkts. As >>> you say, a router alert option could indeed be used. >>> >>> >>>> -----Original Message----- >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>> Sent: 26 February 2008 17:06 >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com >>>> Cc: pcn@ietf.org >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>> >>>> Hi Phil >>>> >>>> * Regarding Routing NOT, >>>> * Regarding scheduling, NOT >>>> * Regarding PCN_marking, it could be handled differently: >>>> >>>> ** if excess rate marking is used AND the PCN-interior-node is >>>> >>> congested >>> >>>> AND >>>> the probe packet contains the ROUTER ALERT option THEN >>>> the probe packet can be distinguished from the other >>>> >>> PCN packets, >>> >>>> and therefore it will be for sure PCN_marking encoded. >>>> >>>> ** if excess rate marking is used AND the PCN-interior-node is >>>> >>> congested >>> >>>> AND >>>> the probe packet DOES NOT contain the ROUTER ALERT option >>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be >>>> PCN_marking encoded. This depends >>>> on whether this probe packet is selected to represent >>>> >>> the excess >>> >>>> rate, or is not selected. >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>>> Sent: dinsdag 26 februari 2008 17:45 >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>>> Cc: pcn@ietf.org >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>> >>>>> But why would the interior node *need* to distinguish it >>>>> >>> from other >>> >>>>> pcn pkts? >>>>> >>>>> And even if you have got router alert, the architecture >>>>> >>> draft says: >>> >>>>> "must be handled the same as (ordinary data) PCN-packets, >>>>> >>> in terms >>> >>>>> of routing, scheduling and PCN-marking." >>>>> Even though your router alert's got it in slow path, will >>>>> >>> it handle >>> >>>>> it any differently in terms of routing scehdulign & pcn-marking? >>>>> >>>>> >>>>> >> _______________________________________________ >> 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 > -- 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 pcn-bounces@ietf.org Thu Feb 28 02:58:43 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86943A6C58; Thu, 28 Feb 2008 02:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 Jg5oasnE6k+k; Thu, 28 Feb 2008 02:58:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE863A6C34; Thu, 28 Feb 2008 02:58:36 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B375D28C1AF for ; Thu, 28 Feb 2008 02:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDQkxoX89hM8 for ; Thu, 28 Feb 2008 02:58:29 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 10E103A6D93 for ; Thu, 28 Feb 2008 02:58:00 -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 m1SAvnmx018850; Thu, 28 Feb 2008 11:57:52 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com> <47C691BC.7090407@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 11:57:44 +0100 Message-ID: <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47C691BC.7090407@informatik.uni-wuerzburg.de> Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 11:57:53 +0100 (MET) Cc: 'pcn' Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Lars Even for excess rate marking the complexity added is not signifficant. The Router Alert processing is already available in each router. The only additional complexity is related to the fact that the PCN-interior-node will PCN_marking encode the packets that are carrying a Router Alert option. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: donderdag 28 februari 2008 11:50 > To: Lars Eggert > Cc: pcn > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi Lars, > > I just want to point out that this complexity is not due to > probing itself but due to the use of excess rate marking for > admission control. > There is no such increased complexity if probing is done in > combination with exhaustive (threshold) marking for admission control. > > Regards, > > Michael > > Lars Eggert wrote: > > Hi, > > > > I'm not sure if I have fully digested this yet, but it > seems like this > > proposal defines different semantics for what the PCN marks mean to > > both the interior and egress nodes, depending on whether a > packet is a > > probe packet or not. That seems to add significant complexity. > > > > Lars > > > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > > > > >> Hi Phil > >> > >> Sorry for not being clear! > >> > >> As you know if ECMP routing is used then this might cause > problems on > >> the way of how admission control and flow termination > algorithms are > >> operating. > >> > >> The ECMP problem is related to the fact that flows can belong to a > >> certain ingress-egress-aggregate, which is maintained at > the ingress > >> adn egress and that operates in admission control state or flow > >> termination state, but that due to the ECMP routing they are not > >> passing through the congested node. > >> > >> Any measures that are taken on such flows will not solve the > >> congestion problem, since such flows are not contributing > and causing > >> the congestion in the PCN-interior-node. > >> > >> Now when probing is used this problem can be solved as follows. > >> When a PCN-interior-node is congested it MUST PCN_marking encode a > >> probe packet. > >> > >> > >> Thus if an egress operates, for a certain > ingress-egress-agrregate in > >> admission control state and it receives a probe packet > which belongs > >> to a flow associated with the same > ingress-egress-agrregate AND the > >> probe packet is PCN_marking encoded, then the egress knows > for sure > >> that the probe packet passed through one or more congested > >> PCN-interior-nodes. In this case the probe packet, and > thus also the > >> requiesting flow can be rejected. > >> > >> If an egress operates, for a certain ingress-egress-agrregate in > >> admission control state and it receives a probe packet > which belongs > >> to a flow associated with the same > ingress-egress-agrregate AND the > >> probe packet is marked as not congested PCN, then the egress knows > >> for sure that the probe packet HAS NOT PASSED through a congested > >> PCN-interior-node due to e.g., used ECMP routing. In this case the > >> probe packet can be accepted, since this flow, even it > belongs to the > >> ingress-egress-aggergate that operates in admission > control, is not > >> contributing and causing the congestion in the PCN-interior-node. > >> > >> > >> Okay, but why one should provide the possibility to PCN-interior- > >> nodes to distinguish between probe packets and other PCN > aware user > >> packets? > >> > >> This is related to which admission control and flow termination > >> algorithms and encodings are used in the PCN-interior-nodes. > >> > >> If an algorithm uses one encoding state for admission control and > >> another encoding state for flow termination then probably > it is not > >> required to provide the possibility to PC_interior-node to > >> distinguish between probe packets and PCN aware user packets. > >> This is because when the PCN-interior-node that operates > in admission > >> control state will AM (admission control encoding state) > encode all > >> packets, i.e., probe packets and user packets. > >> > >> If an algorithm uses only one encoding state for admission control > >> and flow termionation, such as the ones used in the single marking > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to > >> distinguish between probe packets and user data packets. > >> > >> This is because both algorithms SM and LC-PCN are encoding packets > >> proportionaly to the excess rate. > >> This means that when the PCN-interior-node opetrates in admission > >> control state it will not SM mark all packets that are passing > >> through the node, but only a proportion that is needed to > represent > >> the excess rate. Thus if the PCN-interior-node will not > distinguish > >> between the probe packets and other PCN aware packets, > then it is not > >> certain that the probe packet will be SM marked when the > >> PCN-interior-node operates in admission control state. > >> Now, if the probe packets carry a Router Alert option, and when in > >> Admission control state, the PCN-interior-node marks all > packets that > >> are carrying a Router Alert option, then the probe packet > will be for > >> sure marked. > >> > >> Hope that this clarifies your question! > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>> Sent: dinsdag 26 februari 2008 18:16 > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>> Cc: pcn@ietf.org > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>> > >>> Sorry, to repeat: > >>> > >>> I still have not the foggiest idea why on earth someone > would want > >>> or need or be interested in the interior node handling probe pkts > >>> differently from the way it handles probe pkts. > >>> > >>> So far you have answered a different question, about whether it > >>> would be possible for someone to devise pcn so that an > interior node > >>> could distinguish probe pkts from data pkts. As you say, a router > >>> alert option could indeed be used. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>> Sent: 26 February 2008 17:06 > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > >>>> Cc: pcn@ietf.org > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>> > >>>> Hi Phil > >>>> > >>>> * Regarding Routing NOT, > >>>> * Regarding scheduling, NOT > >>>> * Regarding PCN_marking, it could be handled differently: > >>>> > >>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>> > >>> congested > >>> > >>>> AND > >>>> the probe packet contains the ROUTER ALERT option THEN > >>>> the probe packet can be distinguished from the other > >>>> > >>> PCN packets, > >>> > >>>> and therefore it will be for sure PCN_marking encoded. > >>>> > >>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>> > >>> congested > >>> > >>>> AND > >>>> the probe packet DOES NOT contain the ROUTER ALERT option > >>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > >>>> PCN_marking encoded. This depends > >>>> on whether this probe packet is selected to represent > >>>> > >>> the excess > >>> > >>>> rate, or is not selected. > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>>> Sent: dinsdag 26 februari 2008 17:45 > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>>>> Cc: pcn@ietf.org > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>>> > >>>>> But why would the interior node *need* to distinguish it > >>>>> > >>> from other > >>> > >>>>> pcn pkts? > >>>>> > >>>>> And even if you have got router alert, the architecture > >>>>> > >>> draft says: > >>> > >>>>> "must be handled the same as (ordinary data) PCN-packets, > >>>>> > >>> in terms > >>> > >>>>> of routing, scheduling and PCN-marking." > >>>>> Even though your router alert's got it in slow path, will > >>>>> > >>> it handle > >>> > >>>>> it any differently in terms of routing scehdulign & pcn-marking? > >>>>> > >>>>> > >>>>> > >> _______________________________________________ > >> 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 > > > > -- > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 03:26:37 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9057828C377; Thu, 28 Feb 2008 03:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 x0e7+HGB-ofa; Thu, 28 Feb 2008 03:26:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADDA28C267; Thu, 28 Feb 2008 03:26:36 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1953A6B34 for ; Thu, 28 Feb 2008 03:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MdhPcuDnyyo for ; Thu, 28 Feb 2008 03:26:28 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 58D5D28C267 for ; Thu, 28 Feb 2008 03:26:28 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 28 Feb 2008 12:26:19 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 12:26:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 12:27:23 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQAADAnTA= References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com><47C691BC.7090407@informatik.uni-wuerzburg.de> <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Feb 2008 11:26:18.0823 (UTC) FILETIME=[BCE9FD70:01C879FC] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, | Even for excess rate marking the complexity added is not signifficant. | The Router Alert processing is already available in each router. | The only additional complexity is related to the fact that | the PCN-interior-node will PCN_marking encode the packets | that are carrying a Router Alert option. I understand your goal and your idea. I can't recall DiffServ to be a mechanism requiring RAO treatment from any router within a DiffServ domain. As PCN is a DiffServ based mechanism and I'm quite happy with the idea not to depend on RAO evaluation. I look at the feature you propose as a possible option. My companies network is operating with DiffServ and is using MPLS and ECMP. I'd like PCN to be standardised in a way not demanding complex software for the backbone routers (like RAO for MPLS - which you did not propose, but we also shouldn't end there). Preferably, per flow treatment intelligence should reside in edge boxes (and only there). Regards, Rudiger | Best regards, | Georgios | | | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of | > Michael Menth | > Sent: donderdag 28 februari 2008 11:50 | > To: Lars Eggert | > Cc: pcn | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > | > Hi Lars, | > | > I just want to point out that this complexity is not due to probing | > itself but due to the use of excess rate marking for admission | > control. | > There is no such increased complexity if probing is done in | > combination with exhaustive (threshold) marking for | admission control. | > | > Regards, | > | > Michael | > | > Lars Eggert wrote: | > > Hi, | > > | > > I'm not sure if I have fully digested this yet, but it | > seems like this | > > proposal defines different semantics for what the PCN | marks mean to | > > both the interior and egress nodes, depending on whether a | > packet is a | > > probe packet or not. That seems to add significant complexity. | > > | > > Lars | > > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: | > > | > > | > >> Hi Phil | > >> | > >> Sorry for not being clear! | > >> | > >> As you know if ECMP routing is used then this might cause | > problems on | > >> the way of how admission control and flow termination | > algorithms are | > >> operating. | > >> | > >> The ECMP problem is related to the fact that flows can | belong to a | > >> certain ingress-egress-aggregate, which is maintained at | > the ingress | > >> adn egress and that operates in admission control state or flow | > >> termination state, but that due to the ECMP routing they are not | > >> passing through the congested node. | > >> | > >> Any measures that are taken on such flows will not solve the | > >> congestion problem, since such flows are not contributing | > and causing | > >> the congestion in the PCN-interior-node. | > >> | > >> Now when probing is used this problem can be solved as follows. | > >> When a PCN-interior-node is congested it MUST | PCN_marking encode a | > >> probe packet. | > >> | > >> | > >> Thus if an egress operates, for a certain | > ingress-egress-agrregate in | > >> admission control state and it receives a probe packet | > which belongs | > >> to a flow associated with the same | > ingress-egress-agrregate AND the | > >> probe packet is PCN_marking encoded, then the egress knows | > for sure | > >> that the probe packet passed through one or more congested | > >> PCN-interior-nodes. In this case the probe packet, and | > thus also the | > >> requiesting flow can be rejected. | > >> | > >> If an egress operates, for a certain ingress-egress-agrregate in | > >> admission control state and it receives a probe packet | > which belongs | > >> to a flow associated with the same | > ingress-egress-agrregate AND the | > >> probe packet is marked as not congested PCN, then the | egress knows | > >> for sure that the probe packet HAS NOT PASSED through a | congested | > >> PCN-interior-node due to e.g., used ECMP routing. In | this case the | > >> probe packet can be accepted, since this flow, even it | > belongs to the | > >> ingress-egress-aggergate that operates in admission | > control, is not | > >> contributing and causing the congestion in the PCN-interior-node. | > >> | > >> | > >> Okay, but why one should provide the possibility to | PCN-interior- | > >> nodes to distinguish between probe packets and other PCN | > aware user | > >> packets? | > >> | > >> This is related to which admission control and flow termination | > >> algorithms and encodings are used in the PCN-interior-nodes. | > >> | > >> If an algorithm uses one encoding state for admission | control and | > >> another encoding state for flow termination then probably | > it is not | > >> required to provide the possibility to PC_interior-node to | > >> distinguish between probe packets and PCN aware user packets. | > >> This is because when the PCN-interior-node that operates | > in admission | > >> control state will AM (admission control encoding state) | > encode all | > >> packets, i.e., probe packets and user packets. | > >> | > >> If an algorithm uses only one encoding state for | admission control | > >> and flow termionation, such as the ones used in the | single marking | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut | be able to | > >> distinguish between probe packets and user data packets. | > >> | > >> This is because both algorithms SM and LC-PCN are | encoding packets | > >> proportionaly to the excess rate. | > >> This means that when the PCN-interior-node opetrates in | admission | > >> control state it will not SM mark all packets that are passing | > >> through the node, but only a proportion that is needed to | > represent | > >> the excess rate. Thus if the PCN-interior-node will not | > distinguish | > >> between the probe packets and other PCN aware packets, | > then it is not | > >> certain that the probe packet will be SM marked when the | > >> PCN-interior-node operates in admission control state. | > >> Now, if the probe packets carry a Router Alert option, | and when in | > >> Admission control state, the PCN-interior-node marks all | > packets that | > >> are carrying a Router Alert option, then the probe packet | > will be for | > >> sure marked. | > >> | > >> Hope that this clarifies your question! | > >> | > >> Best regards, | > >> Georgios | > >> | > >> | > >> | > >> | > >> | > >> | > >> | > >>> -----Original Message----- | > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > >>> Sent: dinsdag 26 februari 2008 18:16 | > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > >>> Cc: pcn@ietf.org | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > >>> | > >>> Sorry, to repeat: | > >>> | > >>> I still have not the foggiest idea why on earth someone | > would want | > >>> or need or be interested in the interior node handling | probe pkts | > >>> differently from the way it handles probe pkts. | > >>> | > >>> So far you have answered a different question, about whether it | > >>> would be possible for someone to devise pcn so that an | > interior node | > >>> could distinguish probe pkts from data pkts. As you | say, a router | > >>> alert option could indeed be used. | > >>> | > >>> | > >>>> -----Original Message----- | > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > >>>> Sent: 26 February 2008 17:06 | > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com | > >>>> Cc: pcn@ietf.org | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > >>>> | > >>>> Hi Phil | > >>>> | > >>>> * Regarding Routing NOT, | > >>>> * Regarding scheduling, NOT | > >>>> * Regarding PCN_marking, it could be handled differently: | > >>>> | > >>>> ** if excess rate marking is used AND the PCN-interior-node is | > >>>> | > >>> congested | > >>> | > >>>> AND | > >>>> the probe packet contains the ROUTER ALERT option THEN | > >>>> the probe packet can be distinguished from the other | > >>>> | > >>> PCN packets, | > >>> | > >>>> and therefore it will be for sure PCN_marking encoded. | > >>>> | > >>>> ** if excess rate marking is used AND the PCN-interior-node is | > >>>> | > >>> congested | > >>> | > >>>> AND | > >>>> the probe packet DOES NOT contain the ROUTER ALERT option | > >>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be | > >>>> PCN_marking encoded. This depends | > >>>> on whether this probe packet is selected to represent | > >>>> | > >>> the excess | > >>> | > >>>> rate, or is not selected. | > >>>> | > >>>> Best regards, | > >>>> Georgios | > >>>> | > >>>> | > >>>> | > >>>> | > >>>> | > >>>> | > >>>>> -----Original Message----- | > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > >>>>> Sent: dinsdag 26 februari 2008 17:45 | > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > >>>>> Cc: pcn@ietf.org | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > >>>>> | > >>>>> But why would the interior node *need* to distinguish it | > >>>>> | > >>> from other | > >>> | > >>>>> pcn pkts? | > >>>>> | > >>>>> And even if you have got router alert, the architecture | > >>>>> | > >>> draft says: | > >>> | > >>>>> "must be handled the same as (ordinary data) PCN-packets, | > >>>>> | > >>> in terms | > >>> | > >>>>> of routing, scheduling and PCN-marking." | > >>>>> Even though your router alert's got it in slow path, will | > >>>>> | > >>> it handle | > >>> | > >>>>> it any differently in terms of routing scehdulign & | pcn-marking? | > >>>>> | > >>>>> | > >>>>> | > >> _______________________________________________ | > >> 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 | > > | > | > -- | > 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 | > | | | _______________________________________________ | 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 From pcn-bounces@ietf.org Thu Feb 28 03:36:22 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6DB28C7B8; Thu, 28 Feb 2008 03:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 1e1r1hK37-sS; Thu, 28 Feb 2008 03:36:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C0028C80B; Thu, 28 Feb 2008 03:35:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A3428C80B for ; Thu, 28 Feb 2008 03:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-kE2WaXUO3u for ; Thu, 28 Feb 2008 03:35:57 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 3792D28C7F0 for ; Thu, 28 Feb 2008 03:35:44 -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 m1SBZULi022053; Thu, 28 Feb 2008 12:35:33 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com><47C691BC.7090407@informatik.uni-wuerzburg.de> <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> Date: Thu, 28 Feb 2008 12:35:26 +0100 Message-ID: <001e01c879fe$061a4c60$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQAADAnTAAAHrPEA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 12:35:34 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger I see the proposed probing feature as optional that can be used to solve the ECMP routing problem that occurs during admission control. But regarding your comment reagrding the per flow treatment, when using the Router Alert option the PCN-interior-node does not need to maintain any flow related information. If a PCN-interior-node operates in admission control state then all packets that carry a Router Alert option, e.g., RSVP PATH, will be PCN_marking encoded. In order to do this the PCN-interior-node does not need to maintain any flow related information. Bst regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 28 februari 2008 12:27 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Hi Georgios, > > | Even for excess rate marking the complexity added is not > signifficant. > | The Router Alert processing is already available in each router. > | The only additional complexity is related to the fact that the > | PCN-interior-node will PCN_marking encode the packets that are > | carrying a Router Alert option. > > I understand your goal and your idea. I can't recall DiffServ > to be a mechanism requiring RAO treatment from any router > within a DiffServ domain. As PCN is a DiffServ based > mechanism and I'm quite happy with the idea not to depend on > RAO evaluation. I look at the feature you propose as a > possible option. > > My companies network is operating with DiffServ and is using > MPLS and ECMP. I'd like PCN to be standardised in a way not > demanding complex software for the backbone routers (like RAO > for MPLS - which you did not propose, but we also shouldn't > end there). Preferably, per flow treatment intelligence > should reside in edge boxes (and only there). > > Regards, > > Rudiger > > > | Best regards, > | Georgios > | > | > | > -----Original Message----- > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | Behalf Of > | > Michael Menth > | > Sent: donderdag 28 februari 2008 11:50 > | > To: Lars Eggert > | > Cc: pcn > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > | > > | > Hi Lars, > | > > | > I just want to point out that this complexity is not due > to probing > | > itself but due to the use of excess rate marking for admission > | > control. > | > There is no such increased complexity if probing is done in > | > combination with exhaustive (threshold) marking for > | admission control. > | > > | > Regards, > | > > | > Michael > | > > | > Lars Eggert wrote: > | > > Hi, > | > > > | > > I'm not sure if I have fully digested this yet, but it > | > seems like this > | > > proposal defines different semantics for what the PCN > | marks mean to > | > > both the interior and egress nodes, depending on whether a > | > packet is a > | > > probe packet or not. That seems to add significant complexity. > | > > > | > > Lars > | > > > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > | > > > | > > > | > >> Hi Phil > | > >> > | > >> Sorry for not being clear! > | > >> > | > >> As you know if ECMP routing is used then this might cause > | > problems on > | > >> the way of how admission control and flow termination > | > algorithms are > | > >> operating. > | > >> > | > >> The ECMP problem is related to the fact that flows can > | belong to a > | > >> certain ingress-egress-aggregate, which is maintained at > | > the ingress > | > >> adn egress and that operates in admission control > state or flow > | > >> termination state, but that due to the ECMP routing > they are not > | > >> passing through the congested node. > | > >> > | > >> Any measures that are taken on such flows will not solve the > | > >> congestion problem, since such flows are not contributing > | > and causing > | > >> the congestion in the PCN-interior-node. > | > >> > | > >> Now when probing is used this problem can be solved as follows. > | > >> When a PCN-interior-node is congested it MUST > | PCN_marking encode a > | > >> probe packet. > | > >> > | > >> > | > >> Thus if an egress operates, for a certain > | > ingress-egress-agrregate in > | > >> admission control state and it receives a probe packet > | > which belongs > | > >> to a flow associated with the same > | > ingress-egress-agrregate AND the > | > >> probe packet is PCN_marking encoded, then the egress knows > | > for sure > | > >> that the probe packet passed through one or more congested > | > >> PCN-interior-nodes. In this case the probe packet, and > | > thus also the > | > >> requiesting flow can be rejected. > | > >> > | > >> If an egress operates, for a certain > ingress-egress-agrregate in > | > >> admission control state and it receives a probe packet > | > which belongs > | > >> to a flow associated with the same > | > ingress-egress-agrregate AND the > | > >> probe packet is marked as not congested PCN, then the > | egress knows > | > >> for sure that the probe packet HAS NOT PASSED through a > | congested > | > >> PCN-interior-node due to e.g., used ECMP routing. In > | this case the > | > >> probe packet can be accepted, since this flow, even it > | > belongs to the > | > >> ingress-egress-aggergate that operates in admission > | > control, is not > | > >> contributing and causing the congestion in the > PCN-interior-node. > | > >> > | > >> > | > >> Okay, but why one should provide the possibility to > | PCN-interior- > | > >> nodes to distinguish between probe packets and other PCN > | > aware user > | > >> packets? > | > >> > | > >> This is related to which admission control and flow > termination > | > >> algorithms and encodings are used in the PCN-interior-nodes. > | > >> > | > >> If an algorithm uses one encoding state for admission > | control and > | > >> another encoding state for flow termination then probably > | > it is not > | > >> required to provide the possibility to PC_interior-node to > | > >> distinguish between probe packets and PCN aware user packets. > | > >> This is because when the PCN-interior-node that operates > | > in admission > | > >> control state will AM (admission control encoding state) > | > encode all > | > >> packets, i.e., probe packets and user packets. > | > >> > | > >> If an algorithm uses only one encoding state for > | admission control > | > >> and flow termionation, such as the ones used in the > | single marking > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut > | be able to > | > >> distinguish between probe packets and user data packets. > | > >> > | > >> This is because both algorithms SM and LC-PCN are > | encoding packets > | > >> proportionaly to the excess rate. > | > >> This means that when the PCN-interior-node opetrates in > | admission > | > >> control state it will not SM mark all packets that are passing > | > >> through the node, but only a proportion that is needed to > | > represent > | > >> the excess rate. Thus if the PCN-interior-node will not > | > distinguish > | > >> between the probe packets and other PCN aware packets, > | > then it is not > | > >> certain that the probe packet will be SM marked when the > | > >> PCN-interior-node operates in admission control state. > | > >> Now, if the probe packets carry a Router Alert option, > | and when in > | > >> Admission control state, the PCN-interior-node marks all > | > packets that > | > >> are carrying a Router Alert option, then the probe packet > | > will be for > | > >> sure marked. > | > >> > | > >> Hope that this clarifies your question! > | > >> > | > >> Best regards, > | > >> Georgios > | > >> > | > >> > | > >> > | > >> > | > >> > | > >> > | > >> > | > >>> -----Original Message----- > | > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > | > >>> Sent: dinsdag 26 februari 2008 18:16 > | > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > | > >>> Cc: pcn@ietf.org > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > >>> > | > >>> Sorry, to repeat: > | > >>> > | > >>> I still have not the foggiest idea why on earth someone > | > would want > | > >>> or need or be interested in the interior node handling > | probe pkts > | > >>> differently from the way it handles probe pkts. > | > >>> > | > >>> So far you have answered a different question, about > whether it > | > >>> would be possible for someone to devise pcn so that an > | > interior node > | > >>> could distinguish probe pkts from data pkts. As you > | say, a router > | > >>> alert option could indeed be used. > | > >>> > | > >>> > | > >>>> -----Original Message----- > | > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > >>>> Sent: 26 February 2008 17:06 > | > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > | > >>>> Cc: pcn@ietf.org > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > >>>> > | > >>>> Hi Phil > | > >>>> > | > >>>> * Regarding Routing NOT, > | > >>>> * Regarding scheduling, NOT > | > >>>> * Regarding PCN_marking, it could be handled differently: > | > >>>> > | > >>>> ** if excess rate marking is used AND the > PCN-interior-node is > | > >>>> > | > >>> congested > | > >>> > | > >>>> AND > | > >>>> the probe packet contains the ROUTER ALERT option THEN > | > >>>> the probe packet can be distinguished from the other > | > >>>> > | > >>> PCN packets, > | > >>> > | > >>>> and therefore it will be for sure PCN_marking encoded. > | > >>>> > | > >>>> ** if excess rate marking is used AND the > PCN-interior-node is > | > >>>> > | > >>> congested > | > >>> > | > >>>> AND > | > >>>> the probe packet DOES NOT contain the ROUTER ALERT option > | > >>>> THEN this MIGHT be PCN_marking encoded, or it > MIGHT not be > | > >>>> PCN_marking encoded. This depends > | > >>>> on whether this probe packet is selected to represent > | > >>>> > | > >>> the excess > | > >>> > | > >>>> rate, or is not selected. > | > >>>> > | > >>>> Best regards, > | > >>>> Georgios > | > >>>> > | > >>>> > | > >>>> > | > >>>> > | > >>>> > | > >>>> > | > >>>>> -----Original Message----- > | > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > | > >>>>> Sent: dinsdag 26 februari 2008 17:45 > | > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > | > >>>>> Cc: pcn@ietf.org > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > >>>>> > | > >>>>> But why would the interior node *need* to distinguish it > | > >>>>> > | > >>> from other > | > >>> > | > >>>>> pcn pkts? > | > >>>>> > | > >>>>> And even if you have got router alert, the architecture > | > >>>>> > | > >>> draft says: > | > >>> > | > >>>>> "must be handled the same as (ordinary data) PCN-packets, > | > >>>>> > | > >>> in terms > | > >>> > | > >>>>> of routing, scheduling and PCN-marking." > | > >>>>> Even though your router alert's got it in slow path, will > | > >>>>> > | > >>> it handle > | > >>> > | > >>>>> it any differently in terms of routing scehdulign & > | pcn-marking? > | > >>>>> > | > >>>>> > | > >>>>> > | > >> _______________________________________________ > | > >> 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 > | > > > | > > | > -- > | > 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 > | > > | > | > | _______________________________________________ > | 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 From pcn-bounces@ietf.org Thu Feb 28 03:45:46 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7ACD28C377; Thu, 28 Feb 2008 03:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 QIAhF8D0FJan; Thu, 28 Feb 2008 03:45:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6283A6A40; Thu, 28 Feb 2008 03:45:29 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C596D3A6A40 for ; Thu, 28 Feb 2008 03:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeFTWxGcL7v3 for ; Thu, 28 Feb 2008 03:45:13 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id DCF5E28C73F for ; Thu, 28 Feb 2008 03:43:02 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 28 Feb 2008 12:42:55 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 12:42:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 12:43:59 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0AAAF@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001e01c879fe$061a4c60$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQAADAnTAAAHrPEAAAZuQA References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com><47C691BC.7090407@informatik.uni-wuerzburg.de> <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> <001e01c879fe$061a4c60$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Feb 2008 11:42:55.0050 (UTC) FILETIME=[0EB62AA0:01C879FF] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, sure, the routers aren't required to maintain state. I understood that, that's why my mail talks of "per flow treatment" (not of state maintenance). I generally don't favor per flow features in backbone routers. Regards, Rudiger | I see the proposed probing feature as optional that can be | used to solve the | | ECMP routing problem that occurs during admission control. | | But regarding your comment reagrding the per flow treatment, | when using the Router Alert option the PCN-interior-node does | not need to maintain any flow related information. | If a PCN-interior-node operates in admission control state | then all packets that carry a Router Alert option, e.g., RSVP | PATH, will be PCN_marking encoded. In order to do this the | PCN-interior-node does not need to maintain any flow related | information. | | Bst regards, | Georgios | | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: donderdag 28 februari 2008 12:27 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > Hi Georgios, | > | > | Even for excess rate marking the complexity added is not | > signifficant. | > | The Router Alert processing is already available in each router. | > | The only additional complexity is related to the fact that the | > | PCN-interior-node will PCN_marking encode the packets that are | > | carrying a Router Alert option. | > | > I understand your goal and your idea. I can't recall DiffServ to be a | > mechanism requiring RAO treatment from any router within a DiffServ | > domain. As PCN is a DiffServ based mechanism and I'm quite happy with | > the idea not to depend on RAO evaluation. I look at the feature you | > propose as a possible option. | > | > My companies network is operating with DiffServ and is using MPLS and | > ECMP. I'd like PCN to be standardised in a way not demanding complex | > software for the backbone routers (like RAO for MPLS - which you did | > not propose, but we also shouldn't end there). Preferably, per flow | > treatment intelligence should reside in edge boxes (and only there). | > | > Regards, | > | > Rudiger | > | > | > | Best regards, | > | Georgios | > | | > | | > | > -----Original Message----- | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | > | Behalf Of | > | > Michael Menth | > | > Sent: donderdag 28 februari 2008 11:50 | > | > To: Lars Eggert | > | > Cc: pcn | > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > | > | > | > Hi Lars, | > | > | > | > I just want to point out that this complexity is not due | > to probing | > | > itself but due to the use of excess rate marking for admission | > | > control. | > | > There is no such increased complexity if probing is done in | > | > combination with exhaustive (threshold) marking for | > | admission control. | > | > | > | > Regards, | > | > | > | > Michael | > | > | > | > Lars Eggert wrote: | > | > > Hi, | > | > > | > | > > I'm not sure if I have fully digested this yet, but it | > | > seems like this | > | > > proposal defines different semantics for what the PCN | > | marks mean to | > | > > both the interior and egress nodes, depending on whether a | > | > packet is a | > | > > probe packet or not. That seems to add significant complexity. | > | > > | > | > > Lars | > | > > | > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: | > | > > | > | > > | > | > >> Hi Phil | > | > >> | > | > >> Sorry for not being clear! | > | > >> | > | > >> As you know if ECMP routing is used then this might cause | > | > problems on | > | > >> the way of how admission control and flow termination | > | > algorithms are | > | > >> operating. | > | > >> | > | > >> The ECMP problem is related to the fact that flows can | > | belong to a | > | > >> certain ingress-egress-aggregate, which is maintained at | > | > the ingress | > | > >> adn egress and that operates in admission control | > state or flow | > | > >> termination state, but that due to the ECMP routing | > they are not | > | > >> passing through the congested node. | > | > >> | > | > >> Any measures that are taken on such flows will not solve the | > | > >> congestion problem, since such flows are not contributing | > | > and causing | > | > >> the congestion in the PCN-interior-node. | > | > >> | > | > >> Now when probing is used this problem can be solved | as follows. | > | > >> When a PCN-interior-node is congested it MUST | > | PCN_marking encode a | > | > >> probe packet. | > | > >> | > | > >> | > | > >> Thus if an egress operates, for a certain | > | > ingress-egress-agrregate in | > | > >> admission control state and it receives a probe packet | > | > which belongs | > | > >> to a flow associated with the same | > | > ingress-egress-agrregate AND the | > | > >> probe packet is PCN_marking encoded, then the egress knows | > | > for sure | > | > >> that the probe packet passed through one or more congested | > | > >> PCN-interior-nodes. In this case the probe packet, and | > | > thus also the | > | > >> requiesting flow can be rejected. | > | > >> | > | > >> If an egress operates, for a certain | > ingress-egress-agrregate in | > | > >> admission control state and it receives a probe packet | > | > which belongs | > | > >> to a flow associated with the same | > | > ingress-egress-agrregate AND the | > | > >> probe packet is marked as not congested PCN, then the | > | egress knows | > | > >> for sure that the probe packet HAS NOT PASSED through a | > | congested | > | > >> PCN-interior-node due to e.g., used ECMP routing. In | > | this case the | > | > >> probe packet can be accepted, since this flow, even it | > | > belongs to the | > | > >> ingress-egress-aggergate that operates in admission | > | > control, is not | > | > >> contributing and causing the congestion in the | > PCN-interior-node. | > | > >> | > | > >> | > | > >> Okay, but why one should provide the possibility to | > | PCN-interior- | > | > >> nodes to distinguish between probe packets and other PCN | > | > aware user | > | > >> packets? | > | > >> | > | > >> This is related to which admission control and flow | > termination | > | > >> algorithms and encodings are used in the PCN-interior-nodes. | > | > >> | > | > >> If an algorithm uses one encoding state for admission | > | control and | > | > >> another encoding state for flow termination then probably | > | > it is not | > | > >> required to provide the possibility to PC_interior-node to | > | > >> distinguish between probe packets and PCN aware user packets. | > | > >> This is because when the PCN-interior-node that operates | > | > in admission | > | > >> control state will AM (admission control encoding state) | > | > encode all | > | > >> packets, i.e., probe packets and user packets. | > | > >> | > | > >> If an algorithm uses only one encoding state for | > | admission control | > | > >> and flow termionation, such as the ones used in the | > | single marking | > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut | > | be able to | > | > >> distinguish between probe packets and user data packets. | > | > >> | > | > >> This is because both algorithms SM and LC-PCN are | > | encoding packets | > | > >> proportionaly to the excess rate. | > | > >> This means that when the PCN-interior-node opetrates in | > | admission | > | > >> control state it will not SM mark all packets that | are passing | > | > >> through the node, but only a proportion that is needed to | > | > represent | > | > >> the excess rate. Thus if the PCN-interior-node will not | > | > distinguish | > | > >> between the probe packets and other PCN aware packets, | > | > then it is not | > | > >> certain that the probe packet will be SM marked when the | > | > >> PCN-interior-node operates in admission control state. | > | > >> Now, if the probe packets carry a Router Alert option, | > | and when in | > | > >> Admission control state, the PCN-interior-node marks all | > | > packets that | > | > >> are carrying a Router Alert option, then the probe packet | > | > will be for | > | > >> sure marked. | > | > >> | > | > >> Hope that this clarifies your question! | > | > >> | > | > >> Best regards, | > | > >> Georgios | > | > >> | > | > >> | > | > >> | > | > >> | > | > >> | > | > >> | > | > >> | > | > >>> -----Original Message----- | > | > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > | > >>> Sent: dinsdag 26 februari 2008 18:16 | > | > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > | > >>> Cc: pcn@ietf.org | > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > >>> | > | > >>> Sorry, to repeat: | > | > >>> | > | > >>> I still have not the foggiest idea why on earth someone | > | > would want | > | > >>> or need or be interested in the interior node handling | > | probe pkts | > | > >>> differently from the way it handles probe pkts. | > | > >>> | > | > >>> So far you have answered a different question, about | > whether it | > | > >>> would be possible for someone to devise pcn so that an | > | > interior node | > | > >>> could distinguish probe pkts from data pkts. As you | > | say, a router | > | > >>> alert option could indeed be used. | > | > >>> | > | > >>> | > | > >>>> -----Original Message----- | > | > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > >>>> Sent: 26 February 2008 17:06 | > | > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com | > | > >>>> Cc: pcn@ietf.org | > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > >>>> | > | > >>>> Hi Phil | > | > >>>> | > | > >>>> * Regarding Routing NOT, | > | > >>>> * Regarding scheduling, NOT | > | > >>>> * Regarding PCN_marking, it could be handled differently: | > | > >>>> | > | > >>>> ** if excess rate marking is used AND the | > PCN-interior-node is | > | > >>>> | > | > >>> congested | > | > >>> | > | > >>>> AND | > | > >>>> the probe packet contains the ROUTER ALERT option THEN | > | > >>>> the probe packet can be distinguished from the other | > | > >>>> | > | > >>> PCN packets, | > | > >>> | > | > >>>> and therefore it will be for sure PCN_marking encoded. | > | > >>>> | > | > >>>> ** if excess rate marking is used AND the | > PCN-interior-node is | > | > >>>> | > | > >>> congested | > | > >>> | > | > >>>> AND | > | > >>>> the probe packet DOES NOT contain the ROUTER | ALERT option | > | > >>>> THEN this MIGHT be PCN_marking encoded, or it | > MIGHT not be | > | > >>>> PCN_marking encoded. This depends | > | > >>>> on whether this probe packet is selected to represent | > | > >>>> | > | > >>> the excess | > | > >>> | > | > >>>> rate, or is not selected. | > | > >>>> | > | > >>>> Best regards, | > | > >>>> Georgios | > | > >>>> | > | > >>>> | > | > >>>> | > | > >>>> | > | > >>>> | > | > >>>> | > | > >>>>> -----Original Message----- | > | > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > | > >>>>> Sent: dinsdag 26 februari 2008 17:45 | > | > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > | > >>>>> Cc: pcn@ietf.org | > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > >>>>> | > | > >>>>> But why would the interior node *need* to distinguish it | > | > >>>>> | > | > >>> from other | > | > >>> | > | > >>>>> pcn pkts? | > | > >>>>> | > | > >>>>> And even if you have got router alert, the architecture | > | > >>>>> | > | > >>> draft says: | > | > >>> | > | > >>>>> "must be handled the same as (ordinary data) PCN-packets, | > | > >>>>> | > | > >>> in terms | > | > >>> | > | > >>>>> of routing, scheduling and PCN-marking." | > | > >>>>> Even though your router alert's got it in slow path, will | > | > >>>>> | > | > >>> it handle | > | > >>> | > | > >>>>> it any differently in terms of routing scehdulign & | > | pcn-marking? | > | > >>>>> | > | > >>>>> | > | > >>>>> | > | > >> _______________________________________________ | > | > >> 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 | > | > > | > | > | > | > -- | > | > 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 | > | > | > | | > | | > | _______________________________________________ | > | 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 From pcn-bounces@ietf.org Thu Feb 28 03:49:33 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C75F28C4C7; Thu, 28 Feb 2008 03:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 9BP4dGwtWdx4; Thu, 28 Feb 2008 03:49:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2868328C598; Thu, 28 Feb 2008 03:49:18 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0662C28C754 for ; Thu, 28 Feb 2008 03:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3q6e8cXfKGy for ; Thu, 28 Feb 2008 03:49:10 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0F53128C781 for ; Thu, 28 Feb 2008 03:48:28 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m1SBmGAg023117; Thu, 28 Feb 2008 12:48:19 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com><47C691BC.7090407@informatik.uni-wuerzburg.de> <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> <001e01c879fe$061a4c60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AAAF@S4DE8PSAANK.mitte.t-com.de> Date: Thu, 28 Feb 2008 12:48:12 +0100 Message-ID: <002501c879ff$ceb74dc0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CE0AAAF@S4DE8PSAANK.mitte.t-com.de> Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQAADAnTAAAHrPEAAAZuQAAAAtQcA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 12:48:21 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger But is the Router Alert option processing, per flow treatment? Any packet that belongs to any flow and carries a Router Alert option is treated in the same way as all other packets that are carrying a Router Alert option. Or am I missing something here? Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 28 februari 2008 12:44 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Hi Georgios, > > sure, the routers aren't required to maintain state. I > understood that, that's why my mail talks of "per flow > treatment" (not of state maintenance). I generally don't > favor per flow features in backbone routers. > > Regards, > > Rudiger > > | I see the proposed probing feature as optional that can be used to > | solve the > | > | ECMP routing problem that occurs during admission control. > | > | But regarding your comment reagrding the per flow treatment, when > | using the Router Alert option the PCN-interior-node does > not need to > | maintain any flow related information. > | If a PCN-interior-node operates in admission control state then all > | packets that carry a Router Alert option, e.g., RSVP PATH, will be > | PCN_marking encoded. In order to do this the > PCN-interior-node does > | not need to maintain any flow related information. > | > | Bst regards, > | Georgios > | > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: donderdag 28 februari 2008 12:27 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > > | > Hi Georgios, > | > > | > | Even for excess rate marking the complexity added is not > | > signifficant. > | > | The Router Alert processing is already available in each router. > | > | The only additional complexity is related to the fact that the > | > | PCN-interior-node will PCN_marking encode the packets that are > | > | carrying a Router Alert option. > | > > | > I understand your goal and your idea. I can't recall > DiffServ to be > | > a mechanism requiring RAO treatment from any router within a > | > DiffServ domain. As PCN is a DiffServ based mechanism and > I'm quite > | > happy with the idea not to depend on RAO evaluation. I > look at the > | > feature you propose as a possible option. > | > > | > My companies network is operating with DiffServ and is using MPLS > | > and ECMP. I'd like PCN to be standardised in a way not demanding > | > complex software for the backbone routers (like RAO for > MPLS - which > | > you did not propose, but we also shouldn't end there). > Preferably, > | > per flow treatment intelligence should reside in edge > boxes (and only there). > | > > | > Regards, > | > > | > Rudiger > | > > | > > | > | Best regards, > | > | Georgios > | > | > | > | > | > | > -----Original Message----- > | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | > | Behalf Of > | > | > Michael Menth > | > | > Sent: donderdag 28 februari 2008 11:50 > | > | > To: Lars Eggert > | > | > Cc: pcn > | > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > | > | > > | > | > Hi Lars, > | > | > > | > | > I just want to point out that this complexity is not due > | > to probing > | > | > itself but due to the use of excess rate marking for > admission > | > | > control. > | > | > There is no such increased complexity if probing is done in > | > | > combination with exhaustive (threshold) marking for > | > | admission control. > | > | > > | > | > Regards, > | > | > > | > | > Michael > | > | > > | > | > Lars Eggert wrote: > | > | > > Hi, > | > | > > > | > | > > I'm not sure if I have fully digested this yet, but it > | > | > seems like this > | > | > > proposal defines different semantics for what the PCN > | > | marks mean to > | > | > > both the interior and egress nodes, depending on whether a > | > | > packet is a > | > | > > probe packet or not. That seems to add significant > complexity. > | > | > > > | > | > > Lars > | > | > > > | > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > | > | > > > | > | > > > | > | > >> Hi Phil > | > | > >> > | > | > >> Sorry for not being clear! > | > | > >> > | > | > >> As you know if ECMP routing is used then this might cause > | > | > problems on > | > | > >> the way of how admission control and flow termination > | > | > algorithms are > | > | > >> operating. > | > | > >> > | > | > >> The ECMP problem is related to the fact that flows can > | > | belong to a > | > | > >> certain ingress-egress-aggregate, which is maintained at > | > | > the ingress > | > | > >> adn egress and that operates in admission control > | > state or flow > | > | > >> termination state, but that due to the ECMP routing > | > they are not > | > | > >> passing through the congested node. > | > | > >> > | > | > >> Any measures that are taken on such flows will not > solve the > | > | > >> congestion problem, since such flows are not contributing > | > | > and causing > | > | > >> the congestion in the PCN-interior-node. > | > | > >> > | > | > >> Now when probing is used this problem can be solved > | as follows. > | > | > >> When a PCN-interior-node is congested it MUST > | > | PCN_marking encode a > | > | > >> probe packet. > | > | > >> > | > | > >> > | > | > >> Thus if an egress operates, for a certain > | > | > ingress-egress-agrregate in > | > | > >> admission control state and it receives a probe packet > | > | > which belongs > | > | > >> to a flow associated with the same > | > | > ingress-egress-agrregate AND the > | > | > >> probe packet is PCN_marking encoded, then the egress knows > | > | > for sure > | > | > >> that the probe packet passed through one or more congested > | > | > >> PCN-interior-nodes. In this case the probe packet, and > | > | > thus also the > | > | > >> requiesting flow can be rejected. > | > | > >> > | > | > >> If an egress operates, for a certain > | > ingress-egress-agrregate in > | > | > >> admission control state and it receives a probe packet > | > | > which belongs > | > | > >> to a flow associated with the same > | > | > ingress-egress-agrregate AND the > | > | > >> probe packet is marked as not congested PCN, then the > | > | egress knows > | > | > >> for sure that the probe packet HAS NOT PASSED through a > | > | congested > | > | > >> PCN-interior-node due to e.g., used ECMP routing. In > | > | this case the > | > | > >> probe packet can be accepted, since this flow, even it > | > | > belongs to the > | > | > >> ingress-egress-aggergate that operates in admission > | > | > control, is not > | > | > >> contributing and causing the congestion in the > | > PCN-interior-node. > | > | > >> > | > | > >> > | > | > >> Okay, but why one should provide the possibility to > | > | PCN-interior- > | > | > >> nodes to distinguish between probe packets and other PCN > | > | > aware user > | > | > >> packets? > | > | > >> > | > | > >> This is related to which admission control and flow > | > termination > | > | > >> algorithms and encodings are used in the > PCN-interior-nodes. > | > | > >> > | > | > >> If an algorithm uses one encoding state for admission > | > | control and > | > | > >> another encoding state for flow termination then probably > | > | > it is not > | > | > >> required to provide the possibility to PC_interior-node to > | > | > >> distinguish between probe packets and PCN aware > user packets. > | > | > >> This is because when the PCN-interior-node that operates > | > | > in admission > | > | > >> control state will AM (admission control encoding state) > | > | > encode all > | > | > >> packets, i.e., probe packets and user packets. > | > | > >> > | > | > >> If an algorithm uses only one encoding state for > | > | admission control > | > | > >> and flow termionation, such as the ones used in the > | > | single marking > | > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut > | > | be able to > | > | > >> distinguish between probe packets and user data packets. > | > | > >> > | > | > >> This is because both algorithms SM and LC-PCN are > | > | encoding packets > | > | > >> proportionaly to the excess rate. > | > | > >> This means that when the PCN-interior-node opetrates in > | > | admission > | > | > >> control state it will not SM mark all packets that > | are passing > | > | > >> through the node, but only a proportion that is needed to > | > | > represent > | > | > >> the excess rate. Thus if the PCN-interior-node will not > | > | > distinguish > | > | > >> between the probe packets and other PCN aware packets, > | > | > then it is not > | > | > >> certain that the probe packet will be SM marked when the > | > | > >> PCN-interior-node operates in admission control state. > | > | > >> Now, if the probe packets carry a Router Alert option, > | > | and when in > | > | > >> Admission control state, the PCN-interior-node marks all > | > | > packets that > | > | > >> are carrying a Router Alert option, then the probe packet > | > | > will be for > | > | > >> sure marked. > | > | > >> > | > | > >> Hope that this clarifies your question! > | > | > >> > | > | > >> Best regards, > | > | > >> Georgios > | > | > >> > | > | > >> > | > | > >> > | > | > >> > | > | > >> > | > | > >> > | > | > >> > | > | > >>> -----Original Message----- > | > | > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > | > | > >>> Sent: dinsdag 26 februari 2008 18:16 > | > | > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > | > | > >>> Cc: pcn@ietf.org > | > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > | > >>> > | > | > >>> Sorry, to repeat: > | > | > >>> > | > | > >>> I still have not the foggiest idea why on earth someone > | > | > would want > | > | > >>> or need or be interested in the interior node handling > | > | probe pkts > | > | > >>> differently from the way it handles probe pkts. > | > | > >>> > | > | > >>> So far you have answered a different question, about > | > whether it > | > | > >>> would be possible for someone to devise pcn so that an > | > | > interior node > | > | > >>> could distinguish probe pkts from data pkts. As you > | > | say, a router > | > | > >>> alert option could indeed be used. > | > | > >>> > | > | > >>> > | > | > >>>> -----Original Message----- > | > | > >>>> From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] > | > | > >>>> Sent: 26 February 2008 17:06 > | > | > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > | > | > >>>> Cc: pcn@ietf.org > | > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > | > >>>> > | > | > >>>> Hi Phil > | > | > >>>> > | > | > >>>> * Regarding Routing NOT, > | > | > >>>> * Regarding scheduling, NOT > | > | > >>>> * Regarding PCN_marking, it could be handled differently: > | > | > >>>> > | > | > >>>> ** if excess rate marking is used AND the > | > PCN-interior-node is > | > | > >>>> > | > | > >>> congested > | > | > >>> > | > | > >>>> AND > | > | > >>>> the probe packet contains the ROUTER ALERT > option THEN > | > | > >>>> the probe packet can be distinguished from the other > | > | > >>>> > | > | > >>> PCN packets, > | > | > >>> > | > | > >>>> and therefore it will be for sure > PCN_marking encoded. > | > | > >>>> > | > | > >>>> ** if excess rate marking is used AND the > | > PCN-interior-node is > | > | > >>>> > | > | > >>> congested > | > | > >>> > | > | > >>>> AND > | > | > >>>> the probe packet DOES NOT contain the ROUTER > | ALERT option > | > | > >>>> THEN this MIGHT be PCN_marking encoded, or it > | > MIGHT not be > | > | > >>>> PCN_marking encoded. This depends > | > | > >>>> on whether this probe packet is selected to represent > | > | > >>>> > | > | > >>> the excess > | > | > >>> > | > | > >>>> rate, or is not selected. > | > | > >>>> > | > | > >>>> Best regards, > | > | > >>>> Georgios > | > | > >>>> > | > | > >>>> > | > | > >>>> > | > | > >>>> > | > | > >>>> > | > | > >>>> > | > | > >>>>> -----Original Message----- > | > | > >>>>> From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > | > | > >>>>> Sent: dinsdag 26 februari 2008 17:45 > | > | > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > | > | > >>>>> Cc: pcn@ietf.org > | > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > | > | > >>>>> > | > | > >>>>> But why would the interior node *need* to distinguish it > | > | > >>>>> > | > | > >>> from other > | > | > >>> > | > | > >>>>> pcn pkts? > | > | > >>>>> > | > | > >>>>> And even if you have got router alert, the architecture > | > | > >>>>> > | > | > >>> draft says: > | > | > >>> > | > | > >>>>> "must be handled the same as (ordinary data) > PCN-packets, > | > | > >>>>> > | > | > >>> in terms > | > | > >>> > | > | > >>>>> of routing, scheduling and PCN-marking." > | > | > >>>>> Even though your router alert's got it in slow > path, will > | > | > >>>>> > | > | > >>> it handle > | > | > >>> > | > | > >>>>> it any differently in terms of routing scehdulign & > | > | pcn-marking? > | > | > >>>>> > | > | > >>>>> > | > | > >>>>> > | > | > >> _______________________________________________ > | > | > >> 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 > | > | > > > | > | > > | > | > -- > | > | > 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 > | > | > > | > | > | > | > | > | _______________________________________________ > | > | 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 From pcn-bounces@ietf.org Thu Feb 28 04:05:24 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6353A693E; Thu, 28 Feb 2008 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 ePWvbBat51Zr; Thu, 28 Feb 2008 04:05:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BFA28C35A; Thu, 28 Feb 2008 04:05:18 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5FB3A6B6E for ; Thu, 28 Feb 2008 04:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mijSIrQXgbnA for ; Thu, 28 Feb 2008 04:05:15 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 4F4233A6854 for ; Thu, 28 Feb 2008 04:05:14 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 28 Feb 2008 13:05:06 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 13:05:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 13:06:11 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0AADA@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <002501c879ff$ceb74dc0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach599ZX+SnKEbmBTgyAFvTxTSaCugAADJiQAADAnTAAAHrPEAAAZuQAAAAtQcAAAIZgkA== References: <000701c87899$d7d6b100$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345E4@E03MVZ1-UKDY.domain1.systemhost.net> <000a01c879f3$769c0790$810c5982@dynamic.ewi.utwente.nl><34330252-7F4C-407E-AEF1-C3149F52EBA6@nokia.com><47C691BC.7090407@informatik.uni-wuerzburg.de> <001a01c879f8$c232f970$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AA98@S4DE8PSAANK.mitte.t-com.de> <001e01c879fe$061a4c60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CE0AAAF@S4DE8PSAANK.mitte.t-com.de> <002501c879ff$ceb74dc0$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Feb 2008 12:05:06.0104 (UTC) FILETIME=[2814E380:01C87A02] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, that may be a philosophical question. My backbone engineering department probably answers "yes" to the question, whether the RAO means per flow treatment. I didn't ask them, but my impression is that user datagrams are supposed to remain on the fast path within our backbone. Regards, Rudiger | But is the Router Alert option processing, per flow treatment? | Any packet that belongs to any flow and carries a Router | Alert option is treated in the same way as all other packets | that are carrying a Router Alert option. | | Or am I missing something here? | | Best regards, | Georgios | | | | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: donderdag 28 februari 2008 12:44 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > Hi Georgios, | > | > sure, the routers aren't required to maintain state. I understood | > that, that's why my mail talks of "per flow treatment" (not | of state | > maintenance). I generally don't favor per flow features in backbone | > routers. | > | > Regards, | > | > Rudiger | > | > | I see the proposed probing feature as optional that can | be used to | > | solve the | > | | > | ECMP routing problem that occurs during admission control. | > | | > | But regarding your comment reagrding the per flow treatment, when | > | using the Router Alert option the PCN-interior-node does | > not need to | > | maintain any flow related information. | > | If a PCN-interior-node operates in admission control | state then all | > | packets that carry a Router Alert option, e.g., RSVP | PATH, will be | > | PCN_marking encoded. In order to do this the | > PCN-interior-node does | > | not need to maintain any flow related information. | > | | > | Bst regards, | > | Georgios | > | | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: donderdag 28 februari 2008 12:27 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > | > | > Hi Georgios, | > | > | > | > | Even for excess rate marking the complexity added is not | > | > signifficant. | > | > | The Router Alert processing is already available in | each router. | > | > | The only additional complexity is related to the fact | that the | > | > | PCN-interior-node will PCN_marking encode the packets | that are | > | > | carrying a Router Alert option. | > | > | > | > I understand your goal and your idea. I can't recall | > DiffServ to be | > | > a mechanism requiring RAO treatment from any router within a | > | > DiffServ domain. As PCN is a DiffServ based mechanism and | > I'm quite | > | > happy with the idea not to depend on RAO evaluation. I | > look at the | > | > feature you propose as a possible option. | > | > | > | > My companies network is operating with DiffServ and is | using MPLS | > | > and ECMP. I'd like PCN to be standardised in a way not | demanding | > | > complex software for the backbone routers (like RAO for | > MPLS - which | > | > you did not propose, but we also shouldn't end there). | > Preferably, | > | > per flow treatment intelligence should reside in edge | > boxes (and only there). | > | > | > | > Regards, | > | > | > | > Rudiger | > | > | > | > | > | > | Best regards, | > | > | Georgios | > | > | | > | > | | > | > | > -----Original Message----- | > | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | > | > | Behalf Of | > | > | > Michael Menth | > | > | > Sent: donderdag 28 februari 2008 11:50 | > | > | > To: Lars Eggert | > | > | > Cc: pcn | > | > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > | > | > | > | > | > Hi Lars, | > | > | > | > | > | > I just want to point out that this complexity is not due | > | > to probing | > | > | > itself but due to the use of excess rate marking for | > admission | > | > | > control. | > | > | > There is no such increased complexity if probing is done in | > | > | > combination with exhaustive (threshold) marking for | > | > | admission control. | > | > | > | > | > | > Regards, | > | > | > | > | > | > Michael | > | > | > | > | > | > Lars Eggert wrote: | > | > | > > Hi, | > | > | > > | > | > | > > I'm not sure if I have fully digested this yet, but it | > | > | > seems like this | > | > | > > proposal defines different semantics for what the PCN | > | > | marks mean to | > | > | > > both the interior and egress nodes, depending on whether a | > | > | > packet is a | > | > | > > probe packet or not. That seems to add significant | > complexity. | > | > | > > | > | > | > > Lars | > | > | > > | > | > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: | > | > | > > | > | > | > > | > | > | > >> Hi Phil | > | > | > >> | > | > | > >> Sorry for not being clear! | > | > | > >> | > | > | > >> As you know if ECMP routing is used then this might cause | > | > | > problems on | > | > | > >> the way of how admission control and flow termination | > | > | > algorithms are | > | > | > >> operating. | > | > | > >> | > | > | > >> The ECMP problem is related to the fact that flows can | > | > | belong to a | > | > | > >> certain ingress-egress-aggregate, which is maintained at | > | > | > the ingress | > | > | > >> adn egress and that operates in admission control | > | > state or flow | > | > | > >> termination state, but that due to the ECMP routing | > | > they are not | > | > | > >> passing through the congested node. | > | > | > >> | > | > | > >> Any measures that are taken on such flows will not | > solve the | > | > | > >> congestion problem, since such flows are not contributing | > | > | > and causing | > | > | > >> the congestion in the PCN-interior-node. | > | > | > >> | > | > | > >> Now when probing is used this problem can be solved | > | as follows. | > | > | > >> When a PCN-interior-node is congested it MUST | > | > | PCN_marking encode a | > | > | > >> probe packet. | > | > | > >> | > | > | > >> | > | > | > >> Thus if an egress operates, for a certain | > | > | > ingress-egress-agrregate in | > | > | > >> admission control state and it receives a probe packet | > | > | > which belongs | > | > | > >> to a flow associated with the same | > | > | > ingress-egress-agrregate AND the | > | > | > >> probe packet is PCN_marking encoded, then the | egress knows | > | > | > for sure | > | > | > >> that the probe packet passed through one or more | congested | > | > | > >> PCN-interior-nodes. In this case the probe packet, and | > | > | > thus also the | > | > | > >> requiesting flow can be rejected. | > | > | > >> | > | > | > >> If an egress operates, for a certain | > | > ingress-egress-agrregate in | > | > | > >> admission control state and it receives a probe packet | > | > | > which belongs | > | > | > >> to a flow associated with the same | > | > | > ingress-egress-agrregate AND the | > | > | > >> probe packet is marked as not congested PCN, then the | > | > | egress knows | > | > | > >> for sure that the probe packet HAS NOT PASSED through a | > | > | congested | > | > | > >> PCN-interior-node due to e.g., used ECMP routing. In | > | > | this case the | > | > | > >> probe packet can be accepted, since this flow, even it | > | > | > belongs to the | > | > | > >> ingress-egress-aggergate that operates in admission | > | > | > control, is not | > | > | > >> contributing and causing the congestion in the | > | > PCN-interior-node. | > | > | > >> | > | > | > >> | > | > | > >> Okay, but why one should provide the possibility to | > | > | PCN-interior- | > | > | > >> nodes to distinguish between probe packets and other PCN | > | > | > aware user | > | > | > >> packets? | > | > | > >> | > | > | > >> This is related to which admission control and flow | > | > termination | > | > | > >> algorithms and encodings are used in the | > PCN-interior-nodes. | > | > | > >> | > | > | > >> If an algorithm uses one encoding state for admission | > | > | control and | > | > | > >> another encoding state for flow termination then probably | > | > | > it is not | > | > | > >> required to provide the possibility to | PC_interior-node to | > | > | > >> distinguish between probe packets and PCN aware | > user packets. | > | > | > >> This is because when the PCN-interior-node that operates | > | > | > in admission | > | > | > >> control state will AM (admission control encoding state) | > | > | > encode all | > | > | > >> packets, i.e., probe packets and user packets. | > | > | > >> | > | > | > >> If an algorithm uses only one encoding state for | > | > | admission control | > | > | > >> and flow termionation, such as the ones used in the | > | > | single marking | > | > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut | > | > | be able to | > | > | > >> distinguish between probe packets and user data packets. | > | > | > >> | > | > | > >> This is because both algorithms SM and LC-PCN are | > | > | encoding packets | > | > | > >> proportionaly to the excess rate. | > | > | > >> This means that when the PCN-interior-node opetrates in | > | > | admission | > | > | > >> control state it will not SM mark all packets that | > | are passing | > | > | > >> through the node, but only a proportion that is needed to | > | > | > represent | > | > | > >> the excess rate. Thus if the PCN-interior-node will not | > | > | > distinguish | > | > | > >> between the probe packets and other PCN aware packets, | > | > | > then it is not | > | > | > >> certain that the probe packet will be SM marked when the | > | > | > >> PCN-interior-node operates in admission control state. | > | > | > >> Now, if the probe packets carry a Router Alert option, | > | > | and when in | > | > | > >> Admission control state, the PCN-interior-node marks all | > | > | > packets that | > | > | > >> are carrying a Router Alert option, then the probe packet | > | > | > will be for | > | > | > >> sure marked. | > | > | > >> | > | > | > >> Hope that this clarifies your question! | > | > | > >> | > | > | > >> Best regards, | > | > | > >> Georgios | > | > | > >> | > | > | > >> | > | > | > >> | > | > | > >> | > | > | > >> | > | > | > >> | > | > | > >> | > | > | > >>> -----Original Message----- | > | > | > >>> From: philip.eardley@bt.com | [mailto:philip.eardley@bt.com] | > | > | > >>> Sent: dinsdag 26 februari 2008 18:16 | > | > | > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > | > | > >>> Cc: pcn@ietf.org | > | > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > | > >>> | > | > | > >>> Sorry, to repeat: | > | > | > >>> | > | > | > >>> I still have not the foggiest idea why on earth someone | > | > | > would want | > | > | > >>> or need or be interested in the interior node handling | > | > | probe pkts | > | > | > >>> differently from the way it handles probe pkts. | > | > | > >>> | > | > | > >>> So far you have answered a different question, about | > | > whether it | > | > | > >>> would be possible for someone to devise pcn so that an | > | > | > interior node | > | > | > >>> could distinguish probe pkts from data pkts. As you | > | > | say, a router | > | > | > >>> alert option could indeed be used. | > | > | > >>> | > | > | > >>> | > | > | > >>>> -----Original Message----- | > | > | > >>>> From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > >>>> Sent: 26 February 2008 17:06 | > | > | > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com | > | > | > >>>> Cc: pcn@ietf.org | > | > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > | > >>>> | > | > | > >>>> Hi Phil | > | > | > >>>> | > | > | > >>>> * Regarding Routing NOT, | > | > | > >>>> * Regarding scheduling, NOT | > | > | > >>>> * Regarding PCN_marking, it could be handled | differently: | > | > | > >>>> | > | > | > >>>> ** if excess rate marking is used AND the | > | > PCN-interior-node is | > | > | > >>>> | > | > | > >>> congested | > | > | > >>> | > | > | > >>>> AND | > | > | > >>>> the probe packet contains the ROUTER ALERT | > option THEN | > | > | > >>>> the probe packet can be distinguished from | the other | > | > | > >>>> | > | > | > >>> PCN packets, | > | > | > >>> | > | > | > >>>> and therefore it will be for sure | > PCN_marking encoded. | > | > | > >>>> | > | > | > >>>> ** if excess rate marking is used AND the | > | > PCN-interior-node is | > | > | > >>>> | > | > | > >>> congested | > | > | > >>> | > | > | > >>>> AND | > | > | > >>>> the probe packet DOES NOT contain the ROUTER | > | ALERT option | > | > | > >>>> THEN this MIGHT be PCN_marking encoded, or it | > | > MIGHT not be | > | > | > >>>> PCN_marking encoded. This depends | > | > | > >>>> on whether this probe packet is selected | to represent | > | > | > >>>> | > | > | > >>> the excess | > | > | > >>> | > | > | > >>>> rate, or is not selected. | > | > | > >>>> | > | > | > >>>> Best regards, | > | > | > >>>> Georgios | > | > | > >>>> | > | > | > >>>> | > | > | > >>>> | > | > | > >>>> | > | > | > >>>> | > | > | > >>>> | > | > | > >>>>> -----Original Message----- | > | > | > >>>>> From: philip.eardley@bt.com | > [mailto:philip.eardley@bt.com] | > | > | > >>>>> Sent: dinsdag 26 februari 2008 17:45 | > | > | > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > | > | > >>>>> Cc: pcn@ietf.org | > | > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > | > | > >>>>> | > | > | > >>>>> But why would the interior node *need* to | distinguish it | > | > | > >>>>> | > | > | > >>> from other | > | > | > >>> | > | > | > >>>>> pcn pkts? | > | > | > >>>>> | > | > | > >>>>> And even if you have got router alert, the | architecture | > | > | > >>>>> | > | > | > >>> draft says: | > | > | > >>> | > | > | > >>>>> "must be handled the same as (ordinary data) | > PCN-packets, | > | > | > >>>>> | > | > | > >>> in terms | > | > | > >>> | > | > | > >>>>> of routing, scheduling and PCN-marking." | > | > | > >>>>> Even though your router alert's got it in slow | > path, will | > | > | > >>>>> | > | > | > >>> it handle | > | > | > >>> | > | > | > >>>>> it any differently in terms of routing scehdulign & | > | > | pcn-marking? | > | > | > >>>>> | > | > | > >>>>> | > | > | > >>>>> | > | > | > >> _______________________________________________ | > | > | > >> 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 | > | > | > > | > | > | > | > | > | > -- | > | > | > 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 | > | > | > | > | > | | > | > | | > | > | _______________________________________________ | > | > | 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 From pcn-bounces@ietf.org Thu Feb 28 05:08:49 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815463A6E97; Thu, 28 Feb 2008 05:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olq6kYM476Kn; Thu, 28 Feb 2008 05:08:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD593A6E89; Thu, 28 Feb 2008 05:08:36 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4DD3A6EA1 for ; Thu, 28 Feb 2008 05:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s01zvIUT2f+S for ; Thu, 28 Feb 2008 05:08:26 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 2D51228C565 for ; Thu, 28 Feb 2008 05:07:54 -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 m1SD7b7c029496; Thu, 28 Feb 2008 14:07:44 +0100 (MET) From: "Georgios Karagiannis" To: , References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EF@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 14:07:32 +0100 Message-ID: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EF@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZw X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:07:46 +0100 (MET) Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1860995274==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1860995274== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C87A13.4873E020" This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C87A13.4873E020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil ------=_NextPart_000_002F_01C87A13.4873E020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
I am not in favour of using the token bucket as = the only=20 metering function that can be used in PCN!
Regarding the comparison, I think that if you = want to base=20 any decission on it, then
the LC-PCN algorithm should also be included in = this=20 comparison!
 
Best regards,
Georgios
 
 
 
 
 

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: woensdag 27 februari 2008=20 14:13
To: pcn@ietf.org
Subject: [PCN] PCN = termination=20 marking algorithm - consensus?

Here also is an attempt = for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are outlined = in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these three = functions=20 on either its ingoing or outgoing interfaces. The same choice MUST be = made for=20 every PCN-node in one PCN-domain.

[Lars has commented: do = we need to=20 allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have the = value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a PCN-packet. = However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST be = metered as=20 follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST have = the=20 following behaviour:

 

a token bucket, operating in bits: =

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of the=20 PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter indicates = “termination mark” to the Mark function

 

Note: Step 1A can be triggered by a packet = and so can=20 be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead of = Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of PCN-packet, = then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of PCN-packet” = is the MTU in bits of=20 any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to “termination = mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields MUST = be set to the=20 codepoint “termination marked”, as defined in = [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), I = suggest=20 it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------=_NextPart_000_002F_01C87A13.4873E020-- --===============1860995274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1860995274==-- From pcn-bounces@ietf.org Thu Feb 28 05:24:54 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8833A6A80; Thu, 28 Feb 2008 05:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 H+ReWOu9YKQ7; Thu, 28 Feb 2008 05:24:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3C528C367; Thu, 28 Feb 2008 05:24:53 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D229D28C367 for ; Thu, 28 Feb 2008 05:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wm0V7U+HQZN for ; Thu, 28 Feb 2008 05:24:47 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id A72C33A6C5C for ; Thu, 28 Feb 2008 05:24:46 -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 m1SDOW5L000675; Thu, 28 Feb 2008 14:24:35 +0100 (MET) From: "Georgios Karagiannis" To: References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EE@E03MVZ1-UKDY.domain1.systemhost.net> <47C56A8B.4000305@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 14:24:27 +0100 Message-ID: <003a01c87a0d$415a4e60$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47C56A8B.4000305@informatik.uni-wuerzburg.de> Thread-Index: Ach5R9mT2zDObE3YS0asTbrngZJDyAAxGpPg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:24:36 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: woensdag 27 februari 2008 14:50 > To: philip.eardley@bt.com > Cc: pcn@ietf.org; pcn-bounces@ietf.org > Subject: Re: [PCN] PCN admission marking algorithm - consensus? > > Hi, > > philip.eardley@bt.com wrote: > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> > > Lars > > > >> Eggert > >> Sent: 27 February 2008 11:33 > >> To: ext pcn-bounces@ietf.org > >> Cc: pcn@ietf.org > >> Subject: Re: [PCN] PCN admission marking algorithm - consensus? > >> > >> Hi, > >> > >> I think this is a very useful attempt at formalizing things! > >> > >> A few comments on specific things below. > >> > >> On 2008-2-27, at 13:02, ext pcn-bounces@ietf.org wrote: > >> > >>> Note: The PCN-node MAY implement these three functions on > either its > >>> ingoing or outgoing interfaces. The same choice MUST be made for > >>> > > every > > > >>> PCN-node in one PCN-domain. > >>> > >> Is there any difference in functionality or any other > reason why we > >> wouldn't just decide on one? Leaving this open means that > potential > >> users of PCN need to buy matching equipment or at least > configure one > >> more thing correctly. > >> > > > > No difference in functionality & I agree it would be nice to have > > fewer configurables. > > Egress seems more natural to me (if it's a real queue then > naturally > > it's done at the egress). However, I know of existing kit where it > > looks like you can easily configure it to do PCN marking on the > > ingress interface but not on egress interface (still trying > to clarify this). > > Not sure if this is a relevant consideration. > > > > The rational behind this was to give more freedom to possibly > existing hardware when only one meter and marker per > in/outgoing interface is feasible. > > > > > >>> Meter function: > >>> > >> Can we agree to always add the units of the various rates and > >> counters, i.e., whether they are in bits or packets? Some > of them are > >> already clearly identified, but not all. Doing this would > improve the > >> description. > >> > > > > Yes, and should check this in terms of > > > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark- > > 02 > > .txt > > > > Which I think means that it should meter in terms of bits (virtual > > queue is concerned about congestion of the line (ie > bit/sec)) and mark > > irrespective of the pkt size. > > > > That's also my view: packet size dependent metering > (bits/bytes) and packet size independent marking (packets of > different size have the same marking probability). > > Regards, > > Michael > > > I had a quick chat with bob & believe this is what his > byte-pkt-mark > > draft says (with the exception that if the machine > architecture pads > > to the MTU size, then you have to interpret 'size of pkt' to mean > > 'size after padding'). > > > > > >>> Mark function: > >>> > >>> If the meter indicates to "admission mark" a PCN-packet, then: > >>> > >>> [1] this step is REQUIRED, unless [RFC-encoding] standardises an > >>> encoding that allows a PCN-packet to be simultaneously "admission > >>> marked" and "termination marked": > >>> > >> Do you think it would make sense to wait with the > architecture until > >> a few key decisions have been reached on the encoding? That would > >> allow us to simplify the description by avoiding constructs like > >> "REQUIRED, unless". > >> > > > > Don't think it impacts the architecture, but yes it makes > sense to me > > that key encoding decisions are made first in order to avoid this > > construct. > > > >> Lars > >> _______________________________________________ > >> 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 > > > > -- > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 05:27:08 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBD928C573; Thu, 28 Feb 2008 05:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.355 X-Spam-Level: * X-Spam-Status: No, score=1.355 tagged_above=-999 required=5 tests=[AWL=-1.909, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYYt9au6sQLH; Thu, 28 Feb 2008 05:26:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8863A6964; Thu, 28 Feb 2008 05:26:56 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609773A6942 for ; Thu, 28 Feb 2008 05:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YBBOaMiYQZC for ; Thu, 28 Feb 2008 05:26:46 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 556113A6974 for ; Thu, 28 Feb 2008 05:26:45 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 13:26:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 13:26:36 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN termination marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzA= From: To: , X-OriginalArrivalTime: 28 Feb 2008 13:26:37.0488 (UTC) FILETIME=[8B92DB00:01C87A0D] Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641187854==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0641187854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87A0D.8AFA177A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87A0D.8AFA177A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've got to have *one* metering function for termination (& one for adm).=20 =20 I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!).=20 =20 Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic =20 which is exactly what the email below does. =20 Please explain what youre concerned about! thanks. =20 Phil/ =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? =20 Hi Phil =20 I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then=20 the LC-PCN algorithm should also be included in this comparison! =20 Best regards, Georgios =20 =20 =20 =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 [Lars has commented: do we need to allow this choice?] =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. =20 Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. =20 A packet classified as a PCN-packet MUST be metered as follows.=20 The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 a token bucket, operating in bits:=20 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill =3D 0, then the meter indicates "termination mark" to the Mark function =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 =20 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain.=20 Note: Step 1B above is still performed.=20 =20 =20 Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] =20 =20 (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. =20 (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 -PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 .txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87A0D.8AFA177A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve got to have *one* metering function for = termination (& one for adm).

 

I thought the idea was that lc-pcn = would get into anna’s comparison draft, ie in the same format & the = same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!).

 

Even so, I looked at the latest = lc-pcn & S4.3.1 (interior node & termination) and it = says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds a =
configured-admissible-rate and mark this excess PCN

   traffic

 

which is exactly what the email below does.

           = ;            =   

Please explain what youre concerned about!

thanks.

 

Phil/

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28 February 2008 13:08
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN = termination marking algorithm - consensus?

 

Hi Phil

 

I am not in favour of using the = token bucket as the only metering function that can be used in = PCN!

Regarding the comparison, I think = that if you want to base any decission on it, then

the LC-PCN algorithm should also be included in this comparison!

 

Best regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: woensdag 27 = februari 2008 14:13
To: pcn@ietf.org
Subject: [PCN] PCN = termination marking algorithm - consensus?

Here also is an attempt for consensus on the = termination marking behaviour.

 

 

 If an interface of the PCN-domain performs PCN Admission = Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows:

 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

[Lars has commented: do we need to allow this = choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if = the PCN-packet is already “termination marked”, as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. = (*)

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a ‘token bucket’, = however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST be metered as follows. =

The interface MUST have:

[1] a configured bit rate, termed = PCN-upper-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

 

a token bucket, operating in bits:

1A tokens are added at the PCN-upper-rate, to a maximum = TB.size

1B tokens are removed equal to the size in bits of the = PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter indicates “termination mark” to the Mark function

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step = 1

 

The following SHOULD be done (**) instead of Step 2 above (Step = 2 is then superfluous).

if TB.fill < maximum size of PCN-packet, then the meter = indicates “termination mark” to the Mark function

The “maximum size of PCN-packet” is the MTU in bits = of any PCN-packets in the PCN-domain.

Note: Step 1B above is still performed. =

 

 

Mark function:

If the meter indicates to “termination mark” a = PCN-packet, then:

the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “termination marked”, as defined in = [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie the termination based on = rates, rather than the 3SM termination based on marked pkts), if the meter = counts pkts that are already termination marked then there’ll be = over-termination in the event of multiple bottlenecks. However, since this option = is probably more complicated to implement than a normal classifier (?), I = suggest it is a SHOULD.

 

(**) Explanation: this captures the point that Michael = makes in http://www3.informatik.uni-wuerzburg.de/staff/= menth/Publications/Menth08-PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-bris= coe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small = pkts. However, since this option is more complicated to implement than a = normal token bucket, I suggest it is a SHOULD.

 

we could also add an example algorithm, such as that = in http://www.ietf.org/internet-drafts/draft-char= ny-pcn-comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87A0D.8AFA177A-- --===============0641187854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0641187854==-- From pcn-bounces@ietf.org Thu Feb 28 05:29:53 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D246428C3FF; Thu, 28 Feb 2008 05:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 HOT3hwmTJt8h; Thu, 28 Feb 2008 05:29:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABBC3A69A0; Thu, 28 Feb 2008 05:29:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7FC3A6D23 for ; Thu, 28 Feb 2008 05:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbDb0pH7SuVt for ; Thu, 28 Feb 2008 05:29:45 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 2F9843A6E65 for ; Thu, 28 Feb 2008 05:29:21 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 13:29:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 13:29:13 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <003a01c87a0d$415a4e60$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach5R9mT2zDObE3YS0asTbrngZJDyAAxGpPgAABX4GA= From: To: X-OriginalArrivalTime: 28 Feb 2008 13:29:14.0680 (UTC) FILETIME=[E9447380:01C87A0D] Cc: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The email below is about the marking behaviour. Not about the encoding or edge behaviours. The purpose of my email: I believe we have good consensus on the marking behaviour for both admission & termination. So we can formalise them & reach agreement hopefully with some speed. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 28 February 2008 13:24 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN admission marking algorithm - consensus? > > > Hi Phil, > > I would like to have a more clear understanding on what > you are proposing before we can get any consensus! > > In my option all options that are currently decribed in the current > version > of the archietcture draft > will be reduced at the moment that the encoding method is selected and > probably also > when the PCN algorithms used at interior and edges are selected. > > I thought that the idea of the architecture draft is to provide a > description of the > architectural options that can be used, such that later on a selection > on the algorithms is done. > > If that is not the case then the publication of the architecture draft > should be delayed > until the above selections are done! > > Best regards, > Georgios > > > > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of Michael Menth > > Sent: woensdag 27 februari 2008 14:50 > > To: philip.eardley@bt.com > > Cc: pcn@ietf.org; pcn-bounces@ietf.org > > Subject: Re: [PCN] PCN admission marking algorithm - consensus? > > > > Hi, > > > > philip.eardley@bt.com wrote: > > > > > >> -----Original Message----- > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > On Behalf Of > > >> > > > Lars > > > > > >> Eggert > > >> Sent: 27 February 2008 11:33 > > >> To: ext pcn-bounces@ietf.org > > >> Cc: pcn@ietf.org > > >> Subject: Re: [PCN] PCN admission marking algorithm - consensus? > > >> > > >> Hi, > > >> > > >> I think this is a very useful attempt at formalizing things! > > >> > > >> A few comments on specific things below. > > >> > > >> On 2008-2-27, at 13:02, ext pcn-bounces@ietf.org wrote: > > >> > > >>> Note: The PCN-node MAY implement these three functions on > > either its > > >>> ingoing or outgoing interfaces. The same choice MUST be made for > > >>> > > > every > > > > > >>> PCN-node in one PCN-domain. > > >>> > > >> Is there any difference in functionality or any other > > reason why we > > >> wouldn't just decide on one? Leaving this open means that > > potential > > >> users of PCN need to buy matching equipment or at least > > configure one > > >> more thing correctly. > > >> > > > > > > No difference in functionality & I agree it would be nice to have > > > fewer configurables. > > > Egress seems more natural to me (if it's a real queue then > > naturally > > > it's done at the egress). However, I know of existing kit where it > > > looks like you can easily configure it to do PCN marking on the > > > ingress interface but not on egress interface (still trying > > to clarify this). > > > Not sure if this is a relevant consideration. > > > > > > > The rational behind this was to give more freedom to possibly > > existing hardware when only one meter and marker per > > in/outgoing interface is feasible. > > > > > > > > > >>> Meter function: > > >>> > > >> Can we agree to always add the units of the various rates and > > >> counters, i.e., whether they are in bits or packets? Some > > of them are > > >> already clearly identified, but not all. Doing this would > > improve the > > >> description. > > >> > > > > > > Yes, and should check this in terms of > > > > > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark- > > > 02 > > > .txt > > > > > > Which I think means that it should meter in terms of bits (virtual > > > queue is concerned about congestion of the line (ie > > bit/sec)) and mark > > > irrespective of the pkt size. > > > > > > > That's also my view: packet size dependent metering > > (bits/bytes) and packet size independent marking (packets of > > different size have the same marking probability). > > > > Regards, > > > > Michael > > > > > I had a quick chat with bob & believe this is what his > > byte-pkt-mark > > > draft says (with the exception that if the machine > > architecture pads > > > to the MTU size, then you have to interpret 'size of pkt' to mean > > > 'size after padding'). > > > > > > > > >>> Mark function: > > >>> > > >>> If the meter indicates to "admission mark" a PCN-packet, then: > > >>> > > >>> [1] this step is REQUIRED, unless [RFC-encoding] standardises an > > >>> encoding that allows a PCN-packet to be simultaneously "admission > > >>> marked" and "termination marked": > > >>> > > >> Do you think it would make sense to wait with the > > architecture until > > >> a few key decisions have been reached on the encoding? That would > > >> allow us to simplify the description by avoiding constructs like > > >> "REQUIRED, unless". > > >> > > > > > > Don't think it impacts the architecture, but yes it makes > > sense to me > > > that key encoding decisions are made first in order to avoid this > > > construct. > > > > > >> Lars > > >> _______________________________________________ > > >> 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 > > > > > > > -- > > 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 > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 05:30:54 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E003A6E84; Thu, 28 Feb 2008 05:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZkhYgTYPaQi; Thu, 28 Feb 2008 05:30:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8433A6BFB; Thu, 28 Feb 2008 05:30:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DF23A6A40 for ; Thu, 28 Feb 2008 05:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgDwfZfv00v8 for ; Thu, 28 Feb 2008 05:30:27 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C694F3A6BFB for ; Thu, 28 Feb 2008 05:30:26 -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 m1SDT4UE000938; Thu, 28 Feb 2008 14:30:17 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 14:28:59 +0100 Message-ID: <003e01c87a0e$0c8d3250$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78A== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:30:18 +0100 (MET) Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1996787443==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1996787443== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C87A16.6E519A50" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C87A16.6E519A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil ------=_NextPart_000_003F_01C87A16.6E519A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
My concerns are similar to the previous email = that I have=20 sent regarding admission control.

I would like to have a more clear understanding on what you are = proposing=20 before we can get any consensus!

In my option all options that are currently decribed in the current = version=20 of the archietcture draft will be reduced at the moment that the = encoding method=20 is selected and probably also when the PCN algorithms used at interior = and edges=20 are selected.

I thought that the idea of the architecture draft is to provide a = description=20 of the architectural options that can be used, such that later on a = selection on=20 the algorithms is done.

If that is not the case then the publication of the architecture = draft should=20 be delayed until the above selections are done!

Best=20 regards,

Georgios

 


From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: donderdag 28 februari = 2008=20 14:27
To: karagian@cs.utwente.nl; = pcn@ietf.org
Subject:=20 RE: [PCN] PCN termination marking algorithm - = consensus?

We’ve = got to have=20 *one* metering = function for=20 termination (& one for adm).

 

I thought = the idea=20 was that lc-pcn would get into anna’s comparison draft, ie in = the same format=20 & the same general level of understanding of how it works (the = latter=20 being a pre-requisite to getting it in there!).

 

Even so, I = looked at=20 the latest lc-pcn & S4.3.1 (interior node & termination) and = it=20 says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds =
a configured-admissible-rate and mark this excess =
PCN

   traffic

 

which is exactly what the email below=20 does.

           &= nbsp;           &n= bsp; =20

Please explain what youre concerned=20 about!

thanks.

 

Phil/

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28=20 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN termination marking algorithm - consensus?

 

Hi=20 Phil

 

I am not in = favour of=20 using the token bucket as the only metering function that can be used = in=20 PCN!

Regarding = the=20 comparison, I think that if you want to base any decission on it, then =

the LC-PCN = algorithm=20 should also be included in this comparison!

 

Best=20 regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: woensdag 27 februari = 2008=20 14:13
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN termination marking algorithm - consensus?

Here also is an = attempt for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are = outlined in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these = three=20 functions on either its ingoing or outgoing interfaces. The same = choice MUST=20 be made for every PCN-node in one PCN-domain.

[Lars has commented: = do we need=20 to allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have = the value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.=20 However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as = a=20 PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST = be metered=20 as follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST = have the=20 following behaviour:

 

a token bucket, operating in bits:=20

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of=20 the PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter = indicates=20 “termination mark” to the Mark = function

 

Note: Step 1A can be triggered by a packet = and so=20 can be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead = of Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of = PCN-packet, then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of = PCN-packet” is the MTU in bits=20 of any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to = “termination mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields = MUST be set to the=20 codepoint “termination marked”, as defined in=20 [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie = the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), = I=20 suggest it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

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

I would like to have a more clear understanding on what you are = proposing=20 before we can get any consensus!

In my option all options that are currently decribed in the current = version=20 of the archietcture draft will be reduced at the moment that the = encoding method=20 is selected and probably also when the PCN algorithms used at interior = and edges=20 are selected.

I thought that the idea of the architecture draft is to provide a = description=20 of the architectural options that can be used, such that later on a = selection on=20 the algorithms is done.

If that is not the case then the publication of the architecture = draft should=20 be delayed until the above selections are done!

Best=20 regards,

Georgios

 


From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: donderdag 28 februari = 2008=20 14:27
To: karagian@cs.utwente.nl; = pcn@ietf.org
Subject:=20 RE: [PCN] PCN termination marking algorithm - = consensus?

We’ve = got to have=20 *one* metering = function for=20 termination (& one for adm).

 

I thought = the idea=20 was that lc-pcn would get into anna’s comparison draft, ie in = the same format=20 & the same general level of understanding of how it works (the = latter=20 being a pre-requisite to getting it in there!).

 

Even so, I = looked at=20 the latest lc-pcn & S4.3.1 (interior node & termination) and = it=20 says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds =
a configured-admissible-rate and mark this excess =
PCN

   traffic

 

which is exactly what the email below=20 does.

           &= nbsp;           &n= bsp; =20

Please explain what youre concerned=20 about!

thanks.

 

Phil/

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28=20 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN termination marking algorithm - consensus?

 

Hi=20 Phil

 

I am not in = favour of=20 using the token bucket as the only metering function that can be used = in=20 PCN!

Regarding = the=20 comparison, I think that if you want to base any decission on it, then =

the LC-PCN = algorithm=20 should also be included in this comparison!

 

Best=20 regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: woensdag 27 februari = 2008=20 14:13
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN termination marking algorithm - consensus?

Here also is an = attempt for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are = outlined in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these = three=20 functions on either its ingoing or outgoing interfaces. The same = choice MUST=20 be made for every PCN-node in one PCN-domain.

[Lars has commented: = do we need=20 to allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have = the value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.=20 However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as = a=20 PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST = be metered=20 as follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST = have the=20 following behaviour:

 

a token bucket, operating in bits:=20

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of=20 the PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter = indicates=20 “termination mark” to the Mark = function

 

Note: Step 1A can be triggered by a packet = and so=20 can be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead = of Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of = PCN-packet, then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of = PCN-packet” is the MTU in bits=20 of any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to = “termination mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields = MUST be set to the=20 codepoint “termination marked”, as defined in=20 [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie = the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), = I=20 suggest it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------=_NextPart_000_0044_01C87A16.6E671E20-- --===============1967452027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1967452027==-- From pcn-bounces@ietf.org Thu Feb 28 05:32:17 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394523A6EA3; Thu, 28 Feb 2008 05:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.086 X-Spam-Level: * X-Spam-Status: No, score=1.086 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVc+et57DcFX; Thu, 28 Feb 2008 05:32:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A27B3A6A80; Thu, 28 Feb 2008 05:32:05 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0170A3A6A40 for ; Thu, 28 Feb 2008 05:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV-P8Dy6QGj4 for ; Thu, 28 Feb 2008 05:31:51 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 503AB3A6E88 for ; Thu, 28 Feb 2008 05:31:51 -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 m1SDVcn0001140; Thu, 28 Feb 2008 14:31:41 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 14:31:33 +0100 Message-ID: <004e01c87a0e$3f416400$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78A== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:31:43 +0100 (MET) Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056398447==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1056398447== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C87A16.A105CC00" This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C87A16.A105CC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil ------=_NextPart_000_004F_01C87A16.A105CC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
My concerns are similar to the previous email = that I have=20 sent regarding admission control.

I would like to have a more clear understanding on what you are = proposing=20 before we can get any consensus!

In my option all options that are currently decribed in the current = version=20 of the archietcture draft will be reduced at the moment that the = encoding method=20 is selected and probably also when the PCN algorithms used at interior = and edges=20 are selected.

I thought that the idea of the architecture draft is to provide a = description=20 of the architectural options that can be used, such that later on a = selection on=20 the algorithms is done.

If that is not the case then the publication of the architecture = draft should=20 be delayed until the above selections are done!

Best=20 regards,

Georgios

 


From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: donderdag 28 februari = 2008=20 14:27
To: karagian@cs.utwente.nl; = pcn@ietf.org
Subject:=20 RE: [PCN] PCN termination marking algorithm - = consensus?

We’ve = got to have=20 *one* metering = function for=20 termination (& one for adm).

 

I thought = the idea=20 was that lc-pcn would get into anna’s comparison draft, ie in = the same format=20 & the same general level of understanding of how it works (the = latter=20 being a pre-requisite to getting it in there!).

 

Even so, I = looked at=20 the latest lc-pcn & S4.3.1 (interior node & termination) and = it=20 says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds =
a configured-admissible-rate and mark this excess =
PCN

   traffic

 

which is exactly what the email below=20 does.

           &= nbsp;           &n= bsp; =20

Please explain what youre concerned=20 about!

thanks.

 

Phil/

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28=20 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN termination marking algorithm - consensus?

 

Hi=20 Phil

 

I am not in = favour of=20 using the token bucket as the only metering function that can be used = in=20 PCN!

Regarding = the=20 comparison, I think that if you want to base any decission on it, then =

the LC-PCN = algorithm=20 should also be included in this comparison!

 

Best=20 regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: woensdag 27 februari = 2008=20 14:13
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN termination marking algorithm - consensus?

Here also is an = attempt for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are = outlined in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these = three=20 functions on either its ingoing or outgoing interfaces. The same = choice MUST=20 be made for every PCN-node in one PCN-domain.

[Lars has commented: = do we need=20 to allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have = the value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.=20 However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as = a=20 PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST = be metered=20 as follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST = have the=20 following behaviour:

 

a token bucket, operating in bits:=20

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of=20 the PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter = indicates=20 “termination mark” to the Mark = function

 

Note: Step 1A can be triggered by a packet = and so=20 can be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead = of Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of = PCN-packet, then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of = PCN-packet” is the MTU in bits=20 of any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to = “termination mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields = MUST be set to the=20 codepoint “termination marked”, as defined in=20 [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie = the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), = I=20 suggest it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------=_NextPart_000_004F_01C87A16.A105CC00-- --===============1056398447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1056398447==-- From pcn-bounces@ietf.org Thu Feb 28 05:33:51 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C550C3A69A0; Thu, 28 Feb 2008 05:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO2VP-m2aJUB; Thu, 28 Feb 2008 05:33:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7CD3A6EAD; Thu, 28 Feb 2008 05:33:38 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847613A6C0E for ; Thu, 28 Feb 2008 05:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VR0ePXwYrAW for ; Thu, 28 Feb 2008 05:33:26 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id B93DB3A6EB9 for ; Thu, 28 Feb 2008 05:33:02 -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 m1SDWmSR001191; Thu, 28 Feb 2008 14:32:53 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 14:32:48 +0100 Message-ID: <005e01c87a0e$68b67d20$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78A== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:32:55 +0100 (MET) Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0871127776==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0871127776== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C87A16.CA7AE520" This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C87A16.CA7AE520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil ------=_NextPart_000_005F_01C87A16.CA7AE520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
My concerns are similar to the previous email = that I have=20 sent regarding admission control.

I would like to have a more clear understanding on what you are = proposing=20 before we can get any consensus!

In my option all options that are currently decribed in the current = version=20 of the archietcture draft will be reduced at the moment that the = encoding method=20 is selected and probably also when the PCN algorithms used at interior = and edges=20 are selected.

I thought that the idea of the architecture draft is to provide a = description=20 of the architectural options that can be used, such that later on a = selection on=20 the algorithms is done.

If that is not the case then the publication of the architecture = draft should=20 be delayed until the above selections are done!

Best=20 regards,

Georgios

 


From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: donderdag 28 februari = 2008=20 14:27
To: karagian@cs.utwente.nl; = pcn@ietf.org
Subject:=20 RE: [PCN] PCN termination marking algorithm - = consensus?

We’ve = got to have=20 *one* metering = function for=20 termination (& one for adm).

 

I thought = the idea=20 was that lc-pcn would get into anna’s comparison draft, ie in = the same format=20 & the same general level of understanding of how it works (the = latter=20 being a pre-requisite to getting it in there!).

 

Even so, I = looked at=20 the latest lc-pcn & S4.3.1 (interior node & termination) and = it=20 says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds =
a configured-admissible-rate and mark this excess =
PCN

   traffic

 

which is exactly what the email below=20 does.

           &= nbsp;           &n= bsp; =20

Please explain what youre concerned=20 about!

thanks.

 

Phil/

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28=20 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN termination marking algorithm - consensus?

 

Hi=20 Phil

 

I am not in = favour of=20 using the token bucket as the only metering function that can be used = in=20 PCN!

Regarding = the=20 comparison, I think that if you want to base any decission on it, then =

the LC-PCN = algorithm=20 should also be included in this comparison!

 

Best=20 regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: woensdag 27 februari = 2008=20 14:13
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN termination marking algorithm - consensus?

Here also is an = attempt for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are = outlined in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these = three=20 functions on either its ingoing or outgoing interfaces. The same = choice MUST=20 be made for every PCN-node in one PCN-domain.

[Lars has commented: = do we need=20 to allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have = the value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.=20 However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as = a=20 PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST = be metered=20 as follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST = have the=20 following behaviour:

 

a token bucket, operating in bits:=20

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of=20 the PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter = indicates=20 “termination mark” to the Mark = function

 

Note: Step 1A can be triggered by a packet = and so=20 can be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead = of Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of = PCN-packet, then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of = PCN-packet” is the MTU in bits=20 of any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to = “termination mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields = MUST be set to the=20 codepoint “termination marked”, as defined in=20 [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie = the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), = I=20 suggest it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------=_NextPart_000_005F_01C87A16.CA7AE520-- --===============0871127776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0871127776==-- From pcn-bounces@ietf.org Thu Feb 28 05:33:59 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275023A6E88; Thu, 28 Feb 2008 05:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SivzmeR9GHay; Thu, 28 Feb 2008 05:33:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07813A6E9F; Thu, 28 Feb 2008 05:33:37 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890063A6A80 for ; Thu, 28 Feb 2008 05:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuvc9Y6YxCAa for ; Thu, 28 Feb 2008 05:33:25 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id CEAB43A6EB7 for ; Thu, 28 Feb 2008 05:33:00 -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 m1SDWmSQ001191; Thu, 28 Feb 2008 14:32:51 +0100 (MET) From: "Georgios Karagiannis" To: , References: <002e01c87a0a$e6af7820$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 28 Feb 2008 14:32:43 +0100 Message-ID: <005901c87a0e$68a5b440$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78A== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 28 Feb 2008 14:32:53 +0100 (MET) Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1156884998==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1156884998== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C87A16.CA6A1C40" This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C87A16.CA6A1C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios _____ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN -MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil ------=_NextPart_000_005A_01C87A16.CA6A1C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
My concerns are similar to the previous email = that I have=20 sent regarding admission control.

I would like to have a more clear understanding on what you are = proposing=20 before we can get any consensus!

In my option all options that are currently decribed in the current = version=20 of the archietcture draft will be reduced at the moment that the = encoding method=20 is selected and probably also when the PCN algorithms used at interior = and edges=20 are selected.

I thought that the idea of the architecture draft is to provide a = description=20 of the architectural options that can be used, such that later on a = selection on=20 the algorithms is done.

If that is not the case then the publication of the architecture = draft should=20 be delayed until the above selections are done!

Best=20 regards,

Georgios

 


From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: donderdag 28 februari = 2008=20 14:27
To: karagian@cs.utwente.nl; = pcn@ietf.org
Subject:=20 RE: [PCN] PCN termination marking algorithm - = consensus?

We’ve = got to have=20 *one* metering = function for=20 termination (& one for adm).

 

I thought = the idea=20 was that lc-pcn would get into anna’s comparison draft, ie in = the same format=20 & the same general level of understanding of how it works (the = latter=20 being a pre-requisite to getting it in there!).

 

Even so, I = looked at=20 the latest lc-pcn & S4.3.1 (interior node & termination) and = it=20 says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds =
a configured-admissible-rate and mark this excess =
PCN

   traffic

 

which is exactly what the email below=20 does.

           &= nbsp;           &n= bsp; =20

Please explain what youre concerned=20 about!

thanks.

 

Phil/

 

-----Original=20 Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28=20 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN termination marking algorithm - consensus?

 

Hi=20 Phil

 

I am not in = favour of=20 using the token bucket as the only metering function that can be used = in=20 PCN!

Regarding = the=20 comparison, I think that if you want to base any decission on it, then =

the LC-PCN = algorithm=20 should also be included in this comparison!

 

Best=20 regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf=20 Of philip.eardley@bt.com
Sent: woensdag 27 februari = 2008=20 14:13
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN termination marking algorithm - consensus?

Here also is an = attempt for=20 consensus on the termination marking behaviour.

 

 

 If an interface of the PCN-domain = performs PCN=20 Admission Marking then it performs three functions, which are = outlined in=20 draft-ietf-pcn-architecture as follows:

 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these = three=20 functions on either its ingoing or outgoing interfaces. The same = choice MUST=20 be made for every PCN-node in one PCN-domain.

[Lars has commented: = do we need=20 to allow this choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have = the value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.=20 However, if the PCN-packet is already “termination = marked”, as defined in=20 [RFC-encoding], then the Meter function SHOULD NOT be performed.=20 (*)

If a packet’s ECN/DSCP fields do not = have the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as = a=20 PCN-packet.

 

Meter function:

Note: The meter is described as a = ‘token bucket’,=20 however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST = be metered=20 as follows.

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-upper-rate

[2] a meter for PCN-packets, which MUST = have the=20 following behaviour:

 

a token bucket, operating in bits:=20

1A tokens are added at the PCN-upper-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size in = bits of=20 the PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter = indicates=20 “termination mark” to the Mark = function

 

Note: Step 1A can be triggered by a packet = and so=20 can be done at the same time as Step 1B.

Note: Step 2 can be performed before or = after step=20 1

 

The following SHOULD be done (**) instead = of Step 2=20 above (Step 2 is then superfluous).

if TB.fill < maximum size of = PCN-packet, then the=20 meter indicates “termination mark” to the Mark = function

The “maximum size of = PCN-packet” is the MTU in bits=20 of any PCN-packets in the PCN-domain.

Note: Step 1B above is = still=20 performed.

 

 

Mark function:

If the meter indicates to = “termination mark” a=20 PCN-packet, then:

the PCN-packet’s ECN/DSCP fields = MUST be set to the=20 codepoint “termination marked”, as defined in=20 [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie = the=20 termination based on rates, rather than the 3SM termination based on = marked=20 pkts), if the meter counts pkts that are already termination marked = then=20 there’ll be over-termination in the event of multiple = bottlenecks.=20 However, since this = option is=20 probably more complicated to implement than a normal classifier (?), = I=20 suggest it is a SHOULD.

 

(**) Explanation: this = captures the=20 point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicati= ons/Menth08-PCN-MFT.pdf=20 & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-= pkt-mark-02.txt=20 Otherwise flows with big pkts get marked more than flows with small = pkts.=20 However, since this option is more complicated to implement than a = normal=20 token bucket, I suggest it is a SHOULD.

 

we could also add an = example=20 algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparis= on-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------=_NextPart_000_005A_01C87A16.CA6A1C40-- --===============1156884998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1156884998==-- From pcn-bounces@ietf.org Thu Feb 28 06:35:14 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D52128C395; Thu, 28 Feb 2008 06:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-2.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, 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 qxgKvkPiKhpe; Thu, 28 Feb 2008 06:35:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E393A6999; Thu, 28 Feb 2008 06:35:08 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B193A6974 for ; Thu, 28 Feb 2008 06:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-yjS3QsUTHs for ; Thu, 28 Feb 2008 06:35:02 -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 BBDD23A6999 for ; Thu, 28 Feb 2008 06:35:01 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2008 09:34:54 -0500 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 m1SEYsS2012327; Thu, 28 Feb 2008 09:34:54 -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.12.10/8.12.6) with ESMTP id m1SEYs9D000141; Thu, 28 Feb 2008 14:34:54 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); Thu, 28 Feb 2008 09:34:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 09:34:53 -0500 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN termination marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAqJ58A== From: "Anna Charny (acharny)" To: , , X-OriginalArrivalTime: 28 Feb 2008 14:34:54.0081 (UTC) FILETIME=[15555710:01C87A17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7146; t=1204209294; x=1205073294; 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]=20PCN=20termination=20marking=20a lgorithm=20-=20consensus? |Sender:=20 |To:=20,=20, =20; bh=AQbCZGOQwoPgfHlCiGJ1E8Wsz9mmXfdrnhHI9DR5Lxc=; b=qKQiLl9IZAXjiuUEZ4ccpLiVFSu8/8nBc8ByRNSQ2KYjYjulA9oJ6fT4bl sVt+UqcfApYpX0kperPdXjW7RVDnHEUWeL/oFRgg3G9ta7ZBXheci7UyGdFe M9mgH/gOlS; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all, Sorry for coming late into the discussions. I was dealing with a personal emergency and am now trying to sort through a really large amount of email. Will comment on things as I go through and understand them. On this one: >>I thought the idea was that lc-pcn would get into anna's comparison >>draft, ie in the same format & the same general level of understanding >>of how it works (the latter being a pre-requisite to getting it in there!). The new version of lc-pcn draft came too late to get into the comparison draft this time. Georgious did in fact send various short versions of the behaviors to me before the new version of the lc-pcn draft came out, but it was not clear still exactly how it works. Once the new lc-pcn draft is discussed and understood by the WG, we will deal with plugging it into the comparison draft. Anna ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Thursday, February 28, 2008 8:27 AM To: karagian@cs.utwente.nl; pcn@ietf.org Subject: Re: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm). I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!). Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic which is exactly what the email below does. Please explain what youre concerned about! thanks. Phil/ -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? Hi Phil I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then the LC-PCN algorithm should also be included in this comparison! Best regards, Georgios ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain. [Lars has commented: do we need to allow this choice?] Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. A packet classified as a PCN-packet MUST be metered as follows. The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: a token bucket, operating in bits: 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=0 2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark function Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain. Note: Step 1B above is still performed. Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 -PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 .txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. Comments? phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 07:36:17 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C650A28C545; Thu, 28 Feb 2008 07:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 srVP0vGpR1MV; Thu, 28 Feb 2008 07:36:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B723A6A3E; Thu, 28 Feb 2008 07:36:11 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1023A6BAA for ; Thu, 28 Feb 2008 07:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn7YPH0q9ywU for ; Thu, 28 Feb 2008 07:36:04 -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 02A0B28C123 for ; Thu, 28 Feb 2008 07:36:03 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2008 10:35:56 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1SFZufF031077; Thu, 28 Feb 2008 10:35:56 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1SFZS9N027578; Thu, 28 Feb 2008 15:35:51 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 10:35:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 10:35:33 -0500 Message-ID: In-Reply-To: <47C691BC.7090407@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach598sScuH8dWh3T0C+tSSvxPBVBAAJydAQ From: "Anna Charny (acharny)" To: , "Lars Eggert" X-OriginalArrivalTime: 28 Feb 2008 15:35:34.0264 (UTC) FILETIME=[8F0D2F80:01C87A1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10205; t=1204212956; x=1205076956; c=relaxed/simple; s=rtpdkim1001; 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]=20draft-ietf-pcn-architecture-03 |Sender:=20 |To:=20,=20=22Lars=20Egg ert=22=20; bh=Qg0mhdzlubZqT9LKK+H64Blc1N+BJo5dFSGMorlBSYY=; b=nxmntUE2HE6DEjLnbE6RsMMeMJvH5GrgGX1r9dCBinMqo0gLx2tDRHIXoW wG1joqTNw0SNfMl2DJjlPynyZh4mZGTD1VkwmHYeuPbYGZPgF6j68j17aNMX 9J6xYpEzXD; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, You lost me on this. The discussion seems to be centered around the complexities of appropriately forwarding and processing probe packets in the core. What exactly does excess rate marking has to do with it? (I do understand the point that excess rate marking needs more probes to work reliably than threshold-vased/aka vertuall-queue-based marking - I just do not see the connection of this point to the discussion it seems to relate to). If I am missing your point (or the point of the discussion) - which is quite possible as I am reading the thread backwards - I would much appreciate a clarification. Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: Thursday, February 28, 2008 5:50 AM > To: Lars Eggert > Cc: pcn > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi Lars, > > I just want to point out that this complexity is not due to > probing itself but due to the use of excess rate marking for > admission control. > There is no such increased complexity if probing is done in > combination with exhaustive (threshold) marking for admission control. > > Regards, > > Michael > > Lars Eggert wrote: > > Hi, > > > > I'm not sure if I have fully digested this yet, but it > seems like this > > proposal defines different semantics for what the PCN marks mean to > > both the interior and egress nodes, depending on whether a > packet is a > > probe packet or not. That seems to add significant complexity. > > > > Lars > > > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > > > > >> Hi Phil > >> > >> Sorry for not being clear! > >> > >> As you know if ECMP routing is used then this might cause > problems on > >> the way of how admission control and flow termination > algorithms are > >> operating. > >> > >> The ECMP problem is related to the fact that flows can belong to a > >> certain ingress-egress-aggregate, which is maintained at > the ingress > >> adn egress and that operates in admission control state or flow > >> termination state, but that due to the ECMP routing they are not > >> passing through the congested node. > >> > >> Any measures that are taken on such flows will not solve the > >> congestion problem, since such flows are not contributing > and causing > >> the congestion in the PCN-interior-node. > >> > >> Now when probing is used this problem can be solved as follows. > >> When a PCN-interior-node is congested it MUST PCN_marking encode a > >> probe packet. > >> > >> > >> Thus if an egress operates, for a certain > ingress-egress-agrregate in > >> admission control state and it receives a probe packet > which belongs > >> to a flow associated with the same > ingress-egress-agrregate AND the > >> probe packet is PCN_marking encoded, then the egress knows > for sure > >> that the probe packet passed through one or more congested > >> PCN-interior-nodes. In this case the probe packet, and > thus also the > >> requiesting flow can be rejected. > >> > >> If an egress operates, for a certain ingress-egress-agrregate in > >> admission control state and it receives a probe packet > which belongs > >> to a flow associated with the same > ingress-egress-agrregate AND the > >> probe packet is marked as not congested PCN, then the egress knows > >> for sure that the probe packet HAS NOT PASSED through a congested > >> PCN-interior-node due to e.g., used ECMP routing. In this case the > >> probe packet can be accepted, since this flow, even it > belongs to the > >> ingress-egress-aggergate that operates in admission > control, is not > >> contributing and causing the congestion in the PCN-interior-node. > >> > >> > >> Okay, but why one should provide the possibility to PCN-interior- > >> nodes to distinguish between probe packets and other PCN > aware user > >> packets? > >> > >> This is related to which admission control and flow termination > >> algorithms and encodings are used in the PCN-interior-nodes. > >> > >> If an algorithm uses one encoding state for admission control and > >> another encoding state for flow termination then probably > it is not > >> required to provide the possibility to PC_interior-node to > >> distinguish between probe packets and PCN aware user packets. > >> This is because when the PCN-interior-node that operates > in admission > >> control state will AM (admission control encoding state) > encode all > >> packets, i.e., probe packets and user packets. > >> > >> If an algorithm uses only one encoding state for admission control > >> and flow termionation, such as the ones used in the single marking > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to > >> distinguish between probe packets and user data packets. > >> > >> This is because both algorithms SM and LC-PCN are encoding packets > >> proportionaly to the excess rate. > >> This means that when the PCN-interior-node opetrates in admission > >> control state it will not SM mark all packets that are passing > >> through the node, but only a proportion that is needed to > represent > >> the excess rate. Thus if the PCN-interior-node will not > distinguish > >> between the probe packets and other PCN aware packets, > then it is not > >> certain that the probe packet will be SM marked when the > >> PCN-interior-node operates in admission control state. > >> Now, if the probe packets carry a Router Alert option, and when in > >> Admission control state, the PCN-interior-node marks all > packets that > >> are carrying a Router Alert option, then the probe packet > will be for > >> sure marked. > >> > >> Hope that this clarifies your question! > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>> Sent: dinsdag 26 februari 2008 18:16 > >>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>> Cc: pcn@ietf.org > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>> > >>> Sorry, to repeat: > >>> > >>> I still have not the foggiest idea why on earth someone > would want > >>> or need or be interested in the interior node handling probe pkts > >>> differently from the way it handles probe pkts. > >>> > >>> So far you have answered a different question, about whether it > >>> would be possible for someone to devise pcn so that an > interior node > >>> could distinguish probe pkts from data pkts. As you say, a router > >>> alert option could indeed be used. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>> Sent: 26 February 2008 17:06 > >>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > >>>> Cc: pcn@ietf.org > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>> > >>>> Hi Phil > >>>> > >>>> * Regarding Routing NOT, > >>>> * Regarding scheduling, NOT > >>>> * Regarding PCN_marking, it could be handled differently: > >>>> > >>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>> > >>> congested > >>> > >>>> AND > >>>> the probe packet contains the ROUTER ALERT option THEN > >>>> the probe packet can be distinguished from the other > >>>> > >>> PCN packets, > >>> > >>>> and therefore it will be for sure PCN_marking encoded. > >>>> > >>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>> > >>> congested > >>> > >>>> AND > >>>> the probe packet DOES NOT contain the ROUTER ALERT option > >>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > >>>> PCN_marking encoded. This depends > >>>> on whether this probe packet is selected to represent > >>>> > >>> the excess > >>> > >>>> rate, or is not selected. > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>>> Sent: dinsdag 26 februari 2008 17:45 > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>>>> Cc: pcn@ietf.org > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>>> > >>>>> But why would the interior node *need* to distinguish it > >>>>> > >>> from other > >>> > >>>>> pcn pkts? > >>>>> > >>>>> And even if you have got router alert, the architecture > >>>>> > >>> draft says: > >>> > >>>>> "must be handled the same as (ordinary data) PCN-packets, > >>>>> > >>> in terms > >>> > >>>>> of routing, scheduling and PCN-marking." > >>>>> Even though your router alert's got it in slow path, will > >>>>> > >>> it handle > >>> > >>>>> it any differently in terms of routing scehdulign & pcn-marking? > >>>>> > >>>>> > >>>>> > >> _______________________________________________ > >> 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 > > > > -- > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 07:52:06 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3835C28C7B8; Thu, 28 Feb 2008 07:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 nMTMjvW5FIN3; Thu, 28 Feb 2008 07:52:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482F128C4AB; Thu, 28 Feb 2008 07:52:00 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FAE28C0EF for ; Thu, 28 Feb 2008 07:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1bVFi5RH4gN for ; Thu, 28 Feb 2008 07:51:52 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 4377528C5FC for ; Thu, 28 Feb 2008 07:51:52 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6C219A06C5; Thu, 28 Feb 2008 16:51:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5EE12A06C4; Thu, 28 Feb 2008 16:51:42 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0AFBCA06C1; Thu, 28 Feb 2008 16:51:39 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1SFpdV12656; Thu, 28 Feb 2008 16:51:39 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id A153BC851E; Thu, 28 Feb 2008 16:51:39 +0100 (CET) Message-ID: <47C6D84D.40804@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 16:50:37 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna, Anna Charny (acharny) wrote: > Hi Michael, > > You lost me on this. The discussion seems to be centered around the > complexities of appropriately forwarding and processing probe packets in > the core. What exactly does excess rate marking has to do with it? (I > do understand the point that excess rate marking needs more probes to > work reliably than threshold-vased/aka vertuall-queue-based marking - I > just do not see the connection of this point to the discussion it seems > to relate to). > Georgios proposes to do excess rate marking and to avoid multiple probes, he wants to make sure that probe packets are always AM-marked when a link is precongested with regard to the admissible rate. He solves this problem using the router alert option (RAO) taking packets off the fast path. This solves the problem you have described above (which is caused by excess rate marking), but introduces the problem of RAO. That impacts the forwarding of the packets as they need special handling by the routers. The origin of this thread was that the architecture draft said that all pcn packets should be treated in the same way by PCN nodes which is no longer the case for normal data packet and PCN packets. Regards, Michael > If I am missing your point (or the point of the discussion) - which is > quite possible as I am reading the thread backwards - I would much > appreciate a clarification. > > Anna > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Michael Menth >> Sent: Thursday, February 28, 2008 5:50 AM >> To: Lars Eggert >> Cc: pcn >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 >> >> Hi Lars, >> >> I just want to point out that this complexity is not due to >> probing itself but due to the use of excess rate marking for >> admission control. >> There is no such increased complexity if probing is done in >> combination with exhaustive (threshold) marking for admission control. >> >> Regards, >> >> Michael >> >> Lars Eggert wrote: >> >>> Hi, >>> >>> I'm not sure if I have fully digested this yet, but it >>> >> seems like this >> >>> proposal defines different semantics for what the PCN marks mean to >>> both the interior and egress nodes, depending on whether a >>> >> packet is a >> >>> probe packet or not. That seems to add significant complexity. >>> >>> Lars >>> >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: >>> >>> >>> >>>> Hi Phil >>>> >>>> Sorry for not being clear! >>>> >>>> As you know if ECMP routing is used then this might cause >>>> >> problems on >> >>>> the way of how admission control and flow termination >>>> >> algorithms are >> >>>> operating. >>>> >>>> The ECMP problem is related to the fact that flows can belong to a >>>> certain ingress-egress-aggregate, which is maintained at >>>> >> the ingress >> >>>> adn egress and that operates in admission control state or flow >>>> termination state, but that due to the ECMP routing they are not >>>> passing through the congested node. >>>> >>>> Any measures that are taken on such flows will not solve the >>>> congestion problem, since such flows are not contributing >>>> >> and causing >> >>>> the congestion in the PCN-interior-node. >>>> >>>> Now when probing is used this problem can be solved as follows. >>>> When a PCN-interior-node is congested it MUST PCN_marking encode a >>>> probe packet. >>>> >>>> >>>> Thus if an egress operates, for a certain >>>> >> ingress-egress-agrregate in >> >>>> admission control state and it receives a probe packet >>>> >> which belongs >> >>>> to a flow associated with the same >>>> >> ingress-egress-agrregate AND the >> >>>> probe packet is PCN_marking encoded, then the egress knows >>>> >> for sure >> >>>> that the probe packet passed through one or more congested >>>> PCN-interior-nodes. In this case the probe packet, and >>>> >> thus also the >> >>>> requiesting flow can be rejected. >>>> >>>> If an egress operates, for a certain ingress-egress-agrregate in >>>> admission control state and it receives a probe packet >>>> >> which belongs >> >>>> to a flow associated with the same >>>> >> ingress-egress-agrregate AND the >> >>>> probe packet is marked as not congested PCN, then the egress knows >>>> for sure that the probe packet HAS NOT PASSED through a congested >>>> PCN-interior-node due to e.g., used ECMP routing. In this case the >>>> probe packet can be accepted, since this flow, even it >>>> >> belongs to the >> >>>> ingress-egress-aggergate that operates in admission >>>> >> control, is not >> >>>> contributing and causing the congestion in the PCN-interior-node. >>>> >>>> >>>> Okay, but why one should provide the possibility to PCN-interior- >>>> nodes to distinguish between probe packets and other PCN >>>> >> aware user >> >>>> packets? >>>> >>>> This is related to which admission control and flow termination >>>> algorithms and encodings are used in the PCN-interior-nodes. >>>> >>>> If an algorithm uses one encoding state for admission control and >>>> another encoding state for flow termination then probably >>>> >> it is not >> >>>> required to provide the possibility to PC_interior-node to >>>> distinguish between probe packets and PCN aware user packets. >>>> This is because when the PCN-interior-node that operates >>>> >> in admission >> >>>> control state will AM (admission control encoding state) >>>> >> encode all >> >>>> packets, i.e., probe packets and user packets. >>>> >>>> If an algorithm uses only one encoding state for admission control >>>> and flow termionation, such as the ones used in the single marking >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to >>>> distinguish between probe packets and user data packets. >>>> >>>> This is because both algorithms SM and LC-PCN are encoding packets >>>> proportionaly to the excess rate. >>>> This means that when the PCN-interior-node opetrates in admission >>>> control state it will not SM mark all packets that are passing >>>> through the node, but only a proportion that is needed to >>>> >> represent >> >>>> the excess rate. Thus if the PCN-interior-node will not >>>> >> distinguish >> >>>> between the probe packets and other PCN aware packets, >>>> >> then it is not >> >>>> certain that the probe packet will be SM marked when the >>>> PCN-interior-node operates in admission control state. >>>> Now, if the probe packets carry a Router Alert option, and when in >>>> Admission control state, the PCN-interior-node marks all >>>> >> packets that >> >>>> are carrying a Router Alert option, then the probe packet >>>> >> will be for >> >>>> sure marked. >>>> >>>> Hope that this clarifies your question! >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>>> Sent: dinsdag 26 februari 2008 18:16 >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>>> Cc: pcn@ietf.org >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>> >>>>> Sorry, to repeat: >>>>> >>>>> I still have not the foggiest idea why on earth someone >>>>> >> would want >> >>>>> or need or be interested in the interior node handling probe pkts >>>>> differently from the way it handles probe pkts. >>>>> >>>>> So far you have answered a different question, about whether it >>>>> would be possible for someone to devise pcn so that an >>>>> >> interior node >> >>>>> could distinguish probe pkts from data pkts. As you say, a router >>>>> alert option could indeed be used. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>> Sent: 26 February 2008 17:06 >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com >>>>>> Cc: pcn@ietf.org >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>>> >>>>>> Hi Phil >>>>>> >>>>>> * Regarding Routing NOT, >>>>>> * Regarding scheduling, NOT >>>>>> * Regarding PCN_marking, it could be handled differently: >>>>>> >>>>>> ** if excess rate marking is used AND the PCN-interior-node is >>>>>> >>>>>> >>>>> congested >>>>> >>>>> >>>>>> AND >>>>>> the probe packet contains the ROUTER ALERT option THEN >>>>>> the probe packet can be distinguished from the other >>>>>> >>>>>> >>>>> PCN packets, >>>>> >>>>> >>>>>> and therefore it will be for sure PCN_marking encoded. >>>>>> >>>>>> ** if excess rate marking is used AND the PCN-interior-node is >>>>>> >>>>>> >>>>> congested >>>>> >>>>> >>>>>> AND >>>>>> the probe packet DOES NOT contain the ROUTER ALERT option >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be >>>>>> PCN_marking encoded. This depends >>>>>> on whether this probe packet is selected to represent >>>>>> >>>>>> >>>>> the excess >>>>> >>>>> >>>>>> rate, or is not selected. >>>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>>>>> Sent: dinsdag 26 februari 2008 17:45 >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>>>>> Cc: pcn@ietf.org >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>>>> >>>>>>> But why would the interior node *need* to distinguish it >>>>>>> >>>>>>> >>>>> from other >>>>> >>>>> >>>>>>> pcn pkts? >>>>>>> >>>>>>> And even if you have got router alert, the architecture >>>>>>> >>>>>>> >>>>> draft says: >>>>> >>>>> >>>>>>> "must be handled the same as (ordinary data) PCN-packets, >>>>>>> >>>>>>> >>>>> in terms >>>>> >>>>> >>>>>>> of routing, scheduling and PCN-marking." >>>>>>> Even though your router alert's got it in slow path, will >>>>>>> >>>>>>> >>>>> it handle >>>>> >>>>> >>>>>>> it any differently in terms of routing scehdulign & pcn-marking? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> -- >> 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 08:01:29 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF70F28C89B; Thu, 28 Feb 2008 08:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 asvpObyJM3jC; Thu, 28 Feb 2008 08:01:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E2D28C8D4; Thu, 28 Feb 2008 08:00:45 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F6928C8BC for ; Thu, 28 Feb 2008 08:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vm3vaW2rqWx for ; Thu, 28 Feb 2008 08:00:42 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 7E54828C866 for ; Thu, 28 Feb 2008 08:00:09 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 470D4A06B7; Thu, 28 Feb 2008 17:00:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3A461A06B1; Thu, 28 Feb 2008 17:00:02 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D1A22A06A8; Thu, 28 Feb 2008 17:00:00 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1SG00V12706; Thu, 28 Feb 2008 17:00:00 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 8B042C851E; Thu, 28 Feb 2008 17:00:00 +0100 (CET) Message-ID: <47C6DA42.1020302@informatik.uni-wuerzburg.de> Date: Thu, 28 Feb 2008 16:58:58 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <47C6D84D.40804@informatik.uni-wuerzburg.de> In-Reply-To: <47C6D84D.40804@informatik.uni-wuerzburg.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org forgot a piece ... Michael Menth wrote: > Hi Anna, > > Anna Charny (acharny) wrote: > >> Hi Michael, >> >> You lost me on this. The discussion seems to be centered around the >> complexities of appropriately forwarding and processing probe packets in >> the core. What exactly does excess rate marking has to do with it? (I >> do understand the point that excess rate marking needs more probes to >> work reliably than threshold-vased/aka vertuall-queue-based marking - I >> just do not see the connection of this point to the discussion it seems >> to relate to). >> >> > > Georgios proposes to do excess rate marking and to avoid multiple > probes, he wants to make sure that probe packets are always AM-marked > when a link is precongested with regard to the admissible rate. He > solves this problem using the router alert option (RAO) taking packets > off the fast path. ... and making sure that every such probe packet is marked when AR-precongestion occurs. > This solves the problem you have described above > (which is caused by excess rate marking), but introduces the problem of > RAO. That impacts the forwarding of the packets as they need special > handling by the routers. The origin of this thread was that the > architecture draft said that all pcn packets should be treated in the > same way by PCN nodes which is no longer the case for normal data packet > and PCN packets. > > Regards, > > Michael > > >> If I am missing your point (or the point of the discussion) - which is >> quite possible as I am reading the thread backwards - I would much >> appreciate a clarification. >> >> Anna >> >> >> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>> Behalf Of Michael Menth >>> Sent: Thursday, February 28, 2008 5:50 AM >>> To: Lars Eggert >>> Cc: pcn >>> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 >>> >>> Hi Lars, >>> >>> I just want to point out that this complexity is not due to >>> probing itself but due to the use of excess rate marking for >>> admission control. >>> There is no such increased complexity if probing is done in >>> combination with exhaustive (threshold) marking for admission control. >>> >>> Regards, >>> >>> Michael >>> >>> Lars Eggert wrote: >>> >>> >>>> Hi, >>>> >>>> I'm not sure if I have fully digested this yet, but it >>>> >>>> >>> seems like this >>> >>> >>>> proposal defines different semantics for what the PCN marks mean to >>>> both the interior and egress nodes, depending on whether a >>>> >>>> >>> packet is a >>> >>> >>>> probe packet or not. That seems to add significant complexity. >>>> >>>> Lars >>>> >>>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: >>>> >>>> >>>> >>>> >>>>> Hi Phil >>>>> >>>>> Sorry for not being clear! >>>>> >>>>> As you know if ECMP routing is used then this might cause >>>>> >>>>> >>> problems on >>> >>> >>>>> the way of how admission control and flow termination >>>>> >>>>> >>> algorithms are >>> >>> >>>>> operating. >>>>> >>>>> The ECMP problem is related to the fact that flows can belong to a >>>>> certain ingress-egress-aggregate, which is maintained at >>>>> >>>>> >>> the ingress >>> >>> >>>>> adn egress and that operates in admission control state or flow >>>>> termination state, but that due to the ECMP routing they are not >>>>> passing through the congested node. >>>>> >>>>> Any measures that are taken on such flows will not solve the >>>>> congestion problem, since such flows are not contributing >>>>> >>>>> >>> and causing >>> >>> >>>>> the congestion in the PCN-interior-node. >>>>> >>>>> Now when probing is used this problem can be solved as follows. >>>>> When a PCN-interior-node is congested it MUST PCN_marking encode a >>>>> probe packet. >>>>> >>>>> >>>>> Thus if an egress operates, for a certain >>>>> >>>>> >>> ingress-egress-agrregate in >>> >>> >>>>> admission control state and it receives a probe packet >>>>> >>>>> >>> which belongs >>> >>> >>>>> to a flow associated with the same >>>>> >>>>> >>> ingress-egress-agrregate AND the >>> >>> >>>>> probe packet is PCN_marking encoded, then the egress knows >>>>> >>>>> >>> for sure >>> >>> >>>>> that the probe packet passed through one or more congested >>>>> PCN-interior-nodes. In this case the probe packet, and >>>>> >>>>> >>> thus also the >>> >>> >>>>> requiesting flow can be rejected. >>>>> >>>>> If an egress operates, for a certain ingress-egress-agrregate in >>>>> admission control state and it receives a probe packet >>>>> >>>>> >>> which belongs >>> >>> >>>>> to a flow associated with the same >>>>> >>>>> >>> ingress-egress-agrregate AND the >>> >>> >>>>> probe packet is marked as not congested PCN, then the egress knows >>>>> for sure that the probe packet HAS NOT PASSED through a congested >>>>> PCN-interior-node due to e.g., used ECMP routing. In this case the >>>>> probe packet can be accepted, since this flow, even it >>>>> >>>>> >>> belongs to the >>> >>> >>>>> ingress-egress-aggergate that operates in admission >>>>> >>>>> >>> control, is not >>> >>> >>>>> contributing and causing the congestion in the PCN-interior-node. >>>>> >>>>> >>>>> Okay, but why one should provide the possibility to PCN-interior- >>>>> nodes to distinguish between probe packets and other PCN >>>>> >>>>> >>> aware user >>> >>> >>>>> packets? >>>>> >>>>> This is related to which admission control and flow termination >>>>> algorithms and encodings are used in the PCN-interior-nodes. >>>>> >>>>> If an algorithm uses one encoding state for admission control and >>>>> another encoding state for flow termination then probably >>>>> >>>>> >>> it is not >>> >>> >>>>> required to provide the possibility to PC_interior-node to >>>>> distinguish between probe packets and PCN aware user packets. >>>>> This is because when the PCN-interior-node that operates >>>>> >>>>> >>> in admission >>> >>> >>>>> control state will AM (admission control encoding state) >>>>> >>>>> >>> encode all >>> >>> >>>>> packets, i.e., probe packets and user packets. >>>>> >>>>> If an algorithm uses only one encoding state for admission control >>>>> and flow termionation, such as the ones used in the single marking >>>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to >>>>> distinguish between probe packets and user data packets. >>>>> >>>>> This is because both algorithms SM and LC-PCN are encoding packets >>>>> proportionaly to the excess rate. >>>>> This means that when the PCN-interior-node opetrates in admission >>>>> control state it will not SM mark all packets that are passing >>>>> through the node, but only a proportion that is needed to >>>>> >>>>> >>> represent >>> >>> >>>>> the excess rate. Thus if the PCN-interior-node will not >>>>> >>>>> >>> distinguish >>> >>> >>>>> between the probe packets and other PCN aware packets, >>>>> >>>>> >>> then it is not >>> >>> >>>>> certain that the probe packet will be SM marked when the >>>>> PCN-interior-node operates in admission control state. >>>>> Now, if the probe packets carry a Router Alert option, and when in >>>>> Admission control state, the PCN-interior-node marks all >>>>> >>>>> >>> packets that >>> >>> >>>>> are carrying a Router Alert option, then the probe packet >>>>> >>>>> >>> will be for >>> >>> >>>>> sure marked. >>>>> >>>>> Hope that this clarifies your question! >>>>> >>>>> Best regards, >>>>> Georgios >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>>>> Sent: dinsdag 26 februari 2008 18:16 >>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>>>> Cc: pcn@ietf.org >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>>> >>>>>> Sorry, to repeat: >>>>>> >>>>>> I still have not the foggiest idea why on earth someone >>>>>> >>>>>> >>> would want >>> >>> >>>>>> or need or be interested in the interior node handling probe pkts >>>>>> differently from the way it handles probe pkts. >>>>>> >>>>>> So far you have answered a different question, about whether it >>>>>> would be possible for someone to devise pcn so that an >>>>>> >>>>>> >>> interior node >>> >>> >>>>>> could distinguish probe pkts from data pkts. As you say, a router >>>>>> alert option could indeed be used. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>> Sent: 26 February 2008 17:06 >>>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com >>>>>>> Cc: pcn@ietf.org >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>>>> >>>>>>> Hi Phil >>>>>>> >>>>>>> * Regarding Routing NOT, >>>>>>> * Regarding scheduling, NOT >>>>>>> * Regarding PCN_marking, it could be handled differently: >>>>>>> >>>>>>> ** if excess rate marking is used AND the PCN-interior-node is >>>>>>> >>>>>>> >>>>>>> >>>>>> congested >>>>>> >>>>>> >>>>>> >>>>>>> AND >>>>>>> the probe packet contains the ROUTER ALERT option THEN >>>>>>> the probe packet can be distinguished from the other >>>>>>> >>>>>>> >>>>>>> >>>>>> PCN packets, >>>>>> >>>>>> >>>>>> >>>>>>> and therefore it will be for sure PCN_marking encoded. >>>>>>> >>>>>>> ** if excess rate marking is used AND the PCN-interior-node is >>>>>>> >>>>>>> >>>>>>> >>>>>> congested >>>>>> >>>>>> >>>>>> >>>>>>> AND >>>>>>> the probe packet DOES NOT contain the ROUTER ALERT option >>>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be >>>>>>> PCN_marking encoded. This depends >>>>>>> on whether this probe packet is selected to represent >>>>>>> >>>>>>> >>>>>>> >>>>>> the excess >>>>>> >>>>>> >>>>>> >>>>>>> rate, or is not selected. >>>>>>> >>>>>>> Best regards, >>>>>>> Georgios >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>>>>>> Sent: dinsdag 26 februari 2008 17:45 >>>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com >>>>>>>> Cc: pcn@ietf.org >>>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 >>>>>>>> >>>>>>>> But why would the interior node *need* to distinguish it >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> from other >>>>>> >>>>>> >>>>>> >>>>>>>> pcn pkts? >>>>>>>> >>>>>>>> And even if you have got router alert, the architecture >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> draft says: >>>>>> >>>>>> >>>>>> >>>>>>>> "must be handled the same as (ordinary data) PCN-packets, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> in terms >>>>>> >>>>>> >>>>>> >>>>>>>> of routing, scheduling and PCN-marking." >>>>>>>> Even though your router alert's got it in slow path, will >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> it handle >>>>>> >>>>>> >>>>>> >>>>>>>> it any differently in terms of routing scehdulign & pcn-marking? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>> -- >>> 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 08:06:48 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A683A6E77; Thu, 28 Feb 2008 08:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 uiU63cTquW4F; Thu, 28 Feb 2008 08:06:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C403B3A6EB5; Thu, 28 Feb 2008 08:06:42 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9A83A6B8D for ; Thu, 28 Feb 2008 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfq5UN-1fRNN for ; Thu, 28 Feb 2008 08:06:35 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8438A3A6E5D for ; Thu, 28 Feb 2008 08:06:35 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1SG5vjY002570; Thu, 28 Feb 2008 18:06:24 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 18:06:20 +0200 Received: from [10.180.41.5] ([10.241.184.208]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 18:06:19 +0200 Message-Id: From: Lars Eggert To: menth@informatik.uni-wuerzburg.de In-Reply-To: <47C6D84D.40804@informatik.uni-wuerzburg.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 18:06:16 +0200 References: <47C6D84D.40804@informatik.uni-wuerzburg.de> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 28 Feb 2008 16:06:20.0143 (UTC) FILETIME=[DB47F7F0:01C87A23] X-Nokia-AV: Clean Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, On 2008-2-28, at 17:50, ext Michael Menth wrote: > Georgios proposes to do excess rate marking and to avoid multiple > probes, he wants to make sure that probe packets are always AM- > marked when a link is precongested with regard to the admissible > rate. He solves this problem using the router alert option (RAO) > taking packets off the fast path. This solves the problem you have > described above (which is caused by excess rate marking), but > introduces the problem of RAO. That impacts the forwarding of the > packets as they need special handling by the routers. The origin of > this thread was that the architecture draft said that all pcn > packets should be treated in the same way by PCN nodes which is no > longer the case for normal data packet and PCN packets. one related question is whether RAO packets actually receive the same ECMP treatment that non-RAO packets would receive, since they're being kicked out of the fast path, where ECMP happens. Anyone know how routers deal with this? (From what I understand from the discussions with the routing ADs on NSIS' use of RAO, relying on RAO pretty much guarantees serious deployment issues.) Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 08:08:32 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FD428C770; Thu, 28 Feb 2008 08:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 EpoBi22J2Kv7; Thu, 28 Feb 2008 08:08:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CF23A6B8D; Thu, 28 Feb 2008 08:08:26 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0833A6A4D for ; Thu, 28 Feb 2008 08:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdbuzEmmFbks for ; Thu, 28 Feb 2008 08:08:19 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8500D28C4D6 for ; Thu, 28 Feb 2008 08:07:47 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2008 08:07:40 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1SG7ecj019547; Thu, 28 Feb 2008 08:07:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1SG7KCr017250; Thu, 28 Feb 2008 16:07:40 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); Thu, 28 Feb 2008 11:07:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 11:07:36 -0500 Message-ID: In-Reply-To: <47C6D84D.40804@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEng From: "Anna Charny (acharny)" To: X-OriginalArrivalTime: 28 Feb 2008 16:07:37.0531 (UTC) FILETIME=[096870B0:01C87A24] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13822; t=1204214860; x=1205078860; c=relaxed/simple; s=sjdkim4002; 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]=20draft-ietf-pcn-architecture-03 |Sender:=20; bh=WCyi3k6v/oZYwyOiePS7GW6YgBlLW8Ji5wv835SW9cs=; b=AJsL+Wv5ZjArrto3NOJokXygvL1wh5FK6/elSG0Xio5oFNa0Q3v8wHmNoh 6MvYOTjGHrk+NPUP5C7z8DCvfHNZsLQBgjXUzrnOMJ9PHrMUk4WqpT0jvUfJ V9h5s7le2o; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, Ah - that makes perfect sense. Thank you for the concise summary. Anna > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Thursday, February 28, 2008 10:51 AM > To: Anna Charny (acharny) > Cc: Lars Eggert; pcn > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi Anna, > > Anna Charny (acharny) wrote: > > Hi Michael, > > > > You lost me on this. The discussion seems to be centered > around the > > complexities of appropriately forwarding and processing > probe packets > > in the core. What exactly does excess rate marking has to > do with it? > > (I do understand the point that excess rate marking needs > more probes > > to work reliably than threshold-vased/aka > vertuall-queue-based marking > > - I just do not see the connection of this point to the > discussion it > > seems to relate to). > > > > Georgios proposes to do excess rate marking and to avoid > multiple probes, he wants to make sure that probe packets are > always AM-marked when a link is precongested with regard to > the admissible rate. He solves this problem using the router > alert option (RAO) taking packets off the fast path. This > solves the problem you have described above (which is caused > by excess rate marking), but introduces the problem of RAO. > That impacts the forwarding of the packets as they need > special handling by the routers. The origin of this thread > was that the architecture draft said that all pcn packets > should be treated in the same way by PCN nodes which is no > longer the case for normal data packet and PCN packets. > > Regards, > > Michael > > > If I am missing your point (or the point of the discussion) > - which is > > quite possible as I am reading the thread backwards - I would much > > appreciate a clarification. > > > > Anna > > > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> Michael Menth > >> Sent: Thursday, February 28, 2008 5:50 AM > >> To: Lars Eggert > >> Cc: pcn > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > >> > >> Hi Lars, > >> > >> I just want to point out that this complexity is not due > to probing > >> itself but due to the use of excess rate marking for admission > >> control. > >> There is no such increased complexity if probing is done in > >> combination with exhaustive (threshold) marking for > admission control. > >> > >> Regards, > >> > >> Michael > >> > >> Lars Eggert wrote: > >> > >>> Hi, > >>> > >>> I'm not sure if I have fully digested this yet, but it > >>> > >> seems like this > >> > >>> proposal defines different semantics for what the PCN > marks mean to > >>> both the interior and egress nodes, depending on whether a > >>> > >> packet is a > >> > >>> probe packet or not. That seems to add significant complexity. > >>> > >>> Lars > >>> > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > >>> > >>> > >>> > >>>> Hi Phil > >>>> > >>>> Sorry for not being clear! > >>>> > >>>> As you know if ECMP routing is used then this might cause > >>>> > >> problems on > >> > >>>> the way of how admission control and flow termination > >>>> > >> algorithms are > >> > >>>> operating. > >>>> > >>>> The ECMP problem is related to the fact that flows can > belong to a > >>>> certain ingress-egress-aggregate, which is maintained at > >>>> > >> the ingress > >> > >>>> adn egress and that operates in admission control state or flow > >>>> termination state, but that due to the ECMP routing they are not > >>>> passing through the congested node. > >>>> > >>>> Any measures that are taken on such flows will not solve the > >>>> congestion problem, since such flows are not contributing > >>>> > >> and causing > >> > >>>> the congestion in the PCN-interior-node. > >>>> > >>>> Now when probing is used this problem can be solved as follows. > >>>> When a PCN-interior-node is congested it MUST > PCN_marking encode a > >>>> probe packet. > >>>> > >>>> > >>>> Thus if an egress operates, for a certain > >>>> > >> ingress-egress-agrregate in > >> > >>>> admission control state and it receives a probe packet > >>>> > >> which belongs > >> > >>>> to a flow associated with the same > >>>> > >> ingress-egress-agrregate AND the > >> > >>>> probe packet is PCN_marking encoded, then the egress knows > >>>> > >> for sure > >> > >>>> that the probe packet passed through one or more congested > >>>> PCN-interior-nodes. In this case the probe packet, and > >>>> > >> thus also the > >> > >>>> requiesting flow can be rejected. > >>>> > >>>> If an egress operates, for a certain ingress-egress-agrregate in > >>>> admission control state and it receives a probe packet > >>>> > >> which belongs > >> > >>>> to a flow associated with the same > >>>> > >> ingress-egress-agrregate AND the > >> > >>>> probe packet is marked as not congested PCN, then the > egress knows > >>>> for sure that the probe packet HAS NOT PASSED through a > congested > >>>> PCN-interior-node due to e.g., used ECMP routing. In > this case the > >>>> probe packet can be accepted, since this flow, even it > >>>> > >> belongs to the > >> > >>>> ingress-egress-aggergate that operates in admission > >>>> > >> control, is not > >> > >>>> contributing and causing the congestion in the PCN-interior-node. > >>>> > >>>> > >>>> Okay, but why one should provide the possibility to > PCN-interior- > >>>> nodes to distinguish between probe packets and other PCN > >>>> > >> aware user > >> > >>>> packets? > >>>> > >>>> This is related to which admission control and flow termination > >>>> algorithms and encodings are used in the PCN-interior-nodes. > >>>> > >>>> If an algorithm uses one encoding state for admission > control and > >>>> another encoding state for flow termination then probably > >>>> > >> it is not > >> > >>>> required to provide the possibility to PC_interior-node to > >>>> distinguish between probe packets and PCN aware user packets. > >>>> This is because when the PCN-interior-node that operates > >>>> > >> in admission > >> > >>>> control state will AM (admission control encoding state) > >>>> > >> encode all > >> > >>>> packets, i.e., probe packets and user packets. > >>>> > >>>> If an algorithm uses only one encoding state for > admission control > >>>> and flow termionation, such as the ones used in the > single marking > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut > be able to > >>>> distinguish between probe packets and user data packets. > >>>> > >>>> This is because both algorithms SM and LC-PCN are > encoding packets > >>>> proportionaly to the excess rate. > >>>> This means that when the PCN-interior-node opetrates in > admission > >>>> control state it will not SM mark all packets that are passing > >>>> through the node, but only a proportion that is needed to > >>>> > >> represent > >> > >>>> the excess rate. Thus if the PCN-interior-node will not > >>>> > >> distinguish > >> > >>>> between the probe packets and other PCN aware packets, > >>>> > >> then it is not > >> > >>>> certain that the probe packet will be SM marked when the > >>>> PCN-interior-node operates in admission control state. > >>>> Now, if the probe packets carry a Router Alert option, > and when in > >>>> Admission control state, the PCN-interior-node marks all > >>>> > >> packets that > >> > >>>> are carrying a Router Alert option, then the probe packet > >>>> > >> will be for > >> > >>>> sure marked. > >>>> > >>>> Hope that this clarifies your question! > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>>> Sent: dinsdag 26 februari 2008 18:16 > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>>>> Cc: pcn@ietf.org > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>>> > >>>>> Sorry, to repeat: > >>>>> > >>>>> I still have not the foggiest idea why on earth someone > >>>>> > >> would want > >> > >>>>> or need or be interested in the interior node handling > probe pkts > >>>>> differently from the way it handles probe pkts. > >>>>> > >>>>> So far you have answered a different question, about whether it > >>>>> would be possible for someone to devise pcn so that an > >>>>> > >> interior node > >> > >>>>> could distinguish probe pkts from data pkts. As you > say, a router > >>>>> alert option could indeed be used. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>>>> Sent: 26 February 2008 17:06 > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > >>>>>> Cc: pcn@ietf.org > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>>>> > >>>>>> Hi Phil > >>>>>> > >>>>>> * Regarding Routing NOT, > >>>>>> * Regarding scheduling, NOT > >>>>>> * Regarding PCN_marking, it could be handled differently: > >>>>>> > >>>>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>>>> > >>>>>> > >>>>> congested > >>>>> > >>>>> > >>>>>> AND > >>>>>> the probe packet contains the ROUTER ALERT option THEN > >>>>>> the probe packet can be distinguished from the other > >>>>>> > >>>>>> > >>>>> PCN packets, > >>>>> > >>>>> > >>>>>> and therefore it will be for sure PCN_marking encoded. > >>>>>> > >>>>>> ** if excess rate marking is used AND the PCN-interior-node is > >>>>>> > >>>>>> > >>>>> congested > >>>>> > >>>>> > >>>>>> AND > >>>>>> the probe packet DOES NOT contain the ROUTER ALERT option > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > >>>>>> PCN_marking encoded. This depends > >>>>>> on whether this probe packet is selected to represent > >>>>>> > >>>>>> > >>>>> the excess > >>>>> > >>>>> > >>>>>> rate, or is not selected. > >>>>>> > >>>>>> Best regards, > >>>>>> Georgios > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > >>>>>>> Cc: pcn@ietf.org > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > >>>>>>> > >>>>>>> But why would the interior node *need* to distinguish it > >>>>>>> > >>>>>>> > >>>>> from other > >>>>> > >>>>> > >>>>>>> pcn pkts? > >>>>>>> > >>>>>>> And even if you have got router alert, the architecture > >>>>>>> > >>>>>>> > >>>>> draft says: > >>>>> > >>>>> > >>>>>>> "must be handled the same as (ordinary data) PCN-packets, > >>>>>>> > >>>>>>> > >>>>> in terms > >>>>> > >>>>> > >>>>>>> of routing, scheduling and PCN-marking." > >>>>>>> Even though your router alert's got it in slow path, will > >>>>>>> > >>>>>>> > >>>>> it handle > >>>>> > >>>>> > >>>>>>> it any differently in terms of routing scehdulign & > pcn-marking? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >> -- > >> 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 > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 28 10:54:15 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213B028C917; Thu, 28 Feb 2008 10:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 omQ9Dg61g0j2; Thu, 28 Feb 2008 10:54:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07253A6BCF; Thu, 28 Feb 2008 10:54:04 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E1B28C87C for ; Thu, 28 Feb 2008 10:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnXZTgNfcxaX for ; Thu, 28 Feb 2008 10:54:01 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 0B0B128C93D for ; Thu, 28 Feb 2008 10:52:50 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 18:52:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 18:52:42 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEngAALAuiA= From: To: , X-OriginalArrivalTime: 28 Feb 2008 18:52:43.0465 (UTC) FILETIME=[19CE0390:01C87A3B] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Thanks for clarifying Georgios. interesting idea. Just to go back to the basic reason why single marking's attractive. [1] single marking behaviour on interior routers [2] only single encoding needed your idea at first sight has just one marking behaviour, ie excess rate marking. Indeed, it only has one token bucket. However, it does have extra code/complexity in order to do threshold marking for probe pkts, and this involves the pkt being processed on the slow path within a router. I guess this complexity is for pkt classification & PCN-encoding, rather than for the PCN-metering function. in terms of encoding, it does have a second encoding, but it uses RAO bits rather than ECN/DSCP bits. I worry a bit about security attacks (because probe pkts can now be identified) and about deploability barrier (will operators deploy something that slows all their core routers - after all we claimed one advantage of PCN over hop-by-hop rsvp is that your core routers are really simple, don't have to do any difficult processing... phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Anna > Charny (acharny) > Sent: 28 February 2008 16:08 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi Michael, > > Ah - that makes perfect sense. Thank you for the concise summary. > > Anna > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: Thursday, February 28, 2008 10:51 AM > > To: Anna Charny (acharny) > > Cc: Lars Eggert; pcn > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi Anna, > > > > Anna Charny (acharny) wrote: > > > Hi Michael, > > > > > > You lost me on this. The discussion seems to be centered > > around the > > > complexities of appropriately forwarding and processing > > probe packets > > > in the core. What exactly does excess rate marking has to > > do with it? > > > (I do understand the point that excess rate marking needs > > more probes > > > to work reliably than threshold-vased/aka > > vertuall-queue-based marking > > > - I just do not see the connection of this point to the > > discussion it > > > seems to relate to). > > > > > > > Georgios proposes to do excess rate marking and to avoid > > multiple probes, he wants to make sure that probe packets are > > always AM-marked when a link is precongested with regard to > > the admissible rate. He solves this problem using the router > > alert option (RAO) taking packets off the fast path. This > > solves the problem you have described above (which is caused > > by excess rate marking), but introduces the problem of RAO. > > That impacts the forwarding of the packets as they need > > special handling by the routers. The origin of this thread > > was that the architecture draft said that all pcn packets > > should be treated in the same way by PCN nodes which is no > > longer the case for normal data packet and PCN packets. > > > > Regards, > > > > Michael > > > > > If I am missing your point (or the point of the discussion) > > - which is > > > quite possible as I am reading the thread backwards - I would much > > > appreciate a clarification. > > > > > > Anna > > > > > > > > >> -----Original Message----- > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > On Behalf Of > > >> Michael Menth > > >> Sent: Thursday, February 28, 2008 5:50 AM > > >> To: Lars Eggert > > >> Cc: pcn > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > >> > > >> Hi Lars, > > >> > > >> I just want to point out that this complexity is not due > > to probing > > >> itself but due to the use of excess rate marking for admission > > >> control. > > >> There is no such increased complexity if probing is done in > > >> combination with exhaustive (threshold) marking for > > admission control. > > >> > > >> Regards, > > >> > > >> Michael > > >> > > >> Lars Eggert wrote: > > >> > > >>> Hi, > > >>> > > >>> I'm not sure if I have fully digested this yet, but it > > >>> > > >> seems like this > > >> > > >>> proposal defines different semantics for what the PCN > > marks mean to > > >>> both the interior and egress nodes, depending on whether a > > >>> > > >> packet is a > > >> > > >>> probe packet or not. That seems to add significant complexity. > > >>> > > >>> Lars > > >>> > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > >>> > > >>> > > >>> > > >>>> Hi Phil > > >>>> > > >>>> Sorry for not being clear! > > >>>> > > >>>> As you know if ECMP routing is used then this might cause > > >>>> > > >> problems on > > >> > > >>>> the way of how admission control and flow termination > > >>>> > > >> algorithms are > > >> > > >>>> operating. > > >>>> > > >>>> The ECMP problem is related to the fact that flows can > > belong to a > > >>>> certain ingress-egress-aggregate, which is maintained at > > >>>> > > >> the ingress > > >> > > >>>> adn egress and that operates in admission control state or flow > > >>>> termination state, but that due to the ECMP routing they are not > > >>>> passing through the congested node. > > >>>> > > >>>> Any measures that are taken on such flows will not solve the > > >>>> congestion problem, since such flows are not contributing > > >>>> > > >> and causing > > >> > > >>>> the congestion in the PCN-interior-node. > > >>>> > > >>>> Now when probing is used this problem can be solved as follows. > > >>>> When a PCN-interior-node is congested it MUST > > PCN_marking encode a > > >>>> probe packet. > > >>>> > > >>>> > > >>>> Thus if an egress operates, for a certain > > >>>> > > >> ingress-egress-agrregate in > > >> > > >>>> admission control state and it receives a probe packet > > >>>> > > >> which belongs > > >> > > >>>> to a flow associated with the same > > >>>> > > >> ingress-egress-agrregate AND the > > >> > > >>>> probe packet is PCN_marking encoded, then the egress knows > > >>>> > > >> for sure > > >> > > >>>> that the probe packet passed through one or more congested > > >>>> PCN-interior-nodes. In this case the probe packet, and > > >>>> > > >> thus also the > > >> > > >>>> requiesting flow can be rejected. > > >>>> > > >>>> If an egress operates, for a certain ingress-egress-agrregate in > > >>>> admission control state and it receives a probe packet > > >>>> > > >> which belongs > > >> > > >>>> to a flow associated with the same > > >>>> > > >> ingress-egress-agrregate AND the > > >> > > >>>> probe packet is marked as not congested PCN, then the > > egress knows > > >>>> for sure that the probe packet HAS NOT PASSED through a > > congested > > >>>> PCN-interior-node due to e.g., used ECMP routing. In > > this case the > > >>>> probe packet can be accepted, since this flow, even it > > >>>> > > >> belongs to the > > >> > > >>>> ingress-egress-aggergate that operates in admission > > >>>> > > >> control, is not > > >> > > >>>> contributing and causing the congestion in the PCN-interior-node. > > >>>> > > >>>> > > >>>> Okay, but why one should provide the possibility to > > PCN-interior- > > >>>> nodes to distinguish between probe packets and other PCN > > >>>> > > >> aware user > > >> > > >>>> packets? > > >>>> > > >>>> This is related to which admission control and flow termination > > >>>> algorithms and encodings are used in the PCN-interior-nodes. > > >>>> > > >>>> If an algorithm uses one encoding state for admission > > control and > > >>>> another encoding state for flow termination then probably > > >>>> > > >> it is not > > >> > > >>>> required to provide the possibility to PC_interior-node to > > >>>> distinguish between probe packets and PCN aware user packets. > > >>>> This is because when the PCN-interior-node that operates > > >>>> > > >> in admission > > >> > > >>>> control state will AM (admission control encoding state) > > >>>> > > >> encode all > > >> > > >>>> packets, i.e., probe packets and user packets. > > >>>> > > >>>> If an algorithm uses only one encoding state for > > admission control > > >>>> and flow termionation, such as the ones used in the > > single marking > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut > > be able to > > >>>> distinguish between probe packets and user data packets. > > >>>> > > >>>> This is because both algorithms SM and LC-PCN are > > encoding packets > > >>>> proportionaly to the excess rate. > > >>>> This means that when the PCN-interior-node opetrates in > > admission > > >>>> control state it will not SM mark all packets that are passing > > >>>> through the node, but only a proportion that is needed to > > >>>> > > >> represent > > >> > > >>>> the excess rate. Thus if the PCN-interior-node will not > > >>>> > > >> distinguish > > >> > > >>>> between the probe packets and other PCN aware packets, > > >>>> > > >> then it is not > > >> > > >>>> certain that the probe packet will be SM marked when the > > >>>> PCN-interior-node operates in admission control state. > > >>>> Now, if the probe packets carry a Router Alert option, > > and when in > > >>>> Admission control state, the PCN-interior-node marks all > > >>>> > > >> packets that > > >> > > >>>> are carrying a Router Alert option, then the probe packet > > >>>> > > >> will be for > > >> > > >>>> sure marked. > > >>>> > > >>>> Hope that this clarifies your question! > > >>>> > > >>>> Best regards, > > >>>> Georgios > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >>>>> Sent: dinsdag 26 februari 2008 18:16 > > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > >>>>> Cc: pcn@ietf.org > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > >>>>> > > >>>>> Sorry, to repeat: > > >>>>> > > >>>>> I still have not the foggiest idea why on earth someone > > >>>>> > > >> would want > > >> > > >>>>> or need or be interested in the interior node handling > > probe pkts > > >>>>> differently from the way it handles probe pkts. > > >>>>> > > >>>>> So far you have answered a different question, about whether it > > >>>>> would be possible for someone to devise pcn so that an > > >>>>> > > >> interior node > > >> > > >>>>> could distinguish probe pkts from data pkts. As you > > say, a router > > >>>>> alert option could indeed be used. > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>>>>> Sent: 26 February 2008 17:06 > > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > >>>>>> Cc: pcn@ietf.org > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > >>>>>> > > >>>>>> Hi Phil > > >>>>>> > > >>>>>> * Regarding Routing NOT, > > >>>>>> * Regarding scheduling, NOT > > >>>>>> * Regarding PCN_marking, it could be handled differently: > > >>>>>> > > >>>>>> ** if excess rate marking is used AND the PCN-interior-node is > > >>>>>> > > >>>>>> > > >>>>> congested > > >>>>> > > >>>>> > > >>>>>> AND > > >>>>>> the probe packet contains the ROUTER ALERT option THEN > > >>>>>> the probe packet can be distinguished from the other > > >>>>>> > > >>>>>> > > >>>>> PCN packets, > > >>>>> > > >>>>> > > >>>>>> and therefore it will be for sure PCN_marking encoded. > > >>>>>> > > >>>>>> ** if excess rate marking is used AND the PCN-interior-node is > > >>>>>> > > >>>>>> > > >>>>> congested > > >>>>> > > >>>>> > > >>>>>> AND > > >>>>>> the probe packet DOES NOT contain the ROUTER ALERT option > > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not be > > >>>>>> PCN_marking encoded. This depends > > >>>>>> on whether this probe packet is selected to represent > > >>>>>> > > >>>>>> > > >>>>> the excess > > >>>>> > > >>>>> > > >>>>>> rate, or is not selected. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Georgios > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 > > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > >>>>>>> Cc: pcn@ietf.org > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > >>>>>>> > > >>>>>>> But why would the interior node *need* to distinguish it > > >>>>>>> > > >>>>>>> > > >>>>> from other > > >>>>> > > >>>>> > > >>>>>>> pcn pkts? > > >>>>>>> > > >>>>>>> And even if you have got router alert, the architecture > > >>>>>>> > > >>>>>>> > > >>>>> draft says: > > >>>>> > > >>>>> > > >>>>>>> "must be handled the same as (ordinary data) PCN-packets, > > >>>>>>> > > >>>>>>> > > >>>>> in terms > > >>>>> > > >>>>> > > >>>>>>> of routing, scheduling and PCN-marking." > > >>>>>>> Even though your router alert's got it in slow path, will > > >>>>>>> > > >>>>>>> > > >>>>> it handle > > >>>>> > > >>>>> > > >>>>>>> it any differently in terms of routing scehdulign & > > pcn-marking? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> _______________________________________________ > > >>>> 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 > > >>> > > >>> > > >> -- > > >> 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 > > > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Feb 28 11:02:01 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FAE3A6ECE; Thu, 28 Feb 2008 11:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.404 X-Spam-Level: * X-Spam-Status: No, score=1.404 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dK4yVZ48jr1; Thu, 28 Feb 2008 11:01:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965CF3A6A7C; Thu, 28 Feb 2008 11:01:46 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A47C3A6A0E for ; Thu, 28 Feb 2008 11:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGgvobr3ZmKi for ; Thu, 28 Feb 2008 11:01:30 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id CDD223A6A7C for ; Thu, 28 Feb 2008 11:01:29 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 19:01:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Feb 2008 19:01:21 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <005e01c87a0e$68b67d20$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN termination marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAA5ND4AAzOVZwAABtUzAAAHn78AALbRSQ From: To: , X-OriginalArrivalTime: 28 Feb 2008 19:01:22.0373 (UTC) FILETIME=[4F191750:01C87A3C] Subject: Re: [PCN] PCN termination marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245468313==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1245468313== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87A3C.4E909DBC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87A3C.4E909DBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> such that later on a selection on the algorithms is done. Actually I think we're now at the stage where we have good consensus on what the marking algorithms (behaviours) are. So now is the time to agree it! =20 - For admission, it reflects what's in anna's comparison draft - For termination, it also reflects what's in anna's comparison draft, with the added info we now have from michael's emft draft that 3SM termination system behaviour can be got with the CL marking behaviour (& a new edge behaviour). =20 > I thought that the idea of the architecture draft is to provide a description of the architectural options lars is discouraging this & trying to get us to make the choices now. I think we can do this for the marking really quite easily. The edge behaviour may be harder to reach consensus on.=20 =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 28 February 2008 13:33 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? =20 Hi Phil =20 My concerns are similar to the previous email that I have sent regarding admission control. I would like to have a more clear understanding on what you are proposing before we can get any consensus! In my option all options that are currently decribed in the current version of the archietcture draft will be reduced at the moment that the encoding method is selected and probably also when the PCN algorithms used at interior and edges are selected. I thought that the idea of the architecture draft is to provide a description of the architectural options that can be used, such that later on a selection on the algorithms is done. If that is not the case then the publication of the architecture draft should be delayed until the above selections are done! Best regards, Georgios =20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: donderdag 28 februari 2008 14:27 To: karagian@cs.utwente.nl; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? We've got to have *one* metering function for termination (& one for adm).=20 =20 I thought the idea was that lc-pcn would get into anna's comparison draft, ie in the same format & the same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!).=20 =20 Even so, I looked at the latest lc-pcn & S4.3.1 (interior node & termination) and it says: The PCN-interior-nodes can measure the PHB aggregated PCN traffic that exceeds a configured-admissible-rate and mark this excess PCN traffic =20 which is exactly what the email below does. =20 Please explain what youre concerned about! thanks. =20 Phil/ =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 28 February 2008 13:08 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN termination marking algorithm - consensus? =20 Hi Phil =20 I am not in favour of using the token bucket as the only metering function that can be used in PCN! Regarding the comparison, I think that if you want to base any decission on it, then=20 the LC-PCN algorithm should also be included in this comparison! =20 Best regards, Georgios =20 =20 =20 =20 =20 =20 =09 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: woensdag 27 februari 2008 14:13 To: pcn@ietf.org Subject: [PCN] PCN termination marking algorithm - consensus? Here also is an attempt for consensus on the termination marking behaviour. =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 [Lars has commented: do we need to allow this choice?] =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if the PCN-packet is already "termination marked", as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*) If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. =20 Meter function: Note: The meter is described as a 'token bucket', however the implementation is not standardised. =20 A packet classified as a PCN-packet MUST be metered as follows.=20 The interface MUST have: [1] a configured bit rate, termed PCN-upper-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 a token bucket, operating in bits:=20 1A tokens are added at the PCN-upper-rate, to a maximum TB.size 1B tokens are removed equal to the size in bits of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill =3D 0, then the meter indicates "termination mark" to the Mark function =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 =20 The following SHOULD be done (**) instead of Step 2 above (Step 2 is then superfluous). if TB.fill < maximum size of PCN-packet, then the meter indicates "termination mark" to the Mark function The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in the PCN-domain.=20 Note: Step 1B above is still performed.=20 =20 =20 Mark function: If the meter indicates to "termination mark" a PCN-packet, then: the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination marked", as defined in [RFC-encoding] =20 =20 (*) Explanation: for CL termination (ie the termination based on rates, rather than the 3SM termination based on marked pkts), if the meter counts pkts that are already termination marked then there'll be over-termination in the event of multiple bottlenecks. However, since this option is probably more complicated to implement than a normal classifier (?), I suggest it is a SHOULD. =20 (**) Explanation: this captures the point that Michael makes in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 -PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02 .txt Otherwise flows with big pkts get marked more than flows with small pkts. However, since this option is more complicated to implement than a normal token bucket, I suggest it is a SHOULD. =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87A3C.4E909DBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>> such that later on a selection = on the algorithms is done.

Actually I think we’re now at = the stage where we have good consensus on what the marking algorithms = (behaviours) are. So now is the time to agree it!

 

- For admission, it reflects = what’s in anna’s comparison draft

- For termination, it also reflects = what’s in anna’s comparison draft, with the added info we now have from = michael’s emft draft that 3SM termination system behaviour can be got with the CL = marking behaviour (& a new edge behaviour).

 

> I thought that = the idea of the architecture draft is to provide a description of the = architectural options

lars is discouraging this & = trying to get us to make the choices now. I think we can do this for the marking = really quite easily. The edge behaviour may be harder to reach consensus on. =

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28 February 2008 13:33
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN = termination marking algorithm - consensus?

 

Hi Phil

 

My concerns are similar to the = previous email that I have sent regarding admission control.

I would like to have a more clear understanding on what you are proposing before = we can get any consensus!

In my option all options that are currently decribed in the current version of = the archietcture draft will be reduced at the moment that the encoding = method is selected and probably also when the PCN algorithms used at interior and = edges are selected.

I thought that the idea of the architecture draft is to provide a description of = the architectural options that can be used, such that later on a selection = on the algorithms is done.

If that is not the case then the publication of the architecture draft should be delayed until the above selections are done!

Best regards,

Georgios

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: donderdag 28 = februari 2008 14:27
To: = karagian@cs.utwente.nl; pcn@ietf.org
Subject: RE: [PCN] PCN = termination marking algorithm - consensus?

We’ve got to have *one* metering function for = termination (& one for adm).

 

I thought the idea was that lc-pcn = would get into anna’s comparison draft, ie in the same format & the = same general level of understanding of how it works (the latter being a pre-requisite to getting it in there!).

 

Even so, I looked at the latest = lc-pcn & S4.3.1 (interior node & termination) and it = says:

The PCN-interior-nodes can measure the PHB =
aggregated PCN traffic
   that exceeds a =
configured-admissible-rate and mark this excess PCN

   traffic

 

which is exactly what the email below does.

           = ;            =   

Please explain what youre concerned about!

thanks.

 

Phil/

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 28 February 2008 = 13:08
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN = termination marking algorithm - consensus?

 

Hi Phil

 

I am not in favour of using the = token bucket as the only metering function that can be used in = PCN!

Regarding the comparison, I think = that if you want to base any decission on it, then

the LC-PCN algorithm should also be included in this comparison!

 

Best regards,

Georgios

 

 

 

 

 

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: woensdag 27 = februari 2008 14:13
To: pcn@ietf.org
Subject: [PCN] PCN = termination marking algorithm - consensus?

Here also is an attempt for consensus on the = termination marking behaviour.

 

 

 If an interface of the PCN-domain performs PCN Admission = Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows:

 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

[Lars has commented: do we need to allow this = choice?]

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a PCN-packet. However, if = the PCN-packet is already “termination marked”, as defined in [RFC-encoding], then the Meter function SHOULD NOT be performed. = (*)

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a ‘token bucket’, = however the implementation is not standardised.

 

A packet classified as a PCN-packet MUST be metered as follows. =

The interface MUST have:

[1] a configured bit rate, termed = PCN-upper-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

 

a token bucket, operating in bits:

1A tokens are added at the PCN-upper-rate, to a maximum = TB.size

1B tokens are removed equal to the size in bits of the = PCN-packet, to a minimum TB.size=3D0

2 if TB.fill =3D 0, then the meter indicates “termination mark” to the Mark function

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step = 1

 

The following SHOULD be done (**) instead of Step 2 above (Step = 2 is then superfluous).

if TB.fill < maximum size of PCN-packet, then the meter = indicates “termination mark” to the Mark function

The “maximum size of PCN-packet” is the MTU in bits = of any PCN-packets in the PCN-domain.

Note: Step 1B above is still performed. =

 

 

Mark function:

If the meter indicates to “termination mark” a = PCN-packet, then:

the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “termination marked”, as defined in = [RFC-encoding]

 

 

(*) Explanation: for CL termination (ie the termination based on = rates, rather than the 3SM termination based on marked pkts), if the meter = counts pkts that are already termination marked then there’ll be = over-termination in the event of multiple bottlenecks. However, since this option = is probably more complicated to implement than a normal classifier (?), I = suggest it is a SHOULD.

 

(**) Explanation: this captures the point that Michael = makes in http://www3.informatik.uni-wuerzburg.de/staff/= menth/Publications/Menth08-PCN-MFT.pdf & Bob makes in http://www.ietf.org/internet-drafts/draft-bris= coe-tsvwg-byte-pkt-mark-02.txt Otherwise flows with big pkts get marked more than flows with small = pkts. However, since this option is more complicated to implement than a = normal token bucket, I suggest it is a SHOULD.

 

we could also add an example algorithm, such as that = in http://www.ietf.org/internet-drafts/draft-char= ny-pcn-comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87A3C.4E909DBC-- --===============1245468313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1245468313==-- From pcn-bounces@ietf.org Fri Feb 29 00:01:08 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29B128C544; Fri, 29 Feb 2008 00:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 o-N7UAz9QcDX; Fri, 29 Feb 2008 00:01:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6720628C21F; Fri, 29 Feb 2008 00:01:02 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5A228C21F for ; Fri, 29 Feb 2008 00:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2CdYhhayPr9 for ; Fri, 29 Feb 2008 00:00:59 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 27A3B28C180 for ; Fri, 29 Feb 2008 00:00:59 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Fri, 29 Feb 2008 09:00:48 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Feb 2008 09:00:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 09:01:53 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0ACDE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FE@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEngAALAuiAAHlmIIA== References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FE@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Feb 2008 08:00:47.0886 (UTC) FILETIME=[318412E0:01C87AA9] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, as mentioned in another thread: the operator I'm working for is currently not interested in supporting protocols requiring RAO processing in backbone routers. Please also keep in mind MPLS friendliness - RAO based mechanisms are useless in that case. DiffServ mechanisms are generally more MPLS friendly than IntServ mechanisms. Georgios idea may have merits and I don't oppose further development fundamentally. But it shouldn't be more than an option (on which Georgios seems to agree). Taking a security viewpoint, messages requiring slow path processing by backbone routers may have to carry some authentification information (which won't make slow path processing faster) and may also have to be rate limited by backbone routers. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of philip.eardley@bt.com | Sent: Thursday, February 28, 2008 7:53 PM | To: acharny@cisco.com; menth@informatik.uni-wuerzburg.de | Cc: pcn@ietf.org | Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | | Hi | | Thanks for clarifying Georgios. interesting idea. | | Just to go back to the basic reason why single marking's attractive. | [1] single marking behaviour on interior routers [2] only | single encoding needed | | your idea at first sight has just one marking behaviour, ie | excess rate marking. Indeed, it only has one token bucket. | However, it does have extra code/complexity in order to do | threshold marking for probe pkts, and this involves the pkt | being processed on the slow path within a router. I guess | this complexity is for pkt classification & PCN-encoding, | rather than for the PCN-metering function. | | in terms of encoding, it does have a second encoding, but it | uses RAO bits rather than ECN/DSCP bits. | | I worry a bit about security attacks (because probe pkts can now be | identified) and about deploability barrier (will operators | deploy something that slows all their core routers - after | all we claimed one advantage of PCN over hop-by-hop rsvp is | that your core routers are really simple, don't have to do | any difficult processing... | | phil | | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of | Anna | > Charny (acharny) | > Sent: 28 February 2008 16:08 | > To: menth@informatik.uni-wuerzburg.de | > Cc: pcn | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > | > Hi Michael, | > | > Ah - that makes perfect sense. Thank you for the concise summary. | > | > Anna | > | > > -----Original Message----- | > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] | > > Sent: Thursday, February 28, 2008 10:51 AM | > > To: Anna Charny (acharny) | > > Cc: Lars Eggert; pcn | > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > > | > > Hi Anna, | > > | > > Anna Charny (acharny) wrote: | > > > Hi Michael, | > > > | > > > You lost me on this. The discussion seems to be centered | > > around the | > > > complexities of appropriately forwarding and processing | > > probe packets | > > > in the core. What exactly does excess rate marking has to | > > do with it? | > > > (I do understand the point that excess rate marking needs | > > more probes | > > > to work reliably than threshold-vased/aka | > > vertuall-queue-based marking | > > > - I just do not see the connection of this point to the | > > discussion it | > > > seems to relate to). | > > > | > > | > > Georgios proposes to do excess rate marking and to avoid multiple | > > probes, he wants to make sure that probe packets are always | > > AM-marked when a link is precongested with regard to the | admissible | > > rate. He solves this problem using the router alert option (RAO) | > > taking packets off the fast path. This solves the problem | you have | > > described above (which is caused by excess rate marking), but | > > introduces the problem of RAO. | > > That impacts the forwarding of the packets as they need special | > > handling by the routers. The origin of this thread was that the | > > architecture draft said that all pcn packets should be treated in | > > the same way by PCN nodes which is no longer the case for normal | > > data packet and PCN packets. | > > | > > Regards, | > > | > > Michael | > > | > > > If I am missing your point (or the point of the discussion) | > > - which is | > > > quite possible as I am reading the thread backwards - I | would much | > > > appreciate a clarification. | > > > | > > > Anna | > > > | > > > | > > >> -----Original Message----- | > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] | > > On Behalf Of | > > >> Michael Menth | > > >> Sent: Thursday, February 28, 2008 5:50 AM | > > >> To: Lars Eggert | > > >> Cc: pcn | > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > > >> | > > >> Hi Lars, | > > >> | > > >> I just want to point out that this complexity is not due | > > to probing | > > >> itself but due to the use of excess rate marking for admission | > > >> control. | > > >> There is no such increased complexity if probing is done in | > > >> combination with exhaustive (threshold) marking for | > > admission control. | > > >> | > > >> Regards, | > > >> | > > >> Michael | > > >> | > > >> Lars Eggert wrote: | > > >> | > > >>> Hi, | > > >>> | > > >>> I'm not sure if I have fully digested this yet, but it | > > >>> | > > >> seems like this | > > >> | > > >>> proposal defines different semantics for what the PCN | > > marks mean to | > > >>> both the interior and egress nodes, depending on whether a | > > >>> | > > >> packet is a | > > >> | > > >>> probe packet or not. That seems to add significant complexity. | > > >>> | > > >>> Lars | > > >>> | > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: | > > >>> | > > >>> | > > >>> | > > >>>> Hi Phil | > > >>>> | > > >>>> Sorry for not being clear! | > > >>>> | > > >>>> As you know if ECMP routing is used then this might cause | > > >>>> | > > >> problems on | > > >> | > > >>>> the way of how admission control and flow termination | > > >>>> | > > >> algorithms are | > > >> | > > >>>> operating. | > > >>>> | > > >>>> The ECMP problem is related to the fact that flows can | > > belong to a | > > >>>> certain ingress-egress-aggregate, which is maintained at | > > >>>> | > > >> the ingress | > > >> | > > >>>> adn egress and that operates in admission control | state or flow | > > >>>> termination state, but that due to the ECMP routing they are | not | > > >>>> passing through the congested node. | > > >>>> | > > >>>> Any measures that are taken on such flows will not solve the | > > >>>> congestion problem, since such flows are not contributing | > > >>>> | > > >> and causing | > > >> | > > >>>> the congestion in the PCN-interior-node. | > > >>>> | > > >>>> Now when probing is used this problem can be solved | as follows. | > > >>>> When a PCN-interior-node is congested it MUST | > > PCN_marking encode a | > > >>>> probe packet. | > > >>>> | > > >>>> | > > >>>> Thus if an egress operates, for a certain | > > >>>> | > > >> ingress-egress-agrregate in | > > >> | > > >>>> admission control state and it receives a probe packet | > > >>>> | > > >> which belongs | > > >> | > > >>>> to a flow associated with the same | > > >>>> | > > >> ingress-egress-agrregate AND the | > > >> | > > >>>> probe packet is PCN_marking encoded, then the egress knows | > > >>>> | > > >> for sure | > > >> | > > >>>> that the probe packet passed through one or more congested | > > >>>> PCN-interior-nodes. In this case the probe packet, and | > > >>>> | > > >> thus also the | > > >> | > > >>>> requiesting flow can be rejected. | > > >>>> | > > >>>> If an egress operates, for a certain ingress-egress-agrregate | in | > > >>>> admission control state and it receives a probe packet | > > >>>> | > > >> which belongs | > > >> | > > >>>> to a flow associated with the same | > > >>>> | > > >> ingress-egress-agrregate AND the | > > >> | > > >>>> probe packet is marked as not congested PCN, then the | > > egress knows | > > >>>> for sure that the probe packet HAS NOT PASSED through a | > > congested | > > >>>> PCN-interior-node due to e.g., used ECMP routing. In | > > this case the | > > >>>> probe packet can be accepted, since this flow, even it | > > >>>> | > > >> belongs to the | > > >> | > > >>>> ingress-egress-aggergate that operates in admission | > > >>>> | > > >> control, is not | > > >> | > > >>>> contributing and causing the congestion in the | PCN-interior-node. | > > >>>> | > > >>>> | > > >>>> Okay, but why one should provide the possibility to | > > PCN-interior- | > > >>>> nodes to distinguish between probe packets and other PCN | > > >>>> | > > >> aware user | > > >> | > > >>>> packets? | > > >>>> | > > >>>> This is related to which admission control and flow | termination | > > >>>> algorithms and encodings are used in the PCN-interior-nodes. | > > >>>> | > > >>>> If an algorithm uses one encoding state for admission | > > control and | > > >>>> another encoding state for flow termination then probably | > > >>>> | > > >> it is not | > > >> | > > >>>> required to provide the possibility to PC_interior-node to | > > >>>> distinguish between probe packets and PCN aware user packets. | > > >>>> This is because when the PCN-interior-node that operates | > > >>>> | > > >> in admission | > > >> | > > >>>> control state will AM (admission control encoding state) | > > >>>> | > > >> encode all | > > >> | > > >>>> packets, i.e., probe packets and user packets. | > > >>>> | > > >>>> If an algorithm uses only one encoding state for | > > admission control | > > >>>> and flow termionation, such as the ones used in the | > > single marking | > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut | > > be able to | > > >>>> distinguish between probe packets and user data packets. | > > >>>> | > > >>>> This is because both algorithms SM and LC-PCN are | > > encoding packets | > > >>>> proportionaly to the excess rate. | > > >>>> This means that when the PCN-interior-node opetrates in | > > admission | > > >>>> control state it will not SM mark all packets that | are passing | > > >>>> through the node, but only a proportion that is needed to | > > >>>> | > > >> represent | > > >> | > > >>>> the excess rate. Thus if the PCN-interior-node will not | > > >>>> | > > >> distinguish | > > >> | > > >>>> between the probe packets and other PCN aware packets, | > > >>>> | > > >> then it is not | > > >> | > > >>>> certain that the probe packet will be SM marked when the | > > >>>> PCN-interior-node operates in admission control state. | > > >>>> Now, if the probe packets carry a Router Alert option, | > > and when in | > > >>>> Admission control state, the PCN-interior-node marks all | > > >>>> | > > >> packets that | > > >> | > > >>>> are carrying a Router Alert option, then the probe packet | > > >>>> | > > >> will be for | > > >> | > > >>>> sure marked. | > > >>>> | > > >>>> Hope that this clarifies your question! | > > >>>> | > > >>>> Best regards, | > > >>>> Georgios | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>> | > > >>>>> -----Original Message----- | > > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > > >>>>> Sent: dinsdag 26 februari 2008 18:16 | > > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > > >>>>> Cc: pcn@ietf.org | > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > > >>>>> | > > >>>>> Sorry, to repeat: | > > >>>>> | > > >>>>> I still have not the foggiest idea why on earth someone | > > >>>>> | > > >> would want | > > >> | > > >>>>> or need or be interested in the interior node handling | > > probe pkts | > > >>>>> differently from the way it handles probe pkts. | > > >>>>> | > > >>>>> So far you have answered a different question, about whether | it | > > >>>>> would be possible for someone to devise pcn so that an | > > >>>>> | > > >> interior node | > > >> | > > >>>>> could distinguish probe pkts from data pkts. As you | > > say, a router | > > >>>>> alert option could indeed be used. | > > >>>>> | > > >>>>> | > > >>>>> | > > >>>>>> -----Original Message----- | > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > > >>>>>> Sent: 26 February 2008 17:06 | > > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com | > > >>>>>> Cc: pcn@ietf.org | > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > > >>>>>> | > > >>>>>> Hi Phil | > > >>>>>> | > > >>>>>> * Regarding Routing NOT, | > > >>>>>> * Regarding scheduling, NOT | > > >>>>>> * Regarding PCN_marking, it could be handled differently: | > > >>>>>> | > > >>>>>> ** if excess rate marking is used AND the | PCN-interior-node | is | > > >>>>>> | > > >>>>>> | > > >>>>> congested | > > >>>>> | > > >>>>> | > > >>>>>> AND | > > >>>>>> the probe packet contains the ROUTER ALERT option THEN | > > >>>>>> the probe packet can be distinguished from the other | > > >>>>>> | > > >>>>>> | > > >>>>> PCN packets, | > > >>>>> | > > >>>>> | > > >>>>>> and therefore it will be for sure PCN_marking encoded. | > > >>>>>> | > > >>>>>> ** if excess rate marking is used AND the | PCN-interior-node | is | > > >>>>>> | > > >>>>>> | > > >>>>> congested | > > >>>>> | > > >>>>> | > > >>>>>> AND | > > >>>>>> the probe packet DOES NOT contain the ROUTER | ALERT option | > > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not | be | > > >>>>>> PCN_marking encoded. This depends | > > >>>>>> on whether this probe packet is selected to represent | > > >>>>>> | > > >>>>>> | > > >>>>> the excess | > > >>>>> | > > >>>>> | > > >>>>>> rate, or is not selected. | > > >>>>>> | > > >>>>>> Best regards, | > > >>>>>> Georgios | > > >>>>>> | > > >>>>>> | > > >>>>>> | > > >>>>>> | > > >>>>>> | > > >>>>>> | > > >>>>>> | > > >>>>>>> -----Original Message----- | > > >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 | > > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com | > > >>>>>>> Cc: pcn@ietf.org | > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | > > >>>>>>> | > > >>>>>>> But why would the interior node *need* to distinguish it | > > >>>>>>> | > > >>>>>>> | > > >>>>> from other | > > >>>>> | > > >>>>> | > > >>>>>>> pcn pkts? | > > >>>>>>> | > > >>>>>>> And even if you have got router alert, the architecture | > > >>>>>>> | > > >>>>>>> | > > >>>>> draft says: | > > >>>>> | > > >>>>> | > > >>>>>>> "must be handled the same as (ordinary data) PCN-packets, | > > >>>>>>> | > > >>>>>>> | > > >>>>> in terms | > > >>>>> | > > >>>>> | > > >>>>>>> of routing, scheduling and PCN-marking." | > > >>>>>>> Even though your router alert's got it in slow path, will | > > >>>>>>> | > > >>>>>>> | > > >>>>> it handle | > > >>>>> | > > >>>>> | > > >>>>>>> it any differently in terms of routing scehdulign & | > > pcn-marking? | > > >>>>>>> | > > >>>>>>> | > > >>>>>>> | > > >>>>>>> | > > >>>> _______________________________________________ | > > >>>> 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 | > > >>> | > > >>> | > > >> -- | > > >> 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 | > > | > > | > _______________________________________________ | > 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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 29 00:10:09 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4975328C12D; Fri, 29 Feb 2008 00:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 cYnA5ymkJGK2; Fri, 29 Feb 2008 00:10:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5C628C182; Fri, 29 Feb 2008 00:10:04 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A2928C164 for ; Fri, 29 Feb 2008 00:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHQN4MNJ4ewz for ; Fri, 29 Feb 2008 00:10:01 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 5D35028C236 for ; Fri, 29 Feb 2008 00:09:59 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 29 Feb 2008 09:09:49 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Feb 2008 09:09:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 09:10:54 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0ACED@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1204126840.3044.7.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: draft-ietf-pcn-architecture-03 Thread-Index: Ach5VyVUnFEuqff0TG6SQ3mJ2z3MewBUkZqw References: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> <1204126840.3044.7.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Feb 2008 08:09:49.0235 (UTC) FILETIME=[742F6030:01C87AAA] Cc: pcn@ietf.org Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, how many operators and vendors you know deploy or support L-LSPs? Regards, Rudiger | -----Original Message----- | From: Steven Blake [mailto:steven.blake@ericsson.com] = | Sent: Wednesday, February 27, 2008 4:41 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03 | = | On Wed, 2008-02-27 at 09:45 +0100, Geib, Ruediger wrote: | = | > [RG] We MUST have different deployment options. Two points: | > - if your network is MPLS based, it's single codepoint marking. | > - if you don't want to support termination, you just need single = | > codepoint marking. | > IP based networks aiming on termination may fare better with the = | > second codepoint/threshold. But that applies just in the case of = | > an IP based network. If PCN makes the two thresholds a requirement= , = | > then it won't see deployment in carrier backbones, it's a corporat= e = | > network feature. I don't think, that's a good choice. | = | Ruediger, | = | I don't follow your comment regarding MPLS and single = | codepoint marking. | EXP bits are scarce, but I don't see what it is that = | precludes using EXP codepoint to indicate three or more = | encoding states, perhaps through use of L-LSPs. | = | = | Regards, | = | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | Steven Blake | Ericsson/Redback Networks +1 919-472-9913 | = | _______________________________________________ | 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 From pcn-bounces@ietf.org Fri Feb 29 00:21:05 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CC628C4CE; Fri, 29 Feb 2008 00:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.467 X-Spam-Level: * X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[AWL=-1.797, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfrzdJzOGxg0; Fri, 29 Feb 2008 00:20:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFEC28C476; Fri, 29 Feb 2008 00:20:53 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E10728C476 for ; Fri, 29 Feb 2008 00:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTqPNd5a6wai for ; Fri, 29 Feb 2008 00:20:41 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 57D5D28C31B for ; Fri, 29 Feb 2008 00:20:38 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 08:20:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 08:20:29 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34607@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EC@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVAAXygvEA== From: To: X-OriginalArrivalTime: 29 Feb 2008 08:20:31.0151 (UTC) FILETIME=[F2CBFBF0:01C87AAB] Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1908593603==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1908593603== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87AAB.F205F1F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87AAB.F205F1F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anna has pointed out to me that this email should talk about "PCN threshold marking" rather than "PCN Admission marking". Similarly the other email should be about "PCN excess marking" rather than "PCN termination marking". This reflects what we agreed a couple of ietfs ago & also the phrasing in the architecture draft. Sorry & thanks anna for spotting the mistake =20 phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 27 February 2008 11:02 To: pcn@ietf.org Subject: [PCN] PCN admission marking algorithm - consensus? =20 I think we have consensus on the admission marking behaviour. This is a first attempt to capture that in Stds language, is it any use? =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. =20 Meter function: Note: The meter is described as a 'token bucket with threshold', however the implementation is not standardised. For example, it could equally well be implemented as a virtual queue (which operates with negative tokens). =20 A packet classified as a PCN-packet MUST be metered as follows.=20 The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 a token bucket, which=20 1A tokens are added at the PCN-lower-rate, to a maximum TB.size 1B tokens are removed equal to the size of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" to the Mark function =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 =20 If TB.fill < size of the PCN-packet, then the meter MAY: a. leave TB.fill unaltered and indicate "admission mark" to the Mark function b. set TB.fill =3D 0 and indicate "admission mark" to the Mark function c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and if it is, then indicate "admission mark" to the Mark function =20 Note: Option a is expected to be the simplest to implement.=20 =20 =20 Mark function: If the meter indicates to "admission mark" a PCN-packet, then: [1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously "admission marked" and "termination marked": If the PCN-packet's codepoint is already "termination mark" then it MUST NOT be altered, ie the following step is not performed. [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "admission marked", as defined in [RFC-encoding] =20 =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87AAB.F205F1F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anna has pointed out to me that = this email should talk about “PCN threshold marking” rather than = “PCN Admission marking”. Similarly the other email should be about = “PCN excess marking” rather than “PCN termination marking”. = This reflects what we agreed a couple of ietfs ago & also the phrasing in the architecture draft. Sorry & thanks anna for spotting the = mistake

 

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of philip.eardley@bt.com
Sent: 27 February 2008 11:02
To: pcn@ietf.org
Subject: [PCN] PCN = admission marking algorithm - consensus?

 

I think we have consensus on the = admission marking behaviour. This is a first attempt to capture that in Stds = language, is it any use?

 

 

If an interface of the PCN-domain performs =
PCN Admission Marking then it performs three functions, which are =
outlined in draft-ietf-pcn-architecture as =
follows:
 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

 

Meter function:

Note: The meter is described as a ‘token bucket with threshold’, however the implementation is not standardised. For = example, it could equally well be implemented as a virtual queue (which operates = with negative tokens).

 

A packet classified as a PCN-packet MUST be metered as follows. =

The interface MUST have:

[1] a configured bit rate, termed = PCN-lower-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

 

a token bucket, which

1A tokens are added at the PCN-lower-rate, to a maximum = TB.size

1B tokens are removed equal to the size of the PCN-packet, to a = minimum TB.size=3D0

2 if TB.fill < TB.threshold, then the meter indicates “admission mark” to the Mark function

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step 1

 

If TB.fill < size of the PCN-packet, then the meter = MAY:

a. leave TB.fill unaltered and indicate “admission = mark” to the Mark function

b. set TB.fill =3D 0 and indicate “admission mark” = to the Mark function    

c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and = if it is, then indicate “admission mark” to the Mark function       

Note: Option a is expected to be the simplest to implement. =

 

 

Mark function:

If the meter indicates to “admission mark” a = PCN-packet, then:

[1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously “admission marked” and “termination marked”:

If the PCN-packet’s codepoint is already = “termination mark” then it MUST NOT be altered, ie the following step is not performed.

[2] the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “admission marked”, as defined in = [RFC-encoding]

 

 

we could also add an example = algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-= comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87AAB.F205F1F4-- --===============1908593603== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1908593603==-- From pcn-bounces@ietf.org Fri Feb 29 00:28:32 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBF828C26D; Fri, 29 Feb 2008 00:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 0d1xqhLubRFg; Fri, 29 Feb 2008 00:28:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBA528C142; Fri, 29 Feb 2008 00:28:31 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985A73A6EC3 for ; Fri, 29 Feb 2008 00:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8-bx2FUTjkF for ; Fri, 29 Feb 2008 00:28:24 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 15CCB28C12D for ; Fri, 29 Feb 2008 00:28:24 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 29 Feb 2008 09:28:16 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Feb 2008 09:28:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 09:29:18 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0AD0E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EB@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach4mQBIaL7p7PTmRYSHvTwNloLxMAAjoT5wAGDduPA= References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345EB@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Feb 2008 08:28:13.0304 (UTC) FILETIME=[0642EF80:01C87AAD] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, regarding single codepoint marking, I don't see any other viable option if PCN is to be supported by MPLS backbones. What's your position on that? Regards, Rudiger | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] | Sent: Wednesday, February 27, 2008 11:50 AM | To: lars.eggert@nokia.com; steven.blake@ericsson.com | Cc: pcn@ietf.org | Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | | Lars, | Thanks for the detailed pointers on what we need to come to | consensus on. And the other detailed comments. | Thanks for the follow-up Rudiger. | | Summary:- | | 1. I think we have consensus on the admission marking | behaviour, I'll send a separate email on this shortly. | | 2. I think we have consensus on the termination marking | behaviour, I'll send a separate email on this shortly. | Assuming that Joe is convinced by Michael's EMFT i-d. | | 3. in terms of edge behaviour for admission & termination, do | we need consensus on one solution? Since the Charter I | thought that the approach was that edge behaviour is in Info | docs and that there could be more than one edge behaviour | (but a single Std for interior behaviour). | Anyway, there are two approaches suggested for admission | (level of congestion & probing) and two for termination | (measuring rates and termination based on flow being marked). | I don't know how to reach consensus on doing one of each - | perhaps we could have consensus on which to do first??? | | 4. in terms of where the decision making functionality | resides, the ingress is probably more natural - since it | polices flows and understands any other flow requirements | that might impact the decision (such as relative importance). | As to what is signalled, I guess that partly depends on what | approach is being taken in point 3. | the centralised node is also possible for decision making, | but it's clearly understood that this is out of scope. | | 5. you asked about single marking. I don't know if we have | consensus. My view is that the single marking approach isn't | accurate enough for admission control, except perhaps as a | migration step. allowing this possibility would require a bit | more complexity in the edge behaviour Info doc (extra | parameter configured same for all boundary nodes, tweak to | termination behaviour at edges). | | A few follow-ups below (the rest I'll just work in). | | Thanks | phil | | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of | Lars | > Eggert | > Sent: 26 February 2008 17:00 | > To: ext Steven Blake | > Cc: pcn | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | > | > | > Section 1., paragraph 21: | > > o The PCN-domain extends to the end users. The scenario is | > > described in [I-D.babiarz-pcn-sip-cap]. A variant is that | the | > > PCN-domain extends out as far as the LAN edge switch. | > | > This deployment model may not be possible under the initial | charter, | > or maybe even under an extended charter, because it is not clear | that | > sufficient statistical multiplexing exists on the links near the | edge | > to make PCN work, which is a *fundamental* assumption of PCN (see | > assumption 3 in Section 3). Listing this deployment | scenario here | > when | > we aren't sure how to support it raises false expectations - I'd | > hence | > propose to drop this bullet item. | | Yes, it assumes that the links near the edge have sufficient | stat multiplexing. I'll move it to the Appendix, with a note | that if there is sufficient stat multiplexing then it's in scope. | | > Section 4.3., paragraph 4: | > > A different possibility is to configure only the | PCN-lower-rate | > and | > > hence only do one type of PCN-marking, but generate admission | and | > > flow termination responses from different levels of marking. | > This is | > > suggested in [I-D.charny-pcn-single-marking] which | gives some of | > the | > > pros and cons of this approach. | > | > draft-charny is at odds with the second paragraph of the intro, | which | > says that each link has a PCN-lower-rate and a PCN-upper-rate. If | the | > intent of the architecture is to permit a proposal like | draft-charny, | > those concepts need to be re-defined. | > | | I'll try & clarify this. | I think S4.3. (Flow admission and flow termination) needs to | be clarified, and to clarify in Intro that PCN-domain doesn't | have to do admission & termination, but could just do one of them. | | | > | > | > Section 5.4., paragraph 8: | > > The decision needs to be passed to the application | layer so that | > it | > > can take the appropriate action. | > | > The application layer at what node? And define "appropriate". | | I think this sentence can be deleted, as it's already covered | by the earlier para in S5.4: " o Communicate decision about | admission " | | > | > | > Section 5.6., paragraph 4: | > > o Use a probe packet that includes as payload the address of | the | > > PCN-ingress-node. | > | > I don't understand how a probe packet can be used by the | egress to | > determine the address of the ingress, if the egress | needs to know | > this | > address to send the probe packet. (But see my comment on probing | > below; | > this may be moot.) | | "if the egress..." | not sure I understand, it's the ingress that sends the probe | pkt. The idea was that when the ingress sends the probe, it | inserts into the pkt its address (ie the ingress address) - | which the egress then extracts when it gets the probe. | | > | > Section 7., paragraph 0: | > > 7. Probing | > | > I am still opposed to probing as part of the PCN | architecture. It | > is a | > *very* complex mechanism with lots of open issues surrounding how | it | > could actually be implemenented that in the end serves only one | > purpose: to slightly increase capacity utilization in a | PCN domain. | > However, PCN was never meant to remove the need for sufficient | > overprovisioning. A second reason is that probing is only really | > needed to extend PCN into scenarios where some of the assumptions | > (sufficient multiplexing, etc.) are no longer true. We | already have | a | > boatload of explicitly-signalled QoS architectures that were | designed | > for just such scenarios. I see no reason to complicate | PCN into yet | > another signalled-QoS system. | > | > We already had consensus in Vancouver to stop discussing probing | > until | > after work on the initial milestones has finished. I'd like to | > propose | > to remove the discussion of probing from the | architecture at least | > until | > that time. | | I can move the Probing section to an Appendix. Of course I | could also delete it, although I guess there'll be objections to that. | | > | > ------------------------------------------ | > | > NITS (only of interest to the authors) | > | > Nit: eliminate use of first person (throughout the document) | > Nit: s/ie/i.e.,/ (everywhere) | > Nit: s/eg/e.g.,/ (everywhere) | | they can be spelt with or without the dots. I read somewhere | that without dots is the modern usage & have been a convert | ever since! | | > | > Section 2., paragraph 1: | > > nodes that perform DiffServ scheduling; the compete set of | PCN- | > | > Nit: s/compete/complete/ | > | > Section 4.3., paragraph 2: | > > sessions end, existing microflows naturally depart from the | system | > | > Nit: s/microflow/flow/ (or else define what a microflow is; also | > elsewhere in the document) | | thanks, I managed to miss some. They mostly should be flow. | Where it means microflow I added ref to RFC2475 (eg in the | PCN-traffic definition in S2) | | > | > _______________________________________________ | > PCN mailing list | > PCN@ietf.org | > http://www.ietf.org/mailman/listinfo/pcn | _______________________________________________ | 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 From pcn-bounces@ietf.org Fri Feb 29 01:25:00 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C5128C897; Fri, 29 Feb 2008 01:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 4jCC89TdIKom; Fri, 29 Feb 2008 01:24:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA2228C236; Fri, 29 Feb 2008 01:24:58 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B20F28C164 for ; Fri, 29 Feb 2008 01:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JUIcErH7yiq for ; Fri, 29 Feb 2008 01:24:50 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 8EFA028C619 for ; Fri, 29 Feb 2008 01:24:50 -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 m1T9OQFo021102; Fri, 29 Feb 2008 10:24:33 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FE@E03MVZ1-UKDY.domain1.systemhost.net> Date: Fri, 29 Feb 2008 10:24:21 +0100 Message-ID: <000f01c87ab4$e361f990$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B345FE@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEngAALAuiAAIWGyEA== 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]); Fri, 29 Feb 2008 10:24:35 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Regarding the below comment! > in terms of encoding, it does have a second encoding, but it > uses RAO bits rather than ECN/DSCP bits. > > I worry a bit about security attacks (because probe pkts can now be > identified) and about deploability barrier (will operators > deploy something that slows all their core routers - after > all we claimed one advantage of PCN over hop-by-hop rsvp is > that your core routers are really simple, don't have to do > any difficult processing... In the architecture draft we mention that Intserv over Diffserv is one of the scenarios that could be supported by PCN. In this case I assume that RSVP will be used as the Intserv signaling protocol. RSVP PATH carries already a Router Alert option. The only additional functionality in the PCN-interior-nodes, is to use the RAO bits for detection rather than an additional ECN/DSCP code. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: donderdag 28 februari 2008 19:53 > To: acharny@cisco.com; menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi > > Thanks for clarifying Georgios. interesting idea. > > Just to go back to the basic reason why single marking's attractive. > [1] single marking behaviour on interior routers [2] only > single encoding needed > > your idea at first sight has just one marking behaviour, ie > excess rate marking. Indeed, it only has one token bucket. > However, it does have extra code/complexity in order to do > threshold marking for probe pkts, and this involves the pkt > being processed on the slow path within a router. I guess > this complexity is for pkt classification & PCN-encoding, > rather than for the PCN-metering function. > > in terms of encoding, it does have a second encoding, but it > uses RAO bits rather than ECN/DSCP bits. > > I worry a bit about security attacks (because probe pkts can now be > identified) and about deploability barrier (will operators > deploy something that slows all their core routers - after > all we claimed one advantage of PCN over hop-by-hop rsvp is > that your core routers are really simple, don't have to do > any difficult processing... > > phil > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > Anna > > Charny (acharny) > > Sent: 28 February 2008 16:08 > > To: menth@informatik.uni-wuerzburg.de > > Cc: pcn > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi Michael, > > > > Ah - that makes perfect sense. Thank you for the concise summary. > > > > Anna > > > > > -----Original Message----- > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > Sent: Thursday, February 28, 2008 10:51 AM > > > To: Anna Charny (acharny) > > > Cc: Lars Eggert; pcn > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > Hi Anna, > > > > > > Anna Charny (acharny) wrote: > > > > Hi Michael, > > > > > > > > You lost me on this. The discussion seems to be centered > > > around the > > > > complexities of appropriately forwarding and processing > > > probe packets > > > > in the core. What exactly does excess rate marking has to > > > do with it? > > > > (I do understand the point that excess rate marking needs > > > more probes > > > > to work reliably than threshold-vased/aka > > > vertuall-queue-based marking > > > > - I just do not see the connection of this point to the > > > discussion it > > > > seems to relate to). > > > > > > > > > > Georgios proposes to do excess rate marking and to avoid multiple > > > probes, he wants to make sure that probe packets are always > > > AM-marked when a link is precongested with regard to the > admissible > > > rate. He solves this problem using the router alert option (RAO) > > > taking packets off the fast path. This solves the problem > you have > > > described above (which is caused by excess rate marking), but > > > introduces the problem of RAO. > > > That impacts the forwarding of the packets as they need special > > > handling by the routers. The origin of this thread was that the > > > architecture draft said that all pcn packets should be treated in > > > the same way by PCN nodes which is no longer the case for normal > > > data packet and PCN packets. > > > > > > Regards, > > > > > > Michael > > > > > > > If I am missing your point (or the point of the discussion) > > > - which is > > > > quite possible as I am reading the thread backwards - I > would much > > > > appreciate a clarification. > > > > > > > > Anna > > > > > > > > > > > >> -----Original Message----- > > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > On Behalf Of > > > >> Michael Menth > > > >> Sent: Thursday, February 28, 2008 5:50 AM > > > >> To: Lars Eggert > > > >> Cc: pcn > > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > >> > > > >> Hi Lars, > > > >> > > > >> I just want to point out that this complexity is not due > > > to probing > > > >> itself but due to the use of excess rate marking for admission > > > >> control. > > > >> There is no such increased complexity if probing is done in > > > >> combination with exhaustive (threshold) marking for > > > admission control. > > > >> > > > >> Regards, > > > >> > > > >> Michael > > > >> > > > >> Lars Eggert wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> I'm not sure if I have fully digested this yet, but it > > > >>> > > > >> seems like this > > > >> > > > >>> proposal defines different semantics for what the PCN > > > marks mean to > > > >>> both the interior and egress nodes, depending on whether a > > > >>> > > > >> packet is a > > > >> > > > >>> probe packet or not. That seems to add significant complexity. > > > >>> > > > >>> Lars > > > >>> > > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > > >>> > > > >>> > > > >>> > > > >>>> Hi Phil > > > >>>> > > > >>>> Sorry for not being clear! > > > >>>> > > > >>>> As you know if ECMP routing is used then this might cause > > > >>>> > > > >> problems on > > > >> > > > >>>> the way of how admission control and flow termination > > > >>>> > > > >> algorithms are > > > >> > > > >>>> operating. > > > >>>> > > > >>>> The ECMP problem is related to the fact that flows can > > > belong to a > > > >>>> certain ingress-egress-aggregate, which is maintained at > > > >>>> > > > >> the ingress > > > >> > > > >>>> adn egress and that operates in admission control > state or flow > > > >>>> termination state, but that due to the ECMP routing they are > not > > > >>>> passing through the congested node. > > > >>>> > > > >>>> Any measures that are taken on such flows will not solve the > > > >>>> congestion problem, since such flows are not contributing > > > >>>> > > > >> and causing > > > >> > > > >>>> the congestion in the PCN-interior-node. > > > >>>> > > > >>>> Now when probing is used this problem can be solved > as follows. > > > >>>> When a PCN-interior-node is congested it MUST > > > PCN_marking encode a > > > >>>> probe packet. > > > >>>> > > > >>>> > > > >>>> Thus if an egress operates, for a certain > > > >>>> > > > >> ingress-egress-agrregate in > > > >> > > > >>>> admission control state and it receives a probe packet > > > >>>> > > > >> which belongs > > > >> > > > >>>> to a flow associated with the same > > > >>>> > > > >> ingress-egress-agrregate AND the > > > >> > > > >>>> probe packet is PCN_marking encoded, then the egress knows > > > >>>> > > > >> for sure > > > >> > > > >>>> that the probe packet passed through one or more congested > > > >>>> PCN-interior-nodes. In this case the probe packet, and > > > >>>> > > > >> thus also the > > > >> > > > >>>> requiesting flow can be rejected. > > > >>>> > > > >>>> If an egress operates, for a certain ingress-egress-agrregate > in > > > >>>> admission control state and it receives a probe packet > > > >>>> > > > >> which belongs > > > >> > > > >>>> to a flow associated with the same > > > >>>> > > > >> ingress-egress-agrregate AND the > > > >> > > > >>>> probe packet is marked as not congested PCN, then the > > > egress knows > > > >>>> for sure that the probe packet HAS NOT PASSED through a > > > congested > > > >>>> PCN-interior-node due to e.g., used ECMP routing. In > > > this case the > > > >>>> probe packet can be accepted, since this flow, even it > > > >>>> > > > >> belongs to the > > > >> > > > >>>> ingress-egress-aggergate that operates in admission > > > >>>> > > > >> control, is not > > > >> > > > >>>> contributing and causing the congestion in the > PCN-interior-node. > > > >>>> > > > >>>> > > > >>>> Okay, but why one should provide the possibility to > > > PCN-interior- > > > >>>> nodes to distinguish between probe packets and other PCN > > > >>>> > > > >> aware user > > > >> > > > >>>> packets? > > > >>>> > > > >>>> This is related to which admission control and flow > termination > > > >>>> algorithms and encodings are used in the PCN-interior-nodes. > > > >>>> > > > >>>> If an algorithm uses one encoding state for admission > > > control and > > > >>>> another encoding state for flow termination then probably > > > >>>> > > > >> it is not > > > >> > > > >>>> required to provide the possibility to PC_interior-node to > > > >>>> distinguish between probe packets and PCN aware user packets. > > > >>>> This is because when the PCN-interior-node that operates > > > >>>> > > > >> in admission > > > >> > > > >>>> control state will AM (admission control encoding state) > > > >>>> > > > >> encode all > > > >> > > > >>>> packets, i.e., probe packets and user packets. > > > >>>> > > > >>>> If an algorithm uses only one encoding state for > > > admission control > > > >>>> and flow termionation, such as the ones used in the > > > single marking > > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut > > > be able to > > > >>>> distinguish between probe packets and user data packets. > > > >>>> > > > >>>> This is because both algorithms SM and LC-PCN are > > > encoding packets > > > >>>> proportionaly to the excess rate. > > > >>>> This means that when the PCN-interior-node opetrates in > > > admission > > > >>>> control state it will not SM mark all packets that > are passing > > > >>>> through the node, but only a proportion that is needed to > > > >>>> > > > >> represent > > > >> > > > >>>> the excess rate. Thus if the PCN-interior-node will not > > > >>>> > > > >> distinguish > > > >> > > > >>>> between the probe packets and other PCN aware packets, > > > >>>> > > > >> then it is not > > > >> > > > >>>> certain that the probe packet will be SM marked when the > > > >>>> PCN-interior-node operates in admission control state. > > > >>>> Now, if the probe packets carry a Router Alert option, > > > and when in > > > >>>> Admission control state, the PCN-interior-node marks all > > > >>>> > > > >> packets that > > > >> > > > >>>> are carrying a Router Alert option, then the probe packet > > > >>>> > > > >> will be for > > > >> > > > >>>> sure marked. > > > >>>> > > > >>>> Hope that this clarifies your question! > > > >>>> > > > >>>> Best regards, > > > >>>> Georgios > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > >>>>> Sent: dinsdag 26 februari 2008 18:16 > > > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > >>>>> Cc: pcn@ietf.org > > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > >>>>> > > > >>>>> Sorry, to repeat: > > > >>>>> > > > >>>>> I still have not the foggiest idea why on earth someone > > > >>>>> > > > >> would want > > > >> > > > >>>>> or need or be interested in the interior node handling > > > probe pkts > > > >>>>> differently from the way it handles probe pkts. > > > >>>>> > > > >>>>> So far you have answered a different question, about whether > it > > > >>>>> would be possible for someone to devise pcn so that an > > > >>>>> > > > >> interior node > > > >> > > > >>>>> could distinguish probe pkts from data pkts. As you > > > say, a router > > > >>>>> alert option could indeed be used. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >>>>>> Sent: 26 February 2008 17:06 > > > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > > >>>>>> Cc: pcn@ietf.org > > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > >>>>>> > > > >>>>>> Hi Phil > > > >>>>>> > > > >>>>>> * Regarding Routing NOT, > > > >>>>>> * Regarding scheduling, NOT > > > >>>>>> * Regarding PCN_marking, it could be handled differently: > > > >>>>>> > > > >>>>>> ** if excess rate marking is used AND the > PCN-interior-node > is > > > >>>>>> > > > >>>>>> > > > >>>>> congested > > > >>>>> > > > >>>>> > > > >>>>>> AND > > > >>>>>> the probe packet contains the ROUTER ALERT option THEN > > > >>>>>> the probe packet can be distinguished from the other > > > >>>>>> > > > >>>>>> > > > >>>>> PCN packets, > > > >>>>> > > > >>>>> > > > >>>>>> and therefore it will be for sure PCN_marking encoded. > > > >>>>>> > > > >>>>>> ** if excess rate marking is used AND the > PCN-interior-node > is > > > >>>>>> > > > >>>>>> > > > >>>>> congested > > > >>>>> > > > >>>>> > > > >>>>>> AND > > > >>>>>> the probe packet DOES NOT contain the ROUTER > ALERT option > > > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not > be > > > >>>>>> PCN_marking encoded. This depends > > > >>>>>> on whether this probe packet is selected to represent > > > >>>>>> > > > >>>>>> > > > >>>>> the excess > > > >>>>> > > > >>>>> > > > >>>>>> rate, or is not selected. > > > >>>>>> > > > >>>>>> Best regards, > > > >>>>>> Georgios > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 > > > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > >>>>>>> Cc: pcn@ietf.org > > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > >>>>>>> > > > >>>>>>> But why would the interior node *need* to distinguish it > > > >>>>>>> > > > >>>>>>> > > > >>>>> from other > > > >>>>> > > > >>>>> > > > >>>>>>> pcn pkts? > > > >>>>>>> > > > >>>>>>> And even if you have got router alert, the architecture > > > >>>>>>> > > > >>>>>>> > > > >>>>> draft says: > > > >>>>> > > > >>>>> > > > >>>>>>> "must be handled the same as (ordinary data) PCN-packets, > > > >>>>>>> > > > >>>>>>> > > > >>>>> in terms > > > >>>>> > > > >>>>> > > > >>>>>>> of routing, scheduling and PCN-marking." > > > >>>>>>> Even though your router alert's got it in slow path, will > > > >>>>>>> > > > >>>>>>> > > > >>>>> it handle > > > >>>>> > > > >>>>> > > > >>>>>>> it any differently in terms of routing scehdulign & > > > pcn-marking? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > >>> > > > >>> > > > >> -- > > > >> 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 > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 29 03:29:20 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AAB28C536; Fri, 29 Feb 2008 03:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 ftBP1RkpXx-J; Fri, 29 Feb 2008 03:29:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4E528C422; Fri, 29 Feb 2008 03:29:18 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6D53A6B81 for ; Fri, 29 Feb 2008 03:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YYc42A7Z3OI for ; Fri, 29 Feb 2008 03:29:11 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B18613A6F02 for ; Fri, 29 Feb 2008 03:29:10 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 11:29:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 11:29:01 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3460C@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000f01c87ab4$e361f990$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEngAALAuiAAIWGyEAAEiTTA From: To: , , X-OriginalArrivalTime: 29 Feb 2008 11:29:02.0951 (UTC) FILETIME=[4927AF70:01C87AC6] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Whoah! The Intserv or diffserv model was always(*) about the rsvp hop being edge to edge & no rsvp processing on the interior nodes. (*)ie right back to the first architecture draft way before the PCN wg. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 29 February 2008 09:24 > To: Eardley,PL,Philip,CXR9 R; acharny@cisco.com; menth@informatik.uni- > wuerzburg.de > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Hi Phil > > Regarding the below comment! > > > in terms of encoding, it does have a second encoding, but it > > uses RAO bits rather than ECN/DSCP bits. > > > > I worry a bit about security attacks (because probe pkts can now be > > identified) and about deploability barrier (will operators > > deploy something that slows all their core routers - after > > all we claimed one advantage of PCN over hop-by-hop rsvp is > > that your core routers are really simple, don't have to do > > any difficult processing... > > In the architecture draft we mention that Intserv over Diffserv is one of > the scenarios that could be > supported by PCN. In this case I assume that RSVP will be used as the > Intserv signaling protocol. > RSVP PATH carries already a Router Alert option. > The only additional functionality in the PCN-interior-nodes, is to use the > RAO bits for detection > rather than an additional ECN/DSCP code. > > Best regards, > Georgios > > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of philip.eardley@bt.com > > Sent: donderdag 28 februari 2008 19:53 > > To: acharny@cisco.com; menth@informatik.uni-wuerzburg.de > > Cc: pcn@ietf.org > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi > > > > Thanks for clarifying Georgios. interesting idea. > > > > Just to go back to the basic reason why single marking's attractive. > > [1] single marking behaviour on interior routers [2] only > > single encoding needed > > > > your idea at first sight has just one marking behaviour, ie > > excess rate marking. Indeed, it only has one token bucket. > > However, it does have extra code/complexity in order to do > > threshold marking for probe pkts, and this involves the pkt > > being processed on the slow path within a router. I guess > > this complexity is for pkt classification & PCN-encoding, > > rather than for the PCN-metering function. > > > > in terms of encoding, it does have a second encoding, but it > > uses RAO bits rather than ECN/DSCP bits. > > > > I worry a bit about security attacks (because probe pkts can now be > > identified) and about deploability barrier (will operators > > deploy something that slows all their core routers - after > > all we claimed one advantage of PCN over hop-by-hop rsvp is > > that your core routers are really simple, don't have to do > > any difficult processing... > > > > phil > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > Anna > > > Charny (acharny) > > > Sent: 28 February 2008 16:08 > > > To: menth@informatik.uni-wuerzburg.de > > > Cc: pcn > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > Hi Michael, > > > > > > Ah - that makes perfect sense. Thank you for the concise summary. > > > > > > Anna > > > > > > > -----Original Message----- > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > Sent: Thursday, February 28, 2008 10:51 AM > > > > To: Anna Charny (acharny) > > > > Cc: Lars Eggert; pcn > > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > > > Hi Anna, > > > > > > > > Anna Charny (acharny) wrote: > > > > > Hi Michael, > > > > > > > > > > You lost me on this. The discussion seems to be centered > > > > around the > > > > > complexities of appropriately forwarding and processing > > > > probe packets > > > > > in the core. What exactly does excess rate marking has to > > > > do with it? > > > > > (I do understand the point that excess rate marking needs > > > > more probes > > > > > to work reliably than threshold-vased/aka > > > > vertuall-queue-based marking > > > > > - I just do not see the connection of this point to the > > > > discussion it > > > > > seems to relate to). > > > > > > > > > > > > > Georgios proposes to do excess rate marking and to avoid multiple > > > > probes, he wants to make sure that probe packets are always > > > > AM-marked when a link is precongested with regard to the > > admissible > > > > rate. He solves this problem using the router alert option (RAO) > > > > taking packets off the fast path. This solves the problem > > you have > > > > described above (which is caused by excess rate marking), but > > > > introduces the problem of RAO. > > > > That impacts the forwarding of the packets as they need special > > > > handling by the routers. The origin of this thread was that the > > > > architecture draft said that all pcn packets should be treated in > > > > the same way by PCN nodes which is no longer the case for normal > > > > data packet and PCN packets. > > > > > > > > Regards, > > > > > > > > Michael > > > > > > > > > If I am missing your point (or the point of the discussion) > > > > - which is > > > > > quite possible as I am reading the thread backwards - I > > would much > > > > > appreciate a clarification. > > > > > > > > > > Anna > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > > On Behalf Of > > > > >> Michael Menth > > > > >> Sent: Thursday, February 28, 2008 5:50 AM > > > > >> To: Lars Eggert > > > > >> Cc: pcn > > > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > >> > > > > >> Hi Lars, > > > > >> > > > > >> I just want to point out that this complexity is not due > > > > to probing > > > > >> itself but due to the use of excess rate marking for admission > > > > >> control. > > > > >> There is no such increased complexity if probing is done in > > > > >> combination with exhaustive (threshold) marking for > > > > admission control. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Michael > > > > >> > > > > >> Lars Eggert wrote: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> I'm not sure if I have fully digested this yet, but it > > > > >>> > > > > >> seems like this > > > > >> > > > > >>> proposal defines different semantics for what the PCN > > > > marks mean to > > > > >>> both the interior and egress nodes, depending on whether a > > > > >>> > > > > >> packet is a > > > > >> > > > > >>> probe packet or not. That seems to add significant complexity. > > > > >>> > > > > >>> Lars > > > > >>> > > > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>>> Hi Phil > > > > >>>> > > > > >>>> Sorry for not being clear! > > > > >>>> > > > > >>>> As you know if ECMP routing is used then this might cause > > > > >>>> > > > > >> problems on > > > > >> > > > > >>>> the way of how admission control and flow termination > > > > >>>> > > > > >> algorithms are > > > > >> > > > > >>>> operating. > > > > >>>> > > > > >>>> The ECMP problem is related to the fact that flows can > > > > belong to a > > > > >>>> certain ingress-egress-aggregate, which is maintained at > > > > >>>> > > > > >> the ingress > > > > >> > > > > >>>> adn egress and that operates in admission control > > state or flow > > > > >>>> termination state, but that due to the ECMP routing they are > > not > > > > >>>> passing through the congested node. > > > > >>>> > > > > >>>> Any measures that are taken on such flows will not solve the > > > > >>>> congestion problem, since such flows are not contributing > > > > >>>> > > > > >> and causing > > > > >> > > > > >>>> the congestion in the PCN-interior-node. > > > > >>>> > > > > >>>> Now when probing is used this problem can be solved > > as follows. > > > > >>>> When a PCN-interior-node is congested it MUST > > > > PCN_marking encode a > > > > >>>> probe packet. > > > > >>>> > > > > >>>> > > > > >>>> Thus if an egress operates, for a certain > > > > >>>> > > > > >> ingress-egress-agrregate in > > > > >> > > > > >>>> admission control state and it receives a probe packet > > > > >>>> > > > > >> which belongs > > > > >> > > > > >>>> to a flow associated with the same > > > > >>>> > > > > >> ingress-egress-agrregate AND the > > > > >> > > > > >>>> probe packet is PCN_marking encoded, then the egress knows > > > > >>>> > > > > >> for sure > > > > >> > > > > >>>> that the probe packet passed through one or more congested > > > > >>>> PCN-interior-nodes. In this case the probe packet, and > > > > >>>> > > > > >> thus also the > > > > >> > > > > >>>> requiesting flow can be rejected. > > > > >>>> > > > > >>>> If an egress operates, for a certain ingress-egress-agrregate > > in > > > > >>>> admission control state and it receives a probe packet > > > > >>>> > > > > >> which belongs > > > > >> > > > > >>>> to a flow associated with the same > > > > >>>> > > > > >> ingress-egress-agrregate AND the > > > > >> > > > > >>>> probe packet is marked as not congested PCN, then the > > > > egress knows > > > > >>>> for sure that the probe packet HAS NOT PASSED through a > > > > congested > > > > >>>> PCN-interior-node due to e.g., used ECMP routing. In > > > > this case the > > > > >>>> probe packet can be accepted, since this flow, even it > > > > >>>> > > > > >> belongs to the > > > > >> > > > > >>>> ingress-egress-aggergate that operates in admission > > > > >>>> > > > > >> control, is not > > > > >> > > > > >>>> contributing and causing the congestion in the > > PCN-interior-node. > > > > >>>> > > > > >>>> > > > > >>>> Okay, but why one should provide the possibility to > > > > PCN-interior- > > > > >>>> nodes to distinguish between probe packets and other PCN > > > > >>>> > > > > >> aware user > > > > >> > > > > >>>> packets? > > > > >>>> > > > > >>>> This is related to which admission control and flow > > termination > > > > >>>> algorithms and encodings are used in the PCN-interior-nodes. > > > > >>>> > > > > >>>> If an algorithm uses one encoding state for admission > > > > control and > > > > >>>> another encoding state for flow termination then probably > > > > >>>> > > > > >> it is not > > > > >> > > > > >>>> required to provide the possibility to PC_interior-node to > > > > >>>> distinguish between probe packets and PCN aware user packets. > > > > >>>> This is because when the PCN-interior-node that operates > > > > >>>> > > > > >> in admission > > > > >> > > > > >>>> control state will AM (admission control encoding state) > > > > >>>> > > > > >> encode all > > > > >> > > > > >>>> packets, i.e., probe packets and user packets. > > > > >>>> > > > > >>>> If an algorithm uses only one encoding state for > > > > admission control > > > > >>>> and flow termionation, such as the ones used in the > > > > single marking > > > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut > > > > be able to > > > > >>>> distinguish between probe packets and user data packets. > > > > >>>> > > > > >>>> This is because both algorithms SM and LC-PCN are > > > > encoding packets > > > > >>>> proportionaly to the excess rate. > > > > >>>> This means that when the PCN-interior-node opetrates in > > > > admission > > > > >>>> control state it will not SM mark all packets that > > are passing > > > > >>>> through the node, but only a proportion that is needed to > > > > >>>> > > > > >> represent > > > > >> > > > > >>>> the excess rate. Thus if the PCN-interior-node will not > > > > >>>> > > > > >> distinguish > > > > >> > > > > >>>> between the probe packets and other PCN aware packets, > > > > >>>> > > > > >> then it is not > > > > >> > > > > >>>> certain that the probe packet will be SM marked when the > > > > >>>> PCN-interior-node operates in admission control state. > > > > >>>> Now, if the probe packets carry a Router Alert option, > > > > and when in > > > > >>>> Admission control state, the PCN-interior-node marks all > > > > >>>> > > > > >> packets that > > > > >> > > > > >>>> are carrying a Router Alert option, then the probe packet > > > > >>>> > > > > >> will be for > > > > >> > > > > >>>> sure marked. > > > > >>>> > > > > >>>> Hope that this clarifies your question! > > > > >>>> > > > > >>>> Best regards, > > > > >>>> Georgios > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > >>>>> Sent: dinsdag 26 februari 2008 18:16 > > > > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > > >>>>> Cc: pcn@ietf.org > > > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > >>>>> > > > > >>>>> Sorry, to repeat: > > > > >>>>> > > > > >>>>> I still have not the foggiest idea why on earth someone > > > > >>>>> > > > > >> would want > > > > >> > > > > >>>>> or need or be interested in the interior node handling > > > > probe pkts > > > > >>>>> differently from the way it handles probe pkts. > > > > >>>>> > > > > >>>>> So far you have answered a different question, about whether > > it > > > > >>>>> would be possible for someone to devise pcn so that an > > > > >>>>> > > > > >> interior node > > > > >> > > > > >>>>> could distinguish probe pkts from data pkts. As you > > > > say, a router > > > > >>>>> alert option could indeed be used. > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > >>>>>> Sent: 26 February 2008 17:06 > > > > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > > > >>>>>> Cc: pcn@ietf.org > > > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > >>>>>> > > > > >>>>>> Hi Phil > > > > >>>>>> > > > > >>>>>> * Regarding Routing NOT, > > > > >>>>>> * Regarding scheduling, NOT > > > > >>>>>> * Regarding PCN_marking, it could be handled differently: > > > > >>>>>> > > > > >>>>>> ** if excess rate marking is used AND the > > PCN-interior-node > > is > > > > >>>>>> > > > > >>>>>> > > > > >>>>> congested > > > > >>>>> > > > > >>>>> > > > > >>>>>> AND > > > > >>>>>> the probe packet contains the ROUTER ALERT option THEN > > > > >>>>>> the probe packet can be distinguished from the other > > > > >>>>>> > > > > >>>>>> > > > > >>>>> PCN packets, > > > > >>>>> > > > > >>>>> > > > > >>>>>> and therefore it will be for sure PCN_marking encoded. > > > > >>>>>> > > > > >>>>>> ** if excess rate marking is used AND the > > PCN-interior-node > > is > > > > >>>>>> > > > > >>>>>> > > > > >>>>> congested > > > > >>>>> > > > > >>>>> > > > > >>>>>> AND > > > > >>>>>> the probe packet DOES NOT contain the ROUTER > > ALERT option > > > > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT not > > be > > > > >>>>>> PCN_marking encoded. This depends > > > > >>>>>> on whether this probe packet is selected to represent > > > > >>>>>> > > > > >>>>>> > > > > >>>>> the excess > > > > >>>>> > > > > >>>>> > > > > >>>>>> rate, or is not selected. > > > > >>>>>> > > > > >>>>>> Best regards, > > > > >>>>>> Georgios > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 > > > > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > > >>>>>>> Cc: pcn@ietf.org > > > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > >>>>>>> > > > > >>>>>>> But why would the interior node *need* to distinguish it > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>> from other > > > > >>>>> > > > > >>>>> > > > > >>>>>>> pcn pkts? > > > > >>>>>>> > > > > >>>>>>> And even if you have got router alert, the architecture > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>> draft says: > > > > >>>>> > > > > >>>>> > > > > >>>>>>> "must be handled the same as (ordinary data) PCN-packets, > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>> in terms > > > > >>>>> > > > > >>>>> > > > > >>>>>>> of routing, scheduling and PCN-marking." > > > > >>>>>>> Even though your router alert's got it in slow path, will > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>> it handle > > > > >>>>> > > > > >>>>> > > > > >>>>>>> it any differently in terms of routing scehdulign & > > > > pcn-marking? > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>> _______________________________________________ > > > > >>>> 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 > > > > >>> > > > > >>> > > > > >> -- > > > > >> 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 > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 29 13:45:34 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DABF73A6D8E; Fri, 29 Feb 2008 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 lvyvFR4LoBRo; Fri, 29 Feb 2008 13:45:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE6E28C5A0; Fri, 29 Feb 2008 13:45:33 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D023A6E45 for ; Fri, 29 Feb 2008 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbVCUyhSEi16 for ; Fri, 29 Feb 2008 13:45:31 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A97A43A6D5A for ; Fri, 29 Feb 2008 13:45:31 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1TLjNwL008934; Fri, 29 Feb 2008 15:45:23 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 15:45:23 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 15:45:23 -0600 From: Steven Blake To: Lars Eggert In-Reply-To: References: <47C6D84D.40804@informatik.uni-wuerzburg.de> Organization: Ericsson IP Infrastructure Date: Fri, 29 Feb 2008 16:45:22 -0500 Message-Id: <1204321522.9015.17.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 29 Feb 2008 21:45:23.0380 (UTC) FILETIME=[63355740:01C87B1C] Cc: pcn Subject: Re: [PCN] draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Thu, 2008-02-28 at 18:06 +0200, Lars Eggert wrote: > Hi, > > On 2008-2-28, at 17:50, ext Michael Menth wrote: > > Georgios proposes to do excess rate marking and to avoid multiple > > probes, he wants to make sure that probe packets are always AM- > > marked when a link is precongested with regard to the admissible > > rate. He solves this problem using the router alert option (RAO) > > taking packets off the fast path. This solves the problem you have > > described above (which is caused by excess rate marking), but > > introduces the problem of RAO. That impacts the forwarding of the > > packets as they need special handling by the routers. The origin of > > this thread was that the architecture draft said that all pcn > > packets should be treated in the same way by PCN nodes which is no > > longer the case for normal data packet and PCN packets. > > one related question is whether RAO packets actually receive the same > ECMP treatment that non-RAO packets would receive, since they're being > kicked out of the fast path, where ECMP happens. > > Anyone know how routers deal with this? This is very vendor-specific. > (From what I understand from the discussions with the routing ADs on > NSIS' use of RAO, relying on RAO pretty much guarantees serious > deployment issues.) Agreed. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 29 14:20:07 2008 Return-Path: X-Original-To: ietfarch-pcn-archive@core3.amsl.com Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FAA28C7E8; Fri, 29 Feb 2008 14:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 DryYBfYEePCc; Fri, 29 Feb 2008 14:20:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858083A685C; Fri, 29 Feb 2008 14:20:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFEA28C7FD for ; Fri, 29 Feb 2008 14:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DclE109duQ14 for ; Fri, 29 Feb 2008 14:19:56 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2B9723A6804 for ; Fri, 29 Feb 2008 14:19:55 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1TMJl4m029972; Fri, 29 Feb 2008 16:19:48 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:19:47 -0600 Received: from [147.117.169.145] ([147.117.169.145]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:19:46 -0600 From: Steven Blake To: "Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1CE0ACED@S4DE8PSAANK.mitte.t-com.de> References: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> <1204126840.3044.7.camel@neutrino> <1B6169C658325341A3B8066E23919E1CE0ACED@S4DE8PSAANK.mitte.t-com.de> Organization: Ericsson IP Infrastructure Date: Fri, 29 Feb 2008 17:19:46 -0500 Message-Id: <1204323586.9015.31.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 29 Feb 2008 22:19:47.0090 (UTC) FILETIME=[31467F20:01C87B21] Cc: pcn@ietf.org Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Fri, 2008-02-29 at 09:10 +0100, Geib, Ruediger wrote: > Hi Steven, > > how many operators and vendors you know deploy or support L-LSPs? Not many, true. Deploying PCN will require at least some operational and implementation changes. I guess you are telling us that relying on more than two EXP codepoints to signal pre-congestion state (and hence having to re-engineer the way Diffserv is managed over LSPs) is a deal breaker in many networks? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn