Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05
Tom Taylor <tom.taylor@rogers.com> Thu, 27 August 2009 16:28 UTC
Return-Path: <tom.taylor@rogers.com>
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 161E228C22C for <pcn@core3.amsl.com>; Thu, 27 Aug 2009 09:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, 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 NnDiTPvXZGqu for <pcn@core3.amsl.com>; Thu, 27 Aug 2009 09:28:32 -0700 (PDT)
Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by core3.amsl.com (Postfix) with SMTP id 817CB28C21D for <pcn@ietf.org>; Thu, 27 Aug 2009 09:27:49 -0700 (PDT)
Received: (qmail 28437 invoked from network); 27 Aug 2009 16:27:53 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=6gOdNn7fb6uiqv4hw0Wrv6olQ6S4zsRS+heYchrpyFPbJ6SWZvyEk2xDXUcJu0+fRHDDJzO+/vB1GGQAFBe1heMOqvveKZum8KYynEzsKhXM+tatDVCVMOsIYMuf8eYUQeSsXUUWMQxbx4+0OVfNnNryhx0eI5l2yiKK17sUQVc= ;
Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 27 Aug 2009 16:27:53 -0000
X-YMail-OSG: olW3GpMVM1n8UBgO0zozNOjMC5o_A8CLDkZE4p_ahum1vPe0R9OKv39k2SnC2kEc.Q--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A96B406.7080002@rogers.com>
Date: Thu, 27 Aug 2009 12:27:50 -0400
From: Tom Taylor <tom.taylor@rogers.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: menth@informatik.uni-wuerzburg.de
References: <20090826161528.6CDD41C000A8@mwinf5908> <AEDCAF87EEC94F49BA92EBDD49854CC70CC81DC2@E03MVZ1-UKDY.domain1.systemhost.net> <4A965BE0.3050708@informatik.uni-wuerzburg.de>
In-Reply-To: <4A965BE0.3050708@informatik.uni-wuerzburg.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: bob@homefarmparham.co.uk, pcn@ietf.org
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 <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2009 16:28:35 -0000
I like the text you and Ruediger provided. I'll use it for the edge behaviour drafts. Michael Menth wrote: > Hi Toby, > > the abstract still misses my point. > 1) PCN is the metering and marking scheme > 2) QoS is protected by AC and FT (not by marking packets!) > > PCN protects QoS only indirectly. Your abstracts are formulated in a way > that this does not become very clear vor the casual reader. My two > sentences to Rüdiger in my last email were based on Bob's proposal and > fix that shortcoming. > > Regards, > > Michael > > toby.moncaster@bt.com schrieb: >> OK, my last 2 suggested versions. PLEASE can we just make a decision now! >> >> Version 1 (13 lines): >> >> Pre-Congestion Notification (PCN) is a scheme for packet metering >> and marking that can be used within a Diffserv domain to protect >> the quality of service (QoS) of inelastic flows. It does this by >> measuring pre-congestion information at the boundaries of the domain. >> This information is used to determine whether to admit new flows or >> (in abnormal circumstances) terminate some existing flows, thereby >> protecting the QoS of previously admitted flows. The pre-congestion >> information is provided by marking packets when the overall rate of >> PCN traffic on a link exceeds certain configured rates. This document >> specifies how such marks are 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. >> >> >> Version 2 (11 lines): >> >> Pre-Congestion Notification (PCN) is a scheme for packet metering and >> marking that can help protect the quality of service (QoS) of >> inelastic flows within a Diffserv domain. Within the domain nodes >> measure the rate of PCN traffic on each link and mark packets if that >> rate exceeds a configured threshold. This pre-congestion information >> is measured at the boundaries of the domain and is then used to >> determine whether to admit new flows or (in extremis) terminate some >> existing flows. This protects the QoS of previously admitted flows. >> This document specifies how such marks are 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. >> >> Toby >> >> >>> -----Original Message----- >>> From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] >>> Sent: 26 August 2009 17:15 >>> To: Moncaster,T,Toby,DER3 R >>> Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>> baseline-encoding-05 >>> >>> Toby, >>> >>> inline, following up my own post... >>> >>> >>>> Date: Wed, 26 Aug 2009 16:50:15 +0100 >>>> To: menth@informatik.uni-wuerzburg.de, Ruediger.Geib@telekom.de >>>> From: Bob Briscoe <bob@homefarmparham.co.uk> >>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART >>>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>>> Cc: toby.moncaster@bt.com, pcn@ietf.org >>>> >>>> Michael, >>>> >>>> I agree that we should use the term PCN to mean >>>> the notification part, not the whole traffic >>>> control system built around it. We had this >>>> discussion when publishing the architecture. >>>> >>>> * CORRECT: what Phil did in the Intro to the architecture. >>>> " >>>> The objective of Pre-Congestion Notification (PCN) is to protect the >>>> quality of service (QoS) of inelastic flows within a Diffserv >>>> >>> domain >>> >>>> in a simple, scalable, and robust fashion. >>>> >>>> " >>>> (paraphrasing: the *objective* of notification is to protect QoS) >>>> >>>> * INCORRECT: The first sentence of Toby's abstract says: >>>> "Pre-Congestion Notification (PCN) is a metering and marking scheme >>>> >>> that >>> >>>> protects the quality of service (QoS) of >>>> inelastic flows within a Diffserv >>>> domain." >>>> (paraphrasing: notification *is* a scheme that protects QoS) >>>> >>>> Suggestion to fix the first >>>> sentence:"Pre-Congestion Notification (PCN) is a >>>> scheme for metering and marking packets that >>>> can be used to protect the quality of service >>>> (QoS) of inelastic flows within a Diffserv domain." >>>> >>> Just realised that's ambiguous: "scheme that can >>> be used" or "packets that can be used"? >>> >>> 2nd attempt: >>> "Pre-Congestion Notification (PCN) is a scheme >>> for packet metering and marking that can be used >>> to protect the quality of service (QoS) of >>> inelastic flows within a Diffserv domain." >>> >>> >>> >>> >>> >>>> Bob >>>> >>>> At 16:12 26/08/2009, Michael Menth wrote: >>>> >>>>> Hi Ruediger, Toby, >>>>> >>>>> Ruediger.Geib@telekom.de schrieb: >>>>> >>>>>> Toby, >>>>>> >>>>>> you simply ommited some "PCN" in your new >>>>>> version. I think the problem addressed by >>>>>> Spencer may be that you try to sum up RFC5559 rather then refer to >>>>>> >>> it. >>> >>>>>> Below there's an abstract proposal, structured top-down: >>>>>> - What's PCN: a copy of the abstract of RFC5559. >>>>>> - What's the functionality relevant for this document: marking >>>>>> - What's specified by this document: baseline encoding >>>>>> My try: >>>>>> >>>>>> PCN specifies 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. >>>>>> >>>>> What is PCN? Or is admission control and flow >>>>> termination also part of PCN? My take on this >>>>> is that PCN is only the marking scheme and the >>>>> way the information is carried to egress nodes. >>>>> AC and FT is just built on top of PCN. And to >>>>> support QoS is the objective of AC and FT, not >>>>> primarily or only indirectly the objective of the marking scheme. >>>>> >>>>> Regards, >>>>> >>>>> Michael >>>>> >>>>> >>>>>> As a part of this specification, the overall >>>>>> rate of the PCN coloured traffic is metered on >>>>>> every link in the domain, and these packets >>>>>> are appropriately marked when certain configured rates are exceeded. >>>>>> This document specifies how such marks are >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> Please maintain the notion of "overall rate of >>>>>> PCN traffic" or "PCN coloured traffic" which >>>>>> is being metered in the version of abstract you go on with. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ruediger >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: toby.moncaster@bt.com >>>>>> [mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 >>>>>> >>> PM >>> >>>>>> To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger >>>>>> Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>>>>> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART >>>>>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>>>>> >>>>>> So would the following sound better? : >>>>>> >>>>>> Pre-Congestion Notification (PCN) is a >>>>>> metering and marking scheme that protects >>>>>> the quality of service (QoS) of inelastic >>>>>> flows within a Diffserv domain. The >>>>>> overall rate of the traffic is metered on >>>>>> every link in the domain, and packets are appropriately marked >>>>>> >>> when certain >>> >>>>>> configured rates are exceeded. Boundary nodes can measure the >>>>>> >>> level >>> >>>>>> of marking and thus 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 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. >>>>>> >>>>>> Just for clarity here was the earlier version I proposed: >>>>>> >>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>> >>> the >>> >>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>> >>> domain. >>> >>>>>> The overall rate of the traffic is metered on every link in the >>>>>> domain, and packets are appropriately marked when certain >>>>>> configured rates are exceeded. Boundary nodes can measure the >>>>>> >>> level >>> >>>>>> of marking and thus 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 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. >>>>>> >>>>>> I personally disagree with Tom's suggestion to >>>>>> add PCN to all the defined terms (e.g. PCN >>>>>> flow, PCN traffic) - that is fine within the >>>>>> body of the document but in this abstract we >>>>>> should avoid using any terms that readers >>>>>> won't be already familiar with. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>>>> Sent: 26 August 2009 08:46 >>>>>>> To: Ruediger.Geib@telekom.de >>>>>>> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>>> baseline-encoding-05 >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Rüdiger touches an issue that I also feel is not optimally solved >>>>>>> >>> in >>> >>>>>>> the >>>>>>> current abstract. The objective of PCN is provide marking >>>>>>> >>> information >>> >>>>>>> to >>>>>>> egress node and the objective of admission control and flow >>>>>>> >>> termination >>> >>>>>>> is to protect QoS. I use the following short explanation for PCN. >>>>>>> >>> Maybe >>> >>>>>>> this idea could be added to the current abstract. >>>>>>> >>>>>>> Pre-congestion notification (PCN) is a metering and marking scheme >>>>>>> >>> for >>> >>>>>>> Differentiated Services (DiffServ) IP networks which provides >>>>>>> >>> egress >>> >>>>>>> nodes with information about load conditions inside the network >>>>>>> \cite{RFC5559}. This information is used for admission control and >>>>>>> >>> flow >>> >>>>>>> termination to support quality of service (QoS) for admitted >>>>>>> >>> inelastic >>> >>>>>>> realtime flows that are carried with prioritization within the >>>>>>> >>> DiffServ >>> >>>>>>> domain. >>>>>>> This document specifies how nodes encode the marking information in >>>>>>> >>> the >>> >>>>>>> IP header by re-using the Explicit Congestion Notification (ECN) >>>>>>> codepoints within a controlled DiffServ domain. The baseline >>>>>>> >>> encoding >>> >>>>>>> described here provides for only two PCN encoding states which are >>>>>>> not-marked and PCN-marked. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> Ruediger.Geib@telekom.de schrieb: >>>>>>> >>>>>>> >>>>>>>> Toby, Bob >>>>>>>> >>>>>>>> if the abstract is to mention PCN functionalities not defined >>>>>>>> >>> within >>> >>>>>>>> this document in a rather simplified way, would the purpose of PCN >>>>>>>> be to enable a Diffserv domain to support measurement based >>>>>>>> admission control as defined by PCN architecture? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ruediger >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>>>> >>> Of >>> >>>>>>> Bob Briscoe >>>>>>> >>>>>>> >>>>>>>> Sent: Tuesday, August 25, 2009 8:42 PM >>>>>>>> To: toby.moncaster@bt.com; pcn@ietf.org >>>>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>>>> >>>>>>>> >>>>>>> baseline-encoding-05 >>>>>>> >>>>>>> >>>>>>>> Toby, >>>>>>>> >>>>>>>> I think this isn't just good for a casual reader, but it is >>>>>>>> >>> actually >>> >>>>>>>> still correct and doesn't require defining PC-domain (which is >>>>>>>> >>> just >>> >>>>>>>> the Diffserv domain once the described measures - the PDB - have >>>>>>>> >>> been >>> >>>>>>>> put in place). >>>>>>>> >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> This potentially raises an issue for all future PCN documents >>>>>>>>> >>> since >>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>> abstract was based on our agreed standard elevator-pitch >>>>>>>>> >>>>>>>>> >>>>>>> introduction to >>>>>>> >>>>>>> >>>>>>>>> PCN... Specifically Spencer raises the question of using the >>>>>>>>> >>> defined >>> >>>>>>>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>>>>>>> >>>>>>>>> >>>>>>> whether >>>>>>> >>>>>>> >>>>>>>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>>>>>>> >>>>>>>>> >>>>>>> drop >>>>>>> >>>>>>> >>>>>>>>> the "PCN-"). In which case should I alter the whole abstract as >>>>>>>>> >>>>>>>>> >>>>>>> follows >>>>>>> >>>>>>> >>>>>>>>> (note: I realise this is strictly incorrect as it now doesn't >>>>>>>>> >>> seek >>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>>> distinguish the non-PCN and PCN traffic from each other but is >>>>>>>>> >>> this >>> >>>>>>>>> clearer for a casual reader?): >>>>>>>>> >>>>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>>>> >>> protect >>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>>> >>>>>>>>> >>>>>>> domain. >>>>>>> >>>>>>> >>>>>>>>> The overall rate of the traffic is metered on every link in >>>>>>>>> >>> the >>> >>>>>>>>> domain, and packets are appropriately marked when certain >>>>>>>>> configured rates are exceeded. Boundary nodes can measure >>>>>>>>> >>> the >>> >>>>>>> level >>>>>>> >>>>>>> >>>>>>>>> of marking and thus 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 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. >>>>>>>>> >>>>>>>>> Toby >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----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 <spencer@wonderhamster.org> >>>>>>>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> <draft-ietf- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> pcn-baseline-encoding@tools.ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cc: General Area Review Team <gen-art@ietf.org>, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> "ietf@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> " <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 >>>>>>>> _______________________________________________ >>>>>>>> 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/31-86644 (new), 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/31-86644 (new), fax: (+49)-931/888-6632 >>>>> mailto:menth@informatik.uni-wuerzburg.de >>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn >>>>> >
- Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-i… Michael Menth
- Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-i… toby.moncaster
- Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-i… Tom Taylor