From philip.eardley@bt.com Tue Sep 1 08:22:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44503A6FEF for ; Tue, 1 Sep 2009 08:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGzHBmfP5+Rx for ; Tue, 1 Sep 2009 08:22:05 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D44283A6B66 for ; Tue, 1 Sep 2009 08:22:04 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 16:22:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Sep 2009 16:21:54 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363792@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcoljgeTqhCuKsQQSP2KRDNTkNCC7gFbWDBw From: To: X-OriginalArrivalTime: 01 Sep 2009 15:22:11.0843 (UTC) FILETIME=[FA61B530:01CA2B17] Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:22:07 -0000 I see there has been a lot of on & off list discussion about Spencer's first comment (ie the abstract uses Diffserv domain, not PCN-domain). I wasn't able to read all the discussion because it has grown to 35 pages (!!!!)=20 I guess I disagree with Spencer's comment. my view is that the general reader is more likely to know what a Diffserv domain is, so that's a better term to use in the abstract. (if the reader wants to understand exactly what a PCN-domain is then they read further). But if insisted on, the easy solution is just to add "called a PCN-domain" after "Diffserv domain". Problem solved. I disagree with the direction that the revised abstract has been going. It seems to be trying to write a (longish) paragraph summary of what PCN is. I think that is not needed & in fact is quite a bad idea - it's a job for the introduction. I think the abstract should just say what the Baseline encoding is about. However, I think it's probably ok to start with one sentence about the objective of PCN, or a reference to rfc5559. However, I think it might be worth adding to the abstract to explain why this is called the "baseline" encoding, ie there are other encodings building on this one that differentiate two severity levels of PCN-marking. In fact, allowing (/ constraining) encoding extensions is an important part of the baseline doc. My suggested abstract is {..optional text..}:- The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain {called a PCN-domain}. Within the {PCN-}domain, PCN-nodes mark PCN-packets if the rate of PCN-traffic is too high {as defined in [ref marking behaviour]}. This document defines how such marks are encoded in the IP header for a 'baseline' encoding that provides for two PCN encoding states (not-marked and PCN-marked). It reuses the ECN codepoint. Other encodings can build on this baseline encoding to provide more than two encoding states, in order to distinguish two severity levels of PCN-marking.=20 Toby, I'll leave it to you to decide what you want to do with my comments, as I think there's been plenty enough suggestions already. Best wishes, phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars { Eggert { Sent: 25 August 2009 15:12 { To: pcn@ietf.org { Subject: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline- { encoding-05 {=20 {=20 {=20 { Begin forwarded message: {=20 { > From: Spencer Dawkins { > Date: August 25, 2009 14:47:49 GMT+02:00 { > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > { > Cc: General Area Review Team , "ietf@ietf.org { > " { > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- { > encoding-05 { > { > I have been selected as the General Area Review Team (Gen-ART) { > reviewer for { > this draft (for background on Gen-ART, please see { > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). { > { > Please wait for direction from your document shepherd or AD before { > posting a { > new version of the draft. { > { > Document: draft-ietf-pcn-baseline-encoding-05 { > Reviewer: Spencer Dawkins { > IETF LC End Date: 2009-09-03 { > Review Date: 2009-08-21 { > IESG Telechat date: (not known) { > { > Summary: this specification is almost ready for publication as a { > Proposed { > Standard. I have one minor question below (flagged as "Spencer { > (minor)"), { > along with some editorial suggestions to be considered when this { > document is { > edited (either in the working group or by the RFC Editor). { > { > Abstract { > { > The objective of Pre-Congestion Notification (PCN) is to protect the { > quality of service (QoS) of inelastic flows within a Diffserv { > domain. { > { > Spencer (clarity): I'm not sure what the relationship between a { > Diffserv { > domain and a PCN-domain is - this couuld be clearer, especially in an { > Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its { > Abstract ... I can guess, but I'm just guessing. { > { > The overall rate of the PCN-traffic is metered on every link in the { > PCN-domain, and PCN-packets are appropriately marked when certain { > configured rates are exceeded. The level of marking allows the { > boundary nodes to make decisions about whether to admit or block a { > new flow request, and (in abnormal circumstances) whether to { > terminate some of the existing flows, thereby protecting the QoS of { > previously admitted flows. This document specifies how such marks { > are to be encoded into the IP header by re-using the Explicit { > Congestion Notification (ECN) codepoints within this controlled { > domain. The baseline encoding described here provides for only two { > PCN encoding states, Not-marked and PCN-marked. { > { > 4. Encoding two PCN States in IP { > { > The following rules apply to all PCN traffic: { > { > o PCN-traffic MUST be marked with a PCN-compatible Diffserv { > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be { > chosen that are already defined for use with admission controlled { > traffic. Appendix A.1 gives guidance to implementiors on { > suitable { > { > Spencer (clarity): s/implementiors/implementers/? { > { > DSCPs. Guidelines for mixing traffic-types within a PCN-domain { > are given in [I-D.ietf-pcn-marking-behaviour]. { > { > o Any packet that is not-PCN but which shares the same Diffserv { > codepoint as PCN-enabled traffic MUST have the ECN field of its { > outermost IP header equal to 00. { > { > Spencer (minor): this is the only point in the specification (that I { > can { > find) that makes reference to the "outermost IP header". I'm not sure { > whether to suggest s/outermost// here or to ask that a statement be { > added { > earlier in the document to clearly state that PCN encoding only { > protects { > inelastic traffic when it's used for the outermost IP header, but the { > current text seems to call attention to this in a way that makes the { > reader { > wonder what is special about THIS requirement that isn't true of the { > other { > requirements listed. { > { > 4.3. PCN-Compatible Diffserv Codepoints { > { > Enabling PCN marking behaviour for a specific DSCP disables any { > other { > marking behaviour (e.g. enabling PCN disables the default ECN { > marking { > behaviour introduced in [RFC3168]). All traffic metering and { > marking { > { > Spencer (clarity): here, and in Section 6, the text uses "disables" to { > describe the relationship between PCN and ECN. If I understand the { > point, { > the domain is substituting one behavior for another. I might suggest { > "replaces" to describe the relationship in both locations. { > { > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. This { > ensures compliance with the BCP guidance set out in [RFC4774]. { > { > 4.3.1. Co-existence of PCN and not-PCN traffic { > { > The scarcity of pool 1 DSCPs coupled with the fact that PCN is { > envisaged as a marking behaviour that could be applied to a number { > of { > different DSCPs makes it essential that we provide a not-PCN state. { > As stated above (and expanded in Appendix A.1) the aim is for PCN to { > re-use existing DSCPs. Because PCN re-defines the meaning of the { > ECN { > { > Spencer (clarity): here, the text uses "re-defines", which I like { > better { > than "disables", but if you go for "replaces" previously and in { > section 6, { > you might want to use the same wording here. { > { > field for such DSCPs it is important to allow an operator to still { > use the DSCP for traffic that isn't PCN-enabled. This is achieved { > by { > providing a not-PCN state within the encoding scheme. { > { > A.1. Choice of Suitable DSCPs { > { > The PCN Working Group chose not to define a single DSCP for use with { > PCN for several reasons. Firstly the PCN mechanism is applicable to { > a variety of different traffic classes. Secondly standards track { > DSCPs are in increasingly short supply. Thirdly PCN should be seen { > as being essentially a marking behaviour similar to ECN but intended { > for inelastic traffic. The choice of which DSCP is most suitable { > for { > a given PCN-domain is dependent on the nature of the traffic { > entering { > that domain and the link rates of all the links making up that { > domain. In PCN-domains with uniformly high link rates, the { > appropriate DSCPs would currently be those for the Real Time Traffic { > Class [RFC5127]. To be clear the PCN Working Group recommends using { > { > Spencer (clarity): is this 2119 language (apparently not, since this { > section { > is not normative), or are you saying "suggests"? My suggestion is { > that we { > not use 2119 language, even lowercased, except for normative text - { > this { > seems to cause confusion from time to time. But please check with your { > shepherding AD to see if he agrees. { > { > admission control for the following service classes: { > { > o Telephony (EF) { > { > o Real-time interactive (CS4) { > { > o Broadcast Video (CS3) { > { > o Multimedia Conferencing (AF4) { > { > _______________________________________________ { > Gen-art mailing list { > Gen-art@ietf.org { > https://www.ietf.org/mailman/listinfo/gen-art From wwwrun@core3.amsl.com Wed Sep 2 07:36:57 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 36BB928C79E; Wed, 2 Sep 2009 07:36:57 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090902143657.36BB928C79E@core3.amsl.com> Date: Wed, 2 Sep 2009 07:36:57 -0700 (PDT) Cc: pcn mailing list , pcn chair , Internet Architecture Board , RFC Editor Subject: [PCN] Protocol Action: 'Metering and marking behaviour of PCN-nodes' to Proposed Standard X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 14:36:57 -0000 The IESG has approved the following document: - 'Metering and marking behaviour of PCN-nodes ' as a Proposed Standard This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-05.txt Technical Summary This document specifies two packet metering and marking behaviours of PCN nodes. These metering and marking behaviours are implemented in PCN interior nodes to signal the onset of pre-congestion to PCN boundary nodes. Threshold-metering and -marking marks all PCN-packets if the PCN traffic rate is greater than a configured rate ("PCN-threshold-rate"). Excess-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the traffic rate in excess of a configured rate ("PCN-excess-rate"). The level of PCN marking allows PCN boundary nodes to determine the extent of pre-congestion on ingress-egress paths, which is used to make PCN traffic admission or termination decisions. Working Group Summary The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. Personnel The document shepherd was Steven Blake (slblake@petri-meat.com). Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From toby.moncaster@bt.com Fri Sep 4 04:16:25 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD72C3A67E2 for ; Fri, 4 Sep 2009 04:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3myxo1U6r676 for ; Fri, 4 Sep 2009 04:16:23 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 66F5F3A67FE for ; Fri, 4 Sep 2009 04:16:23 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 12:14:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Sep 2009 12:14:51 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363792@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Reviewofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcoljgeTqhCuKsQQSP2KRDNTkNCC7gFbWDBwAJUlg1A= References: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <4A916DBC72536E419A0BD955EDECEDEC06363792@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 04 Sep 2009 11:14:54.0368 (UTC) FILETIME=[EDCBF200:01CA2D50] Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Reviewofdraft-ietf-pcn-baseline-encoding-05 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 11:16:25 -0000 As the IETF LC has now finished with no further comments, I am in the process of completing the revised draft for the IESG to approve. I have decided that Phil has a sound point about the abstract - what we had ended up with last week was effectively a complete introduction to the PCN architecture as a whole. I have now crafted a final abstract for people to see if they approve. I will actually submit the revised version by 1600 GMT this afternoon so if people disagree they need to shout quickly! Before I give the abstract, a few words to explain where it is coming from. I think the abstract for the baseline encoding needs to do the following: introduce readers to PCN - by which I mean give them a hint as to what field this is in, NOT describe PCN in detail...; Then introduce PCN marking; then finally explain that this is the baseline encoding for that marking... The pre-congestion notification (PCN) architecture is intended to=20 protect the QoS of inelastic flows within a DiffServ domain. In order to do this, packets belonging to PCN-flows are marked when the rate of traffic exceeds pre-configured thresholds on a link. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into=20 the IP header by redefining the Explicit Congestion Notification=20 (ECN) codepoints within such domains. The baseline encoding=20 described here provides only two PCN encoding states: not-marked=20 and PCN-marked. Future extensions to this encoding may be needed to provide more than one level of marking severity. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 01 September 2009 16:22 > To: pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Reviewofdraft-ietf-pcn- > baseline-encoding-05 >=20 > I see there has been a lot of on & off list discussion about Spencer's > first comment (ie the abstract uses Diffserv domain, not PCN-domain). I > wasn't able to read all the discussion because it has grown to 35 pages > (!!!!) >=20 > I guess I disagree with Spencer's comment. my view is that the general > reader is more likely to know what a Diffserv domain is, so that's a > better term to use in the abstract. (if the reader wants to understand > exactly what a PCN-domain is then they read further). But if insisted > on, the easy solution is just to add "called a PCN-domain" after > "Diffserv domain". Problem solved. >=20 > I disagree with the direction that the revised abstract has been going. > It seems to be trying to write a (longish) paragraph summary of what > PCN > is. I think that is not needed & in fact is quite a bad idea - it's a > job for the introduction. I think the abstract should just say what the > Baseline encoding is about. However, I think it's probably ok to start > with one sentence about the objective of PCN, or a reference to > rfc5559. >=20 > However, I think it might be worth adding to the abstract to explain > why > this is called the "baseline" encoding, ie there are other encodings > building on this one that differentiate two severity levels of > PCN-marking. In fact, allowing (/ constraining) encoding extensions is > an important part of the baseline doc. >=20 > My suggested abstract is {..optional text..}:- >=20 > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain > {called a PCN-domain}. > Within the {PCN-}domain, PCN-nodes mark PCN-packets if the rate of > PCN-traffic is too high {as defined in [ref marking behaviour]}. This > document defines how such marks are encoded in the IP header for a > 'baseline' encoding that provides for two PCN encoding states > (not-marked and PCN-marked). It reuses the ECN codepoint. Other > encodings can build on this baseline encoding to provide more than two > encoding states, in order to distinguish two severity levels of > PCN-marking. >=20 > Toby, I'll leave it to you to decide what you want to do with my > comments, as I think there's been plenty enough suggestions already. >=20 > Best wishes, > phil >=20 >=20 > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Lars > { Eggert > { Sent: 25 August 2009 15:12 > { To: pcn@ietf.org > { Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > ofdraft-ietf-pcn-baseline- > { encoding-05 > { > { > { > { Begin forwarded message: > { > { > From: Spencer Dawkins > { > Date: August 25, 2009 14:47:49 GMT+02:00 > { > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > { pcn-baseline-encoding@tools.ietf.org > { > > > { > Cc: General Area Review Team , > "ietf@ietf.org > { > " > { > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > { > encoding-05 > { > > { > I have been selected as the General Area Review Team (Gen-ART) > { > reviewer for > { > this draft (for background on Gen-ART, please see > { > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > { > > { > Please wait for direction from your document shepherd or AD before > { > posting a > { > new version of the draft. > { > > { > Document: draft-ietf-pcn-baseline-encoding-05 > { > Reviewer: Spencer Dawkins > { > IETF LC End Date: 2009-09-03 > { > Review Date: 2009-08-21 > { > IESG Telechat date: (not known) > { > > { > Summary: this specification is almost ready for publication as a > { > Proposed > { > Standard. I have one minor question below (flagged as "Spencer > { > (minor)"), > { > along with some editorial suggestions to be considered when this > { > document is > { > edited (either in the working group or by the RFC Editor). > { > > { > Abstract > { > > { > The objective of Pre-Congestion Notification (PCN) is to protect > the > { > quality of service (QoS) of inelastic flows within a Diffserv > { > domain. > { > > { > Spencer (clarity): I'm not sure what the relationship between a > { > Diffserv > { > domain and a PCN-domain is - this couuld be clearer, especially in > an > { > Abstract. I note that RFC 5559 doesn't use the term PCN-domain in > its > { > Abstract ... I can guess, but I'm just guessing. > { > > { > The overall rate of the PCN-traffic is metered on every link in > the > { > PCN-domain, and PCN-packets are appropriately marked when certain > { > configured rates are exceeded. The level of marking allows the > { > boundary nodes to make decisions about whether to admit or block > a > { > new flow request, and (in abnormal circumstances) whether to > { > terminate some of the existing flows, thereby protecting the QoS > of > { > previously admitted flows. This document specifies how such > marks > { > are to be encoded into the IP header by re-using the Explicit > { > Congestion Notification (ECN) codepoints within this controlled > { > domain. The baseline encoding described here provides for only > two > { > PCN encoding states, Not-marked and PCN-marked. > { > > { > 4. Encoding two PCN States in IP > { > > { > The following rules apply to all PCN traffic: > { > > { > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > { > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > { > chosen that are already defined for use with admission > controlled > { > traffic. Appendix A.1 gives guidance to implementiors on > { > suitable > { > > { > Spencer (clarity): s/implementiors/implementers/? > { > > { > DSCPs. Guidelines for mixing traffic-types within a PCN- > domain > { > are given in [I-D.ietf-pcn-marking-behaviour]. > { > > { > o Any packet that is not-PCN but which shares the same Diffserv > { > codepoint as PCN-enabled traffic MUST have the ECN field of > its > { > outermost IP header equal to 00. > { > > { > Spencer (minor): this is the only point in the specification (that > I > { > can > { > find) that makes reference to the "outermost IP header". I'm not > sure > { > whether to suggest s/outermost// here or to ask that a statement be > { > added > { > earlier in the document to clearly state that PCN encoding only > { > protects > { > inelastic traffic when it's used for the outermost IP header, but > the > { > current text seems to call attention to this in a way that makes > the > { > reader > { > wonder what is special about THIS requirement that isn't true of > the > { > other > { > requirements listed. > { > > { > 4.3. PCN-Compatible Diffserv Codepoints > { > > { > Enabling PCN marking behaviour for a specific DSCP disables any > { > other > { > marking behaviour (e.g. enabling PCN disables the default ECN > { > marking > { > behaviour introduced in [RFC3168]). All traffic metering and > { > marking > { > > { > Spencer (clarity): here, and in Section 6, the text uses "disables" > to > { > describe the relationship between PCN and ECN. If I understand the > { > point, > { > the domain is substituting one behavior for another. I might > suggest > { > "replaces" to describe the relationship in both locations. > { > > { > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > This > { > ensures compliance with the BCP guidance set out in [RFC4774]. > { > > { > 4.3.1. Co-existence of PCN and not-PCN traffic > { > > { > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > { > envisaged as a marking behaviour that could be applied to a > number > { > of > { > different DSCPs makes it essential that we provide a not-PCN > state. > { > As stated above (and expanded in Appendix A.1) the aim is for PCN > to > { > re-use existing DSCPs. Because PCN re-defines the meaning of the > { > ECN > { > > { > Spencer (clarity): here, the text uses "re-defines", which I like > { > better > { > than "disables", but if you go for "replaces" previously and in > { > section 6, > { > you might want to use the same wording here. > { > > { > field for such DSCPs it is important to allow an operator to > still > { > use the DSCP for traffic that isn't PCN-enabled. This is > achieved > { > by > { > providing a not-PCN state within the encoding scheme. > { > > { > A.1. Choice of Suitable DSCPs > { > > { > The PCN Working Group chose not to define a single DSCP for use > with > { > PCN for several reasons. Firstly the PCN mechanism is applicable > to > { > a variety of different traffic classes. Secondly standards track > { > DSCPs are in increasingly short supply. Thirdly PCN should be > seen > { > as being essentially a marking behaviour similar to ECN but > intended > { > for inelastic traffic. The choice of which DSCP is most suitable > { > for > { > a given PCN-domain is dependent on the nature of the traffic > { > entering > { > that domain and the link rates of all the links making up that > { > domain. In PCN-domains with uniformly high link rates, the > { > appropriate DSCPs would currently be those for the Real Time > Traffic > { > Class [RFC5127]. To be clear the PCN Working Group recommends > using > { > > { > Spencer (clarity): is this 2119 language (apparently not, since > this > { > section > { > is not normative), or are you saying "suggests"? My suggestion is > { > that we > { > not use 2119 language, even lowercased, except for normative text - > { > this > { > seems to cause confusion from time to time. But please check with > your > { > shepherding AD to see if he agrees. > { > > { > admission control for the following service classes: > { > > { > o Telephony (EF) > { > > { > o Real-time interactive (CS4) > { > > { > o Broadcast Video (CS3) > { > > { > o Multimedia Conferencing (AF4) > { > > { > _______________________________________________ > { > Gen-art mailing list > { > Gen-art@ietf.org > { > https://www.ietf.org/mailman/listinfo/gen-art >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Fri Sep 4 07:06:10 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E08F3A67EB for ; Fri, 4 Sep 2009 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pWjIV4mkSe5 for ; Fri, 4 Sep 2009 07:06:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 2629C3A679F for ; Fri, 4 Sep 2009 07:06:07 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 14:11:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Sep 2009 14:11:14 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ARTReviewofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcoljgeTqhCuKsQQSP2KRDNTkNCC7gFbWDBwAJUlg1AABA+UIA== References: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com><4A916DBC72536E419A0BD955EDECEDEC06363792@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 04 Sep 2009 13:11:17.0234 (UTC) FILETIME=[2FE8BD20:01CA2D61] Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReviewofdraft-ietf-pcn-baseline-encoding-05 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:06:10 -0000 Replying to my own email. On reading back what I wrote I actually think it would sound better as: The objective of the pre-congestion notification (PCN) architecture=20 is to protect the QoS of inelastic flows within a DiffServ domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the=20 domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion=20 Notification (ECN) codepoints within such domains. The baseline=20 encoding described here provides only two PCN encoding states:=20 not-marked and PCN-marked. Future extensions to this encoding may be=20 needed in order to provide more than one level of marking severity. As I said below this does 3 things: introduces the PCN architecture (if someone has found this document they probably already know about that), it explains what PCN-marks are and how they are generated and then it explains how to encode these into the IP header. The final bit was as suggested by Phil - we need to give a hint as to why this is a baseline encoding... Unless I get really strong pushback against this then I will run with it when I release the update in the next couple of hours... > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > toby.moncaster@bt.com > Sent: 04 September 2009 12:15 > To: Eardley,PL,Philip,DER3 R; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReviewofdraft-ietf-pcn- > baseline-encoding-05 >=20 > As the IETF LC has now finished with no further comments, I am in the > process of completing the revised draft for the IESG to approve. >=20 > I have decided that Phil has a sound point about the abstract - what we > had ended up with last week was effectively a complete introduction to > the PCN architecture as a whole. I have now crafted a final abstract > for > people to see if they approve. I will actually submit the revised > version by 1600 GMT this afternoon so if people disagree they need to > shout quickly! >=20 > Before I give the abstract, a few words to explain where it is coming > from. I think the abstract for the baseline encoding needs to do the > following: introduce readers to PCN - by which I mean give them a hint > as to what field this is in, NOT describe PCN in detail...; Then > introduce PCN marking; then finally explain that this is the baseline > encoding for that marking... >=20 > The pre-congestion notification (PCN) architecture is intended to > protect the QoS of inelastic flows within a DiffServ domain. In > order > to do this, packets belonging to PCN-flows are marked when the rate > of traffic exceeds pre-configured thresholds on a link. These marks > can then be evaluated to determine how close the domain is to being > congested. This document specifies how such marks are encoded into > the IP header by redefining the Explicit Congestion Notification > (ECN) codepoints within such domains. The baseline encoding > described here provides only two PCN encoding states: not-marked > and PCN-marked. Future extensions to this encoding may be needed to > provide more than one level of marking severity. >=20 > Toby >=20 > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > philip.eardley@bt.com > > Sent: 01 September 2009 16:22 > > To: pcn@ietf.org > > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Reviewofdraft-ietf-pcn- > > baseline-encoding-05 > > > > I see there has been a lot of on & off list discussion about > Spencer's > > first comment (ie the abstract uses Diffserv domain, not PCN-domain). > I > > wasn't able to read all the discussion because it has grown to 35 > pages > > (!!!!) > > > > I guess I disagree with Spencer's comment. my view is that the > general > > reader is more likely to know what a Diffserv domain is, so that's a > > better term to use in the abstract. (if the reader wants to > understand > > exactly what a PCN-domain is then they read further). But if insisted > > on, the easy solution is just to add "called a PCN-domain" after > > "Diffserv domain". Problem solved. > > > > I disagree with the direction that the revised abstract has been > going. > > It seems to be trying to write a (longish) paragraph summary of what > > PCN > > is. I think that is not needed & in fact is quite a bad idea - it's a > > job for the introduction. I think the abstract should just say what > the > > Baseline encoding is about. However, I think it's probably ok to > start > > with one sentence about the objective of PCN, or a reference to > > rfc5559. > > > > However, I think it might be worth adding to the abstract to explain > > why > > this is called the "baseline" encoding, ie there are other encodings > > building on this one that differentiate two severity levels of > > PCN-marking. In fact, allowing (/ constraining) encoding extensions > is > > an important part of the baseline doc. > > > > My suggested abstract is {..optional text..}:- > > > > The objective of Pre-Congestion Notification (PCN) is to protect > the > > quality of service (QoS) of inelastic flows within a Diffserv > domain > > {called a PCN-domain}. > > Within the {PCN-}domain, PCN-nodes mark PCN-packets if the rate of > > PCN-traffic is too high {as defined in [ref marking behaviour]}. This > > document defines how such marks are encoded in the IP header for a > > 'baseline' encoding that provides for two PCN encoding states > > (not-marked and PCN-marked). It reuses the ECN codepoint. Other > > encodings can build on this baseline encoding to provide more than > two > > encoding states, in order to distinguish two severity levels of > > PCN-marking. > > > > Toby, I'll leave it to you to decide what you want to do with my > > comments, as I think there's been plenty enough suggestions already. > > > > Best wishes, > > phil > > > > > > { -----Original Message----- > > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > > Lars > > { Eggert > > { Sent: 25 August 2009 15:12 > > { To: pcn@ietf.org > > { Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > > ofdraft-ietf-pcn-baseline- > > { encoding-05 > > { > > { > > { > > { Begin forwarded message: > > { > > { > From: Spencer Dawkins > > { > Date: August 25, 2009 14:47:49 GMT+02:00 > > { > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > > { pcn-baseline-encoding@tools.ietf.org > > { > > > > { > Cc: General Area Review Team , > > "ietf@ietf.org > > { > " > > { > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > > { > encoding-05 > > { > > > { > I have been selected as the General Area Review Team (Gen-ART) > > { > reviewer for > > { > this draft (for background on Gen-ART, please see > > { > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > { > > > { > Please wait for direction from your document shepherd or AD > before > > { > posting a > > { > new version of the draft. > > { > > > { > Document: draft-ietf-pcn-baseline-encoding-05 > > { > Reviewer: Spencer Dawkins > > { > IETF LC End Date: 2009-09-03 > > { > Review Date: 2009-08-21 > > { > IESG Telechat date: (not known) > > { > > > { > Summary: this specification is almost ready for publication as a > > { > Proposed > > { > Standard. I have one minor question below (flagged as "Spencer > > { > (minor)"), > > { > along with some editorial suggestions to be considered when this > > { > document is > > { > edited (either in the working group or by the RFC Editor). > > { > > > { > Abstract > > { > > > { > The objective of Pre-Congestion Notification (PCN) is to > protect > > the > > { > quality of service (QoS) of inelastic flows within a Diffserv > > { > domain. > > { > > > { > Spencer (clarity): I'm not sure what the relationship between a > > { > Diffserv > > { > domain and a PCN-domain is - this couuld be clearer, especially > in > > an > > { > Abstract. I note that RFC 5559 doesn't use the term PCN-domain in > > its > > { > Abstract ... I can guess, but I'm just guessing. > > { > > > { > The overall rate of the PCN-traffic is metered on every link in > > the > > { > PCN-domain, and PCN-packets are appropriately marked when > certain > > { > configured rates are exceeded. The level of marking allows the > > { > boundary nodes to make decisions about whether to admit or > block > > a > > { > new flow request, and (in abnormal circumstances) whether to > > { > terminate some of the existing flows, thereby protecting the > QoS > > of > > { > previously admitted flows. This document specifies how such > > marks > > { > are to be encoded into the IP header by re-using the Explicit > > { > Congestion Notification (ECN) codepoints within this controlled > > { > domain. The baseline encoding described here provides for only > > two > > { > PCN encoding states, Not-marked and PCN-marked. > > { > > > { > 4. Encoding two PCN States in IP > > { > > > { > The following rules apply to all PCN traffic: > > { > > > { > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > > { > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > > { > chosen that are already defined for use with admission > > controlled > > { > traffic. Appendix A.1 gives guidance to implementiors on > > { > suitable > > { > > > { > Spencer (clarity): s/implementiors/implementers/? > > { > > > { > DSCPs. Guidelines for mixing traffic-types within a PCN- > > domain > > { > are given in [I-D.ietf-pcn-marking-behaviour]. > > { > > > { > o Any packet that is not-PCN but which shares the same > Diffserv > > { > codepoint as PCN-enabled traffic MUST have the ECN field of > > its > > { > outermost IP header equal to 00. > > { > > > { > Spencer (minor): this is the only point in the specification > (that > > I > > { > can > > { > find) that makes reference to the "outermost IP header". I'm not > > sure > > { > whether to suggest s/outermost// here or to ask that a statement > be > > { > added > > { > earlier in the document to clearly state that PCN encoding only > > { > protects > > { > inelastic traffic when it's used for the outermost IP header, but > > the > > { > current text seems to call attention to this in a way that makes > > the > > { > reader > > { > wonder what is special about THIS requirement that isn't true of > > the > > { > other > > { > requirements listed. > > { > > > { > 4.3. PCN-Compatible Diffserv Codepoints > > { > > > { > Enabling PCN marking behaviour for a specific DSCP disables any > > { > other > > { > marking behaviour (e.g. enabling PCN disables the default ECN > > { > marking > > { > behaviour introduced in [RFC3168]). All traffic metering and > > { > marking > > { > > > { > Spencer (clarity): here, and in Section 6, the text uses > "disables" > > to > > { > describe the relationship between PCN and ECN. If I understand > the > > { > point, > > { > the domain is substituting one behavior for another. I might > > suggest > > { > "replaces" to describe the relationship in both locations. > > { > > > { > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > > This > > { > ensures compliance with the BCP guidance set out in [RFC4774]. > > { > > > { > 4.3.1. Co-existence of PCN and not-PCN traffic > > { > > > { > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > > { > envisaged as a marking behaviour that could be applied to a > > number > > { > of > > { > different DSCPs makes it essential that we provide a not-PCN > > state. > > { > As stated above (and expanded in Appendix A.1) the aim is for > PCN > > to > > { > re-use existing DSCPs. Because PCN re-defines the meaning of > the > > { > ECN > > { > > > { > Spencer (clarity): here, the text uses "re-defines", which I like > > { > better > > { > than "disables", but if you go for "replaces" previously and in > > { > section 6, > > { > you might want to use the same wording here. > > { > > > { > field for such DSCPs it is important to allow an operator to > > still > > { > use the DSCP for traffic that isn't PCN-enabled. This is > > achieved > > { > by > > { > providing a not-PCN state within the encoding scheme. > > { > > > { > A.1. Choice of Suitable DSCPs > > { > > > { > The PCN Working Group chose not to define a single DSCP for use > > with > > { > PCN for several reasons. Firstly the PCN mechanism is > applicable > > to > > { > a variety of different traffic classes. Secondly standards > track > > { > DSCPs are in increasingly short supply. Thirdly PCN should be > > seen > > { > as being essentially a marking behaviour similar to ECN but > > intended > > { > for inelastic traffic. The choice of which DSCP is most > suitable > > { > for > > { > a given PCN-domain is dependent on the nature of the traffic > > { > entering > > { > that domain and the link rates of all the links making up that > > { > domain. In PCN-domains with uniformly high link rates, the > > { > appropriate DSCPs would currently be those for the Real Time > > Traffic > > { > Class [RFC5127]. To be clear the PCN Working Group recommends > > using > > { > > > { > Spencer (clarity): is this 2119 language (apparently not, since > > this > > { > section > > { > is not normative), or are you saying "suggests"? My suggestion is > > { > that we > > { > not use 2119 language, even lowercased, except for normative text > - > > { > this > > { > seems to cause confusion from time to time. But please check with > > your > > { > shepherding AD to see if he agrees. > > { > > > { > admission control for the following service classes: > > { > > > { > o Telephony (EF) > > { > > > { > o Real-time interactive (CS4) > > { > > > { > o Broadcast Video (CS3) > > { > > > { > o Multimedia Conferencing (AF4) > > { > > > { > _______________________________________________ > > { > Gen-art mailing list > > { > Gen-art@ietf.org > > { > https://www.ietf.org/mailman/listinfo/gen-art > > > > _______________________________________________ > > 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 root@core3.amsl.com Fri Sep 4 12:30:02 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 26B223A687F; Fri, 4 Sep 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090904193002.26B223A687F@core3.amsl.com> Date: Fri, 4 Sep 2009 12:30:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 19:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Baseline Encoding and Transport of Pre-Congestion Information Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-baseline-encoding-06.txt Pages : 17 Date : 2009-09-04 The objective of the pre-congestion notification (PCN) architecture is to protect the QoS of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: not- marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-baseline-encoding-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-04122421.I-D@ietf.org> --NextPart-- From slblake@petri-meat.com Tue Sep 8 11:45:24 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B0628C2F6 for ; Tue, 8 Sep 2009 11:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KieVmMHukJAQ for ; Tue, 8 Sep 2009 11:45:23 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 92BC328C178 for ; Tue, 8 Sep 2009 11:45:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ml5hH-0004Dj-Uq for pcn@ietf.org; Tue, 08 Sep 2009 14:45:43 -0400 MIME-Version: 1.0 Date: Tue, 08 Sep 2009 14:45:43 -0400 From: To: pcn@ietf.org Message-ID: <1bf1cccd3a6a959e8f02d2fcc1ac14ee@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] WG chair affiliation X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:45:24 -0000 For the record: I am affiliated with my employer, Extreme Networks (the synthetic meat-thing is just a hobby). We make Ethernet switches and other related stuff. I do not believe my employer has ever influenced any decision I have taken as working group co-chair. Regards, // Steve From root@core3.amsl.com Fri Sep 25 06:15:02 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B2AA28C12A; Fri, 25 Sep 2009 06:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090925131502.0B2AA28C12A@core3.amsl.com> Date: Fri, 25 Sep 2009 06:15:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 13:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Baseline Encoding and Transport of Pre-Congestion Information Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-baseline-encoding-07.txt Pages : 18 Date : 2009-09-25 The objective of the pre-congestion notification (PCN) architecture is to protect the QoS of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: not- marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-baseline-encoding-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-25060009.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed Sep 30 09:28:51 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 70DBA3A69B5; Wed, 30 Sep 2009 09:28:51 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090930162851.70DBA3A69B5@core3.amsl.com> Date: Wed, 30 Sep 2009 09:28:51 -0700 (PDT) Cc: pcn mailing list , pcn chair , Internet Architecture Board , RFC Editor Subject: [PCN] Protocol Action: 'Baseline Encoding and Transport of Pre-Congestion Information' to Proposed Standard X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:28:51 -0000 The IESG has approved the following document: - 'Baseline Encoding and Transport of Pre-Congestion Information ' as a Proposed Standard This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-07.txt Technical Summary This document specifies a baseline encoding for pre-congestion notification states in a PCN domain. The baseline encoding assumes that the ECN bits in the IP header can be used to encode two PCN states ("Not-marked", "PCN-marked") for packets belonging to certain Diffserv behavior aggregates. The PCN-compatible Diffserv codepoints are not specified, and are assumed to be configurable on a domain basis. It is assumed that normal ECN behavior is not available for packets within these behavior aggregates; however, the encoding allows packets in these behavior aggregates to be marked as "Not-PCN". The proposed alternative semantics of the ECN bits is consistent with the rules specified in RFC 4774. Working Group Summary The proposed encoding is the product of substantial discussion within group. Personnel The document shepherd was Steven Blake (sblake@extremenetworks.com). Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG.