From toby.moncaster@bt.com Tue May 5 02:39:27 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 955DD3A6855 for ; Tue, 5 May 2009 02:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ2sW3gIUPK9 for ; Tue, 5 May 2009 02:39:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id ACE373A6CB5 for ; Tue, 5 May 2009 02:39:25 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 10:40:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:40:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-ietf-pcn-baseline-encoding-02 thread-index: AcmvCLoZ4aVXEXQZTJeFvFuwwyOV6AeVTgQN References: <49CD18E5.80508@erg.abdn.ac.uk> From: To: X-OriginalArrivalTime: 05 May 2009 09:40:46.0128 (UTC) FILETIME=[90C96B00:01C9CD65] Cc: pcn@ietf.org Subject: Re: [PCN] Some comments on draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Tue, 05 May 2009 09:39:27 -0000 Hi Gorry, =20 here is your list of comments with my annotations of how I addressed = them in version 03 (the current version which is in WGLC). My comments = marked {TM}... =20 Toby ________________________________ From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Fri 27/03/2009 18:20 To: pcn@ietf.org Cc: Briscoe,RJ,Bob,CXR9 R; Moncaster,T,Toby,CXR9 R; = menth@informatik.uni-wuerzburg.de; Gorry Subject: Some comments on draft-ietf-pcn-baseline-encoding-02 Here are some comments on pcn baseline encoding, the document seems in good shape, but there are probably a few things I would update to help others to read this document. Gorry General comments: - It would be really nice to see the explanation. {TM} this coment really applies to lots of the drafts. We have now = concocted a new Intro paragraph (elevator pitch) to set the scene + I = re-wrote the abstract (see later) - I had problems reading this to understand what was the implication on packet forwarding - the key thing that I thought was missing, I later found in 4.2. Have the authors thought about placing this section ahead of the others and then explicitly calling out with a [very short] subsection on what to do if there were a DSCP conflict and how the original traffic could be mapped to not-PCN and the where to find details on how to traffic ECN-enabled traffic on this DSCP (i.e. = tunnel?). {TM}I still need to write a sub-section to address this, but am not sure = where it should fit in the structure. Probably within 4.3 or as a new = subsection 4.3.1. I can then refer to it in the intro... - I found Table 2 hard to understand, then discovered there were some encodings missing. {TM} Completely replaced with text sections for ingress and egress + a = new table for the interior nodes. Let me know if this is any clearer = (not sure how else to clarify it as there are so many posisble = transitions) - I think the security considerations could be improved. {TM} Did my best but they are still not ideal. Any suggestions on = additions gratefully received! - To me, Appendix A.2 seems reasonable. ---------------------- Specific comments: Abstract - English seems to me to need a little polishing. s/in order// ? - Please mention ECN code points in the abstract. - Later you say a sentence such as: The PCN encoding states are defined using a combination of the DSCP and ECN fields within the IP header. The baseline PCN encoding closely follows the semantics of ECN [RFC3168]. {TM} re-wrote abstract completely. Let me know if you think it is better = or not Abstract " below the physical link rate." - This seems very odd to me, I thought this was about the link capacity. {TM} I think its about link rate but this is more to do with the = architecture and marking behaviour. The new intro which has been agreed = by most people uses rate not capacity... Abstract "states but such schemes will be described in other documents." ^ - insert comma, or better still separate this into two sentences (to me it seems an odd way for a PS abstract to finish). S1 Makes no mention of ECN fields, which would be nice for people wanting to look for documents that show the meaning of the ECN-field. {TM} It now mentions ECN S1 "Other extensions have also been suggested all of which can build on the baseline encoding." - Seems very bold. is the WG sure that *ALL* can build on this? {TM} removed claim and replaced with "can be easily extended" plus = pointed out the guidelines later in doc (but no xref) S1 "MUST extend this baseline scheme" - How? - The draft places a normative requirement, but doesn't say what is intended. Is this by updating this specification? By obsoleting this spec? using some common part of the same framework? - I don't see what is being required. {TM} removed this S3, bullet 2 o PCN-marked - codepoint indicating packets that have been marked = at a PCN-interior-node using some PCN marking behaviour [pcn-marking-behaviour]. Also PM. ^^^^^^^ - is this an alternative or a definition of the term PN? {TM} its the official abbreviation. I've clarified all these definitions S3: o Not-marked - codepoint indicating packets that are PCN-capable = but ^ - comma? S3: are not PCN-marked. Also NM. ^^^^^^^ - is this an alternative or, as I think, a definition of the term NM? S3: By definition packets carrying such codepoints are PCN-packets. ^ - comma? S3: o PCN-compatible Diffserv codepoint - a Diffserv codepoint for = which the ECN field is used to carry PCN markings rather than [RFC3168] markings. - Could this definition be placed as bullet one or bullet two? {TM} re-ordered all the definitions... S3: In addition the document uses the terminology defined in [pcn-arch]. ^ - comma? S4: allows for traffic that is not PCN capable to be marked as such = (Not- PCN). - I'd like to see this more clearly called out. The reader of this spec may be trying to figure out how these codepoints are used with PCN and how to transport the traditional use of ECN or where the DSCP is already used for non PCN traffic. The structure of the document did not really help me in this case at all (although the framework seems to be addressing this case). A very short section that simply sets out the = NON-PCN {TM} This probably still needs to be addressed. If I add a section as = asked for above on DSCPs this would naturally sit there. But not sure = where best to insert the section? S4 to prevent any possible future compatability issues. - remove /any/ - or are sure? {TM} I was fairly sure but I removed it anyway S4 o Any packet that is not PCN-enabled (Not-PCN) but which shares the ^ S4 Table 2 is not easily understood. In fact, I got pretty confused, then discovered there were some encodings missing. I'd really like to see all the encodings or a different table format. {TM} see comment above S4 packet MUST be treated as if it were NM. ^^^^^^ - as if it carried the NM marking? {TM} yep S4 End 4.0 has a truncated sentence {TM} Ooops! Don't know what happened there. Over-enthusiastic use of = delete key 4.1 says: If the packet is being tunneled then only the 11 codepoint gets copied into the inner header upon decapsulation. - This language seems odd to me. {TM} rephrased this to hopefully make it clearer - and people will have = to read Bob's ECN tunnel draft (which is much clearer in its new form) = to find out more An additional constraint is the need to minimise the use of DiffServ codepoints as ^^ -English? - because? {TM} sorry, missed this one... S4.1 The encoding scheme above seems to meet all these constraints and - is this WG consensus, or author's? {TM} I think its more or less WG consensus by now... It took a lot of = arguing to get to this scheme and many dead ends... S4.2 Enabling PCN for a DSCP switches on PCN marking behaviour for = packets ^^^^^^^^^^^^^ - Better phrase here? {TM} I've tried to improve the phrasing S4.2 but only if those packets also have their ECN field set to indicate a codepoint other than Not-PCN. - presumably this refers to PCN router behaviour within a PCN domain? {TM} Yes. Probably I should add this is only relevant within the = PCN-domain S4.2 Enabling PCN marking behaviour disables any other marking behaviour - OK, but I think this should be clearer that this is for only for a specific DSCP. {TM} missed this one S5 o The 00 codepoint in the ECN field MUST mean Not-PCN. - not sure /mean/ is the correct word, should it be /indicate/ (and following points) - and should this also say and /MUST NOT be changed to any other codepoint within a PCN domain/? {TM} Yes - and now does say this. Also corrected to indicate S5 o Once set the 11 codepoint in the ECN field MUST NOT be changed to ^ - insert comma - /doesn't/ change to /does not/ S5 o Any experimental scheme MUST include details of all valid and invalid codepoint transitions at any PCN nodes. - OK, you could say it MUST NOT update 00 or 11 (or is this now = implicit?) {TM} added. Hopefully everyone agrees with this... S8 Packets claim entitlement to be PCN marked by carrying a PCN- - English? I think the document should say that that a PCN domain has been pre-configured with domain edges, and that this document describes behaviour within the domain. {TM} I re-wrote section 8. Can you look and see if you htink I addressed = most of these comments? S8 However there is a requirement to keep inter-domain scenarios in mind when defining the PCN encoding. - I found this rather vague, or more precisely too vague for me to understand the implications. S8 Then any one domain's security against its neighbours would be described as part of the proposed edge-node behaviour document. - I could not understand what the security implication was and what was being requested of people who followed this document with new proposals. {TM} On re-reading I found this unhelpful so I removed and changed it S9 It also allows for the co- existence of competing traffic within the same DSCP so long as that traffic doesn't require end-to-end ECN support. s/doesn't/does not/ - This sounds categorical that this is not possible, but presumably tunnels may be used. Is theer better language that could be chosen? {TM} I missed this one. I shoudl probably clarify that ECN can be = tunneled but that it is effectively disabled within the PCN-domain. S11 - Should be removed by RFC-Ed? {TM} yes S12: Refs. - Are there no normative architecture specifications to define what PCN is? - Seems odd for a PS, could this be [pcn-arch]. {TM} indeed it does seem odd but that is what the charter states. I = think it is sort of trying to follow the lead of DiffServ where the = architecture is an informational document. I have tried to refer to = marking behaviour more often as that is standards track S12: Refs. - Why is RFC3168 also not normative? A.1 domain includes lower speed links ^^^^^^^^^^^^^^^^^^ - Is this really the issue??? Or does this describe a PCN network link with a link with low flow aggregation as an example of the case where other appropriate use is needed. If this is not the case, we should quantify what is meant by "lower speed" and be much more clear about the guidance here. Either way, I find this confusing. {TM} I have left this as is. Can others comment on whether they find = this confusing also? It might almost be easier just to remove this = section altogether - A.1, suggests there is no fixed DSCP for PCN, this seems a pity from the point of view of a router knowing whether PCN is to be invoked, it therefore becomes yet one more thing that could be misconfigured. I presume this decision has been extensively discussed within the PCN WG, so this probably does not need action? {TM} This follows advice from the ADs concerning how slow it is to get a = standards track DSCP assigned. I believe the hope is that PCN will be = rolled out by 1 or 2 operators and found to be successful. We can then = come back and try for a complete set of DSCPs. Also this baseline = encoding is a slight red herring as it is really just an enabler for = experiments to see which alternative encoding is most sensible (and to = see if encodings offering more codepoints are actually necessary). = Current simulation results suggest schemes with a single marked state = are less good than those with 2 marked states A.2 o Leakage of traffic into PCN-domain: ECT(1) is less often correct. - This does not make seem to make sense. {TM} can't remember why we worked that out but it seemed to make sense = at the time... However I have tried to re-phrase this o Leakage of traffic out of PCN-domainL Either ECT is equally = unsafe ^ - Character? /./ A.2 o Incremental deployment: Either ECT is suitable as long as they = are ^ ^^^^^^^^^^^^^^^^ - Please insert /codepoint/ and s/as long as/, providing that the codepoints are/ Editorial question should it be "PCN capable" or "PCN-capable"? From gorry@erg.abdn.ac.uk Tue May 5 09:49: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 C8B923A7125 for ; Tue, 5 May 2009 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KXrAVPsecOM for ; Tue, 5 May 2009 09:49:05 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 7BDC63A715D for ; Tue, 5 May 2009 09:49:03 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n45GnY2e017212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 17:49:34 +0100 (BST) Message-ID: <4A006E1E.60001@erg.abdn.ac.uk> Date: Tue, 05 May 2009 18:49:34 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <49CD18E5.80508@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Tue, 05 May 2009 10:25:30 -0700 Cc: pcn@ietf.org Subject: Re: [PCN] Some comments on draft-ietf-pcn-baseline-encoding-02 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:49:06 -0000 Greetings Toby! Thanks, I was pleased to see many of the comments had been addressed. There are some comments that you may like to consider further as you process any other LC comments (marked **). I hope this helps, this document seems quite mature and looks nearly finished. Best wishes, Gorry toby.moncaster@bt.com wrote: > Hi Gorry, > > here is your list of comments with my annotations of how I addressed them in version 03 (the current version which is in WGLC). My comments marked {TM}... > > Toby > > ________________________________ > > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Fri 27/03/2009 18:20 > To: pcn@ietf.org > Cc: Briscoe,RJ,Bob,CXR9 R; Moncaster,T,Toby,CXR9 R; menth@informatik.uni-wuerzburg.de; Gorry > Subject: Some comments on draft-ietf-pcn-baseline-encoding-02 > > > > Here are some comments on pcn baseline encoding, the document seems in > good shape, but there are probably a few things I would update to help > others to read this document. > > Gorry > > > General comments: > > - It would be really nice to see the explanation. > > {TM} this comment really applies to lots of the drafts. > We have now concocted a new Intro paragraph (elevator pitch) > to set the scene + I re-wrote the abstract (see later) > True. I found the new abstract is much clearer, if i had read this and the new introduction I do not think that I would have made that comment. > - I had problems reading this to understand what was the implication on > packet forwarding - the key thing that I thought was missing, I later > found in 4.2. Have the authors thought about placing this section ahead > of the others and then explicitly calling out with a [very short] > subsection on what to do if there were a DSCP conflict and how the > original traffic could be mapped to not-PCN and the where to find > details on how to traffic ECN-enabled traffic on this DSCP (i.e. tunnel?). > > {TM}I still need to write a sub-section to address this, but am not > sure where it should fit in the structure. Probably within 4.3 or as a > new subsection 4.3.1. I can then refer to it in the intro... > > > - I found Table 2 hard to understand, then discovered there were some > encodings missing. > > {TM} Completely replaced with text sections for ingress and egress > + a new table for the interior nodes. > Let me know if this is any clearer (not sure how else to clarify > it as there are so many posisble transitions) > Looks good. > - I think the security considerations could be improved. > > {TM} Did my best but they are still not ideal. > Any suggestions on additions gratefully received! > > - To me, Appendix A.2 seems reasonable. > ** This point seems weak: "o Leakage of traffic into PCN-domain: ECT(1) is slightly less likely" I think you should be stronger e.g.: "Overall this seemed to suggest ECT(0) was most appropriate to use." - e.g. On the basis of the above considerations, ECT(0) was selected for use. > > ---------------------- > Specific comments: > > Abstract > - English seems to me to need a little polishing. > s/in order// ? > - Please mention ECN code points in the abstract. > - Later you say a sentence such as: > The PCN encoding states are defined using a combination of the DSCP > and ECN fields within the IP header. The baseline PCN encoding > closely follows the semantics of ECN [RFC3168]. > > {TM} re-wrote abstract completely. Let me know if you think it is better or not > > Abstract > " below the physical link rate." - This seems very odd to me, I thought > this was about the link capacity. > > {TM} I think its about link rate but this is more to do with the architecture > and marking behaviour. The new intro which has been agreed by most > people > uses rate not capacity... > > Abstract > "states but such schemes will be described in other documents." > ^ > - insert comma, or better still separate this into two sentences (to me > it seems an odd way for a PS abstract to finish). > The rewrite looks good to me. > S1 > Makes no mention of ECN fields, which would be nice for people wanting > to look for documents that show the meaning of the ECN-field. > > {TM} It now mentions ECN ** Good, although a NIT is it would be nice to see the term "ECN" defined (expanded) the first time it appears in the introduction. > > S1 > "Other extensions have also been suggested all of which can build on the > baseline encoding." > - Seems very bold. is the WG sure that *ALL* can build on this? > > {TM} removed claim and replaced with "can be easily extended" plus > pointed out the guidelines later in doc (but no xref) > ** NiT: I misread /states and rules/ when I first read this, perhaps you could put some punctuation in here? e.g. /However, the encoding can be easily extended to provide more states. Rules for such extensions are given in this document./ > S1 > "MUST extend this baseline scheme" > - How? - The draft places a normative requirement, but doesn't say what > is intended. Is this by updating this specification? By obsoleting this > spec? using some common part of the same framework? - I don't see what > is being required. > > {TM} removed this > OK - that avoids this issue. > S3, bullet 2 > o PCN-marked - codepoint indicating packets that have been marked at > a PCN-interior-node using some PCN marking behaviour > [pcn-marking-behaviour]. Also PM. > ^^^^^^^ > - is this an alternative or a definition of the term PN? > > {TM} its the official abbreviation. I've clarified all these definitions > > S3: > o Not-marked - codepoint indicating packets that are PCN-capable but > ^ > - comma? > S3: > are not PCN-marked. Also NM. > ^^^^^^^ > - is this an alternative or, as I think, a definition of the term NM? > > > S3: > By definition packets carrying such codepoints are PCN-packets. > ^ > - comma? > > S3: > o PCN-compatible Diffserv codepoint - a Diffserv codepoint for which > the ECN field is used to carry PCN markings rather than [RFC3168] > markings. > - Could this definition be placed as bullet one or bullet two? > > {TM} re-ordered all the definitions... > Fine now. > S3: > In addition the document uses the terminology defined in [pcn-arch]. > ^ > - comma? > > S4: > allows for traffic that is not PCN capable to be marked as such (Not- > PCN). > - I'd like to see this more clearly called out. The reader of this spec > may be trying to figure out how these codepoints are used with PCN and > how to transport the traditional use of ECN or where the DSCP is already > used for non PCN traffic. The structure of the document did not really > help me in this case at all (although the framework seems to be > addressing this case). A very short section that simply sets out the NON-PCN > > {TM} This probably still needs to be addressed. If I add a section as > asked for above on DSCPs this would naturally sit there. But not sure where > best to insert the section? > ** This question still seems to need an answer. > > S4 > to prevent any possible future compatability issues. > - remove /any/ - or are sure? > > {TM} I was fairly sure but I removed it anyway > done. > > S4 > o Any packet that is not PCN-enabled (Not-PCN) but which shares the > ^ > > S4 > Table 2 is not easily understood. In fact, I got pretty confused, then > discovered there were some encodings missing. I'd really like to see all > the encodings or a different table format. > > {TM} see comment above > > S4 > packet MUST be treated as if it were NM. > ^^^^^^ > - as if it carried the NM marking? > > {TM} yep > > S4 > End 4.0 has a truncated sentence > > {TM} Ooops! Don't know what happened there. Over-enthusiastic use of delete key > > > 4.1 says: > If the packet is being tunneled then only the 11 codepoint gets copied > into the inner header upon decapsulation. > > - This language seems odd to me. > > {TM} rephrased this to hopefully make it clearer > - and people will have to read Bob's ECN tunnel draft (which is much > clearer in its new form) to find out more > > > An additional constraint is the need to minimise > the use of DiffServ codepoints as > ^^ > -English? - because? > > {TM} sorry, missed this one... > ** Please fix > S4.1 > The encoding scheme above seems to meet all these constraints and > - is this WG consensus, or author's? ** Seems fine, then I'd be happier making this decision and saying "This was judged by the PCN WG to ..." > > {TM} I think its more or less WG consensus by now... > It took a lot of arguing to get to this scheme and many dead ends... > > S4.2 > Enabling PCN for a DSCP switches on PCN marking behaviour for packets > ^^^^^^^^^^^^^ > - Better phrase here? > > {TM} I've tried to improve the phrasing > OK > S4.2 > but only if those packets also have their ECN field > set to indicate a codepoint other than Not-PCN. > - presumably this refers to PCN router behaviour within a PCN domain? > > {TM} Yes. Probably I should add this is only relevant within the PCN-domain > ** I think your proposed change would be an improvement. > S4.2 > Enabling PCN marking behaviour disables any other marking behaviour > - OK, but I think this should be clearer that this is for only for a > specific DSCP. > > {TM} missed this one > ** I think this should be changed. > S5 > o The 00 codepoint in the ECN field MUST mean Not-PCN. > - not sure /mean/ is the correct word, should it be /indicate/ (and > following points) > - and should this also say and /MUST NOT be changed to any other > codepoint within a PCN domain/? > > {TM} Yes - and now does say this. Also corrected to indicate > OK > S5 > o Once set the 11 codepoint in the ECN field MUST NOT be changed to > ^ > - insert comma > - /doesn't/ change to /does not/ > > S5 > o Any experimental scheme MUST include details of all valid and > invalid codepoint transitions at any PCN nodes. > - OK, you could say it MUST NOT update 00 or 11 (or is this now implicit?) > > {TM} added. Hopefully everyone agrees with this... > > S8 > Packets claim entitlement to be PCN marked by carrying a PCN- > - English? I think the document should say that that a PCN domain has > been pre-configured with domain edges, and that this document describes > behaviour within the domain. > > {TM} I re-wrote section 8. Can you look and see if you think I addressed > most of these comments? > Better > S8 > However there is a > requirement to keep inter-domain scenarios in mind when defining the > PCN encoding. > - I found this rather vague, or more precisely too vague for me to > understand the implications. > Fixed. > S8 > Then any one domain's security against its neighbours would > be described as part of the proposed edge-node behaviour document. > - I could not understand what the security implication was and what was > being requested of people who followed this document with new proposals. > > {TM} On re-reading I found this unhelpful so I removed and changed it > OK > S9 > It also allows for the co- > existence of competing traffic within the same DSCP so long as that > traffic doesn't require end-to-end ECN support. > s/doesn't/does not/ > - This sounds categorical that this is not possible, but presumably > tunnels may be used. Is there better language that could be chosen? > > {TM} I missed this one. I should probably clarify that ECN can be > tunneled but that it is effectively disabled within the PCN-domain. > ** Not sure I understand what you propose that the new text would say. I think that ECN markings may be tunneled across an ECN domain, by encapsulating an IP packet with a tunnel header. How would the outer header of the tunnel be treated if the tunnel egress endpoint was outside the PCN domain? ** Section 8 also describes behaviour when IPsec is used to tunnel PCN marked packets. > S11 > - Should be removed by RFC-Ed? > {TM} yes > Done. > S12: Refs. > - Are there no normative architecture specifications to define what PCN > is? - Seems odd for a PS, could this be [pcn-arch]. > > {TM} indeed it does seem odd but that is what the charter states. > I think it is sort of trying to follow the lead of DiffServ where the > architecture is an informational document. I have tried to refer to > marking behaviour more often as that is standards track. > Seems to be addressed. > S12: Refs. > - Why is RFC3168 also not normative? > done. > > A.1 > domain includes lower speed links > ^^^^^^^^^^^^^^^^^^ > - Is this really the issue??? Or does this describe a PCN network link > with a link with low flow aggregation as an example of the case where > other appropriate use is needed. If this is not the case, we should > quantify what is meant by "lower speed" and be much more clear about the > guidance here. Either way, I find this confusing. > > {TM} I have left this as is. Can others comment on whether they find > this confusing also? It might almost be easier just to remove this > section altogether> > The new text seems better. ** The terms "higher" and "lower" are comparative terms, and am I right that here it relates to the ratio between the rates of the admitted flows and the link rate (i.e. level of statistical multipelxing)? > - A.1, suggests there is no fixed DSCP for PCN, this seems a pity from > the point of view of a router knowing whether PCN is to be invoked, it > therefore becomes yet one more thing that could be misconfigured. I > presume this decision has been extensively discussed within the PCN WG, > so this probably does not need action? > > {TM} This follows advice from the ADs concerning how slow it is to > get a standards track DSCP assigned. I believe the hope is that PCN > will be rolled out by 1 or 2 operators and found to be successful. > We can then come back and try for a complete set of DSCPs. > Also this baseline encoding is a slight red herring as it is really > just an enabler for experiments to see which alternative encoding is > most sensible (and to see if encodings offering more codepoints are > actually necessary). Current simulation results suggest schemes with > a single marked state are less good than those with 2 marked states > Understood, and I assume the ADs would support this. See comment at end. > A.2 > o Leakage of traffic into PCN-domain: ECT(1) is less often correct. > - This does not make seem to make sense. > > {TM} can't remember why we worked that out but it seemed to make sense at > the time... However I have tried to re-phrase this. > ** Not sure this really answers the question. You seem already to have reasons, if you can not clarify this, could you consider omitting it? > > o Leakage of traffic out of PCN-domainL Either ECT is equally unsafe > ^ > - Character? /./ > done. > A.2 > o Incremental deployment: Either ECT is suitable as long as they are > ^ ^^^^^^^^^^^^^^^^ > - Please insert /codepoint/ and s/as long as/, providing that the > codepoints are/ > done. > Editorial question should it be "PCN capable" or "PCN-capable"? > done. > ** New nits: Please change /any otehr/ to /any other/ and in abstract: /t o/ to /to/. S4: / codepoint as PCN-enabled traffic MUST have the ECN field equal to 00./ - This relates to the outer IP header, right? S4.3: / Equipment complying with the baseline PCN encoding MUST allow PCN to be enabled for certain Diffserv codepoints. / - I understand this, but if this is a requirement, I should have noted that "certain" is probably not sufficient for a manufacturer to claim compliance. Would it be compliant if the manufacturer supported this only one DSCP value - and if so is there any interoperability between different vendors. Maybe I am wrong, but I would expect manufacturers to allow configuration of these codepoints from a a range of required codepoints? I observe you use both the keywords: MUST and SHALL, it is worth checking these are consistently used - or consider changing all MUST to SHALL. Last, at the end of section 6 you write: " It should be noted that this baseline encoding effectively disables end- to-end ECN except where mechanisms are put in place to tunnel such traffic across the PCN-domain." - I udnerstand this, but if I was reading this as someone wanting to preserve normal ECN semantics, I am not sure I would clearly see what would happen. If I setup a tunnel across the DS domain, then the tunneled packets ECN behaviour would be preserved, right? However, within the PCN domain then I would see a different ECN behaviour, which would be ... End. From philip.eardley@bt.com Thu May 7 06:59:51 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 DAF863A6BC1 for ; Thu, 7 May 2009 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NthCxsvvFVV for ; Thu, 7 May 2009 06:59:51 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B1A553A6AE8 for ; Thu, 7 May 2009 06:59:50 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 15:01:16 +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: Thu, 7 May 2009 15:01:16 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7BF1@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt Thread-Index: AcnIIYroMnOqKCysTKOD+mcRMI9IdwG+TQQQ From: To: X-OriginalArrivalTime: 07 May 2009 14:01:16.0751 (UTC) FILETIME=[4A30B5F0:01C9CF1C] Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Thu, 07 May 2009 13:59:51 -0000 Some LC comments: Non-NIT: 4.1 A PCN-interior-node MUST observe the rules for valid and invalid codepoint transitions as set out in the following table. The precise rules governing which valid transition to use are set out in [I-D.ietf-pcn-marking-behaviour] unfortunately it doesn't - thought we'd decided best to handle here? anyway, all it would need would be something like: NM -> PM if meter indicates to mark EXP -> PM maybe allowed in exptal extension NITS Abstract: Unmarked and marked - use the defined terms Throughout: think the rfc style guide has "Diffserv" & "IPsec" 4.1 - "It MUST set the not-PCN (00) codepoint on all other packets. You mean: packets with the PCN-compatible codepoint 4.2 There are a number of factors that were considered before deciding to set 10 as the NM state. =20 Insert: "(instead of 01)! 4.3 "traffic scheduling and conditioning" - would metering & marking be better? Not sure scheduling is mentioned. conditioning is about (latest edit) to be replaced by "dropping" ['conditioning' has a wider meaning to diffserv experts] 5 "otehr" 6 except where =3D> unless 8 pcn-compatible enabled - capitalisation is different from terminilogy the architecture used to determine whether =3D> how pcn edge node =3D> PCN-boundary-node 12 - table loos odd marking behaviour title is changing to ""Metering and marking behaviour of PCN-nodes" Appendix Say it's informative A.2=20 Title & text: Not marked =3D> not-marked phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { slblake@petri-meat.com { Sent: 28 April 2009 17:48 { To: pcn@ietf.org { Subject: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt {=20 { The working group last call for draft-ietf-pcn-baseline-encoding-03.txt { starts now, and will end in two weeks (Tuesday May 12). Please send { comments to the list. {=20 { http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding {=20 {=20 { Regards, {=20 { // Steve { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Thu May 7 09:49:14 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7941528C301 for ; Thu, 7 May 2009 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP2fDXX14H93 for ; Thu, 7 May 2009 09:49:13 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 5DAF228C30A for ; Thu, 7 May 2009 09:47:56 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 17:49:23 +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: Thu, 7 May 2009 17:48:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7BF3@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <0AD29BC9-757C-4AEF-9F99-939BEF18A936@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN elevator speech Thread-Index: AcnFN+zh+vmen8uBRoyHt8KVh0CQEwJ+2ntw From: To: , X-OriginalArrivalTime: 07 May 2009 16:49:23.0572 (UTC) FILETIME=[C6677340:01C9CF33] Cc: pcn@ietf.org Subject: Re: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 16:49:14 -0000 Fred, To let you know that in the draft-ietf-pcn-marking-behaviour [currently updating] Have added in Section B.5 the sentence=20 The PCN-threshold-rate is configured at less than the rate allocated to the PCN-traffic class. And in B.6 The PCN-excess-rate is configured at less than (or possibly equal to) the rate allocated to the PCN-traffic class. phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fred { Baker { Sent: 25 April 2009 00:54 { To: Tom Taylor { Cc: pcn { Subject: Re: [PCN] PCN elevator speech {=20 { I have an additional edit. {=20 { Generally, one doesn't configure a link to run full-bore and then { scale back to deal with the traffic it has. r\Rather, one configures a { link to deal effectively with specific application classes. For { example, one will generally have a class for real-time traffic or { separate classes for voice and video, with a separate class for { elastic applications. This results in the real time traffic being { handled in a way that serves its needs (it is guaranteed at most a { given latency on a link so that e2e delay variation doesn't exceed { some threshold), allowing elastic traffic to do the things it is { famous for doing without interrupting real-time services. {=20 { As such, the reference to "the rate of the link" should refer to the { "the rate allocated to a traffic class". If the class in fact occupies { the whole link, the two statements are equivalent. If that observation { gives heartburn, I would suggest "the rate of a traffic class, or { where appropriate, a link". {=20 { It would also be very nice if we could somehow provide an architecture { in which we are not using one mechanism differently for two different { purposes, but using one mechanism to serve one purpose interpreted { differently by different use cases. We are willing to have pre- { congestion notification for voice/video/etc, but are willing to build { queues for data in some cases, and in other cases have had suggestions { that folks could similarly manage RFC 3168-like ECN based on traffic { rates in elastic classes. If we are building an architecture for ECN { in general of which PCN and RFC 3168 are special cases, then that { should be reflected in this proposed text. {=20 { On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote: {=20 { > Having said this, I would beg the indulgence of the group to modify { > the second-last sentence slightly, so it reads: { > { > "The level of marking allows decisions to be made about whether to { > admit or terminate." { > { > Tom Taylor wrote: { >> Here is the text that is proposed to begin all PCN-related { >> documents. Phil actually did the work, with input from others. { >> 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. Two mechanisms are used: { >> admission control, to decide whether to admit or block a new flow { >> request, and (in abnormal circumstances) flow termination to decide { >> whether to terminate some of the existing flows. Together they { >> protect { >> the QoS of previously admitted flows. To achieve this, 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. These configured rates are below the rate of the link thus { >> providing notification before any congestion occurs (hence { >> "pre-congestion notification"). The level of marking allows the { >> boundary { >> nodes to make decisions about whether to admit or terminate. For a { >> full description of the PCN architecure see [RFC xxxx (the { >> architecture document)]. { >> _______________________________________________ { >> 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 {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From root@core3.amsl.com Fri May 8 09: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 093443A6AA0; Fri, 8 May 2009 09:15: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: <20090508161502.093443A6AA0@core3.amsl.com> Date: Fri, 8 May 2009 09:15:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-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: , X-List-Received-Date: Fri, 08 May 2009 16: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 : Metering and marking behaviour of PCN-nodes Author(s) : P. Eardley Filename : draft-ietf-pcn-marking-behaviour-03.txt Pages : 21 Date : 2009-05-08 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. This document specifies the two metering and marking behaviours of PCN-nodes. Threshold- metering and -marking marks all PCN-packets if the PCN traffic rate is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-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 marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-03.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-marking-behaviour-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-08091424.I-D@ietf.org> --NextPart-- From philip.eardley@bt.com Fri May 8 09:33:26 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285623A6A8D for ; Fri, 8 May 2009 09:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcXpx3sbPUbJ for ; Fri, 8 May 2009 09:33:25 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id EB3013A69D3 for ; Fri, 8 May 2009 09:33:24 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 17:34:51 +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, 8 May 2009 17:34:07 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7C0D@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20090508161502.093443A6AA0@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-03.txt Thread-Index: AcnP+GzrVUFGo8iYQyale76nAocB+gAAc4IQ From: To: X-OriginalArrivalTime: 08 May 2009 16:34:51.0860 (UTC) FILETIME=[E93C8140:01C9CFFA] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-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: , X-List-Received-Date: Fri, 08 May 2009 16:33:26 -0000 Hi I updated the metering & marking behaviours draft to take account of the Last Call comments (thanks for the comments!) (I also took account of comments during the IESG review of the architecture draft) Scott, Steve - I think this is now ready for the next stage =3D WG Chair processing? Best wishes Phil 6.1. Changes to -03 from -02 Updates to take account of last call comments as follows: o renamed from "marking" to "metering and marking" (throughout) - the former was intended as shorthand for the latter, but this was found confusing o added 'common capsule' summary of PCN to Introduction and removed extraneous material o replaced the term 'traffic conditioning' by 'dropping' (throughout) - since the former has a wider meaning than just dropping. o discussion of the case with baseline encoding where there are two PCN states - this is now done just once - in Section B.2. o added in Section B.5 "The PCN-threshold-rate is configured at less than the rate allocated to the PCN-traffic class" and in B.6 "The PCN-excess-rate is configured at less than (or possibly equal to) the rate allocated to the PCN-traffic class". o configuring the PCN-excess-rate at greater than (or possibly equal to) the PCN-threshold-rate - this is now in one place, as advice is B5 & B6. o SB.1: "voice-admit" corrected with references to I-D ietf-tsvwg- admitted-realtime-dscp and RFC5127. o "CL/SM edge behaviour" altered to the less obscure "controlled load edge behaviour" and a reference added. o S2.3, 2.4 & Appendix A: altered some of the abbreviations, for better consistency with approach of RFC2698. eg TBthreshold.fill =3D> Ttm. o the ACKs section improved o other minor corrections and clarifications { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 08 May 2009 17:15 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-03.txt {=20 { 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. {=20 {=20 { Title : Metering and marking behaviour of PCN-nodes { Author(s) : P. Eardley { Filename : draft-ietf-pcn-marking-behaviour-03.txt { Pages : 21 { Date : 2009-05-08 {=20 { 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. This document specifies { the two metering and marking behaviours of PCN-nodes. Threshold- { metering and -marking marks all PCN-packets if the PCN traffic rate { is greater than a configured rate ("PCN-threshold-rate"). Excess- { traffic-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 marking allows { PCN-boundary-nodes to make decisions about whether to admit or { terminate PCN-flows. {=20 { A URL for this Internet-Draft is: { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- { 03.txt {=20 { Internet-Drafts are also available by anonymous FTP at: { ftp://ftp.ietf.org/internet-drafts/ {=20 { Below is the data which will enable a MIME compliant mail reader { implementation to automatically retrieve the ASCII version of the { Internet-Draft. From ingemar.s.johansson@ericsson.com Tue May 12 01:34:43 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 082AB3A6A76 for ; Tue, 12 May 2009 01:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.871 X-Spam-Level: X-Spam-Status: No, score=-5.871 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4t9NCqg5YE7 for ; Tue, 12 May 2009 01:34:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9A60F3A67FD for ; Tue, 12 May 2009 01:34:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b7fae0000015ab-3c-4a0934f1c555 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 38.C7.05547.1F4390A4; Tue, 12 May 2009 10:36:01 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 10:36:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 May 2009 10:36:00 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pcn-marking-behaviour-03.txt, some comments Thread-Index: AcnS3K3OaeZqmTjZSE67ijjs4M+M2g== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 12 May 2009 08:36:01.0218 (UTC) FILETIME=[AE177220:01C9D2DC] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S Subject: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments 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, 12 May 2009 08:34:43 -0000 Hi I have some comments on draft-ietf-pcn-marking-behaviour-03. I would = believe that all the comments are of the nit-picking kind also it has = been a few moons since I had time to delve into this area and I may have = missed something so I trust you to disagree where needed :-) Section 1, bullet 1 : "its objective is to mark all packets...".=20 Is it necessary to have "all" in the sentence ?.=20 As I see it it is likely that a token bucket will introduce a threshold = marking pattern that is not a continuous threshold-mark for all packets, = this mecause the bucket level may be either above or below the threshold = when a packet arrives. The word "all" in the sentence gives me that all = packets within some given time frame are marked and my understand that = this is not the case (I believe). But perhaps I am over-interpreting the = statement ?.=20 Section 2.4, bullet 1 : Is it possible to make a reference to the = motivation behind this in B.6 ? Section 2.4, MTU : As a reader I get a bit confused here. My = (application view) interpretation of MTU is the maximum allowed packet = size that is discovered by an endpoint (is this refered to as path-MTU = ?). In this context however I believe it is the maximum experienced = packet size on the link.=20 Section B.1, Competing-non-PCN-traffic: "In such cases PCN-traffic and = competing-non-PCN-traffic are distinguished by different values of the = ECN field [I-D.ietf-pcn-baseline-encoding]" I would suggest that the sentence is slightly rewritten as "In such cases, and if baseline encoding = [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and = competing-non-PCN-traffic are distinguished by different values of the = ECN field"=20 The reason is that it may not be possible to do this distinction with = other encoding schemas. Regards Ingemar=20 *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From menth@informatik.uni-wuerzburg.de Tue May 12 07:05:17 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 46AA33A6C85 for ; Tue, 12 May 2009 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhYsGs8r5v8P for ; Tue, 12 May 2009 07:05:16 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id BD9AD3A6C31 for ; Tue, 12 May 2009 07:05:15 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8F2701990F3; Tue, 12 May 2009 16:06:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 81E4D1990D5; Tue, 12 May 2009 16:06:46 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5F89E19908F; Tue, 12 May 2009 16:06:46 +0200 (CEST) Message-ID: <4A098277.9020301@informatik.uni-wuerzburg.de> Date: Tue, 12 May 2009 16:06:47 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 14:05:17 -0000 Hi Ingemar, hi Phil, Ingemar Johansson S schrieb: > Hi > > I have some comments on draft-ietf-pcn-marking-behaviour-03. I would believe that all the comments are of the nit-picking kind also it has been a few moons since I had time to delve into this area and I may have missed something so I trust you to disagree where needed :-) > > Section 1, bullet 1 : "its objective is to mark all packets...". > Is it necessary to have "all" in the sentence ?. > As I see it it is likely that a token bucket will introduce a threshold marking pattern that is not a continuous threshold-mark for all packets, this mecause the bucket level may be either above or below the threshold when a packet arrives. The word "all" in the sentence gives me that all packets within some given time frame are marked and my understand that this is not the case (I believe). But perhaps I am over-interpreting the statement ?. > > Section 2.4, bullet 1 : Is it possible to make a reference to the motivation behind this in B.6 ? > > Section 2.4, MTU : As a reader I get a bit confused here. My (application view) interpretation of MTU is the maximum allowed packet size that is discovered by an endpoint (is this refered to as path-MTU ?). In this context however I believe it is the maximum experienced packet size on the link. > Phil, packet-size-independent marking can be achieved for excess marking simply by letting the token bucket counter become negative. When the counter is larger than zero, the packet is not marked, otherwise it is marked. This eliminates unclarities about MTUs and simplifies configuration. > Section B.1, Competing-non-PCN-traffic: "In such cases PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field [I-D.ietf-pcn-baseline-encoding]" > I would suggest that the sentence is slightly rewritten as > "In such cases, and if baseline encoding [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field" > The reason is that it may not be possible to do this distinction with other encoding schemas. > I believe that any encoding for PCN traffic needs to make sure that PCN traffic can be differentiated from non-PCN traffic. I do not think that we need to make this statement depending on any encoding scheme. Regards, Michael > > Regards > Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Luleå, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > 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/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From philip.eardley@bt.com Wed May 13 08:56:12 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 600873A6BD1 for ; Wed, 13 May 2009 08:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmoCFwbN4HGC for ; Wed, 13 May 2009 08:56:10 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D92153A6DFF for ; Wed, 13 May 2009 08:56:07 -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); Wed, 13 May 2009 16:57:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 16:57:37 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments Thread-Index: AcnTCvAMTR0KeykKRQi5j3pvrIFBFAAyIpZ1 References: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> <4A098277.9020301@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 13 May 2009 15:57:38.0521 (UTC) FILETIME=[8A20C490:01C9D3E3] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments 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, 13 May 2009 15:56:12 -0000 ingemar, i dont seem to have got your email, so sorry for what i dont answer! ________________________________ From: pcn-bounces@ietf.org on behalf of Michael Menth Sent: Tue 12/05/2009 15:06 To: Ingemar Johansson S Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some = comments Hi Ingemar, hi Phil, Ingemar Johansson S schrieb: > Hi > > I have some comments on draft-ietf-pcn-marking-behaviour-03. I would = believe that all the comments are of the nit-picking kind also it has = been a few moons since I had time to delve into this area and I may have = missed something so I trust you to disagree where needed :-) > > Section 1, bullet 1 : "its objective is to mark all packets...". > Is it necessary to have "all" in the sentence ?. > As I see it it is likely that a token bucket will introduce a = threshold marking pattern that is not a continuous threshold-mark for = all packets, this mecause the bucket level may be either above or below = the threshold when a packet arrives. The word "all" in the sentence = gives me that all packets within some given time frame are marked and my = understand that this is not the case (I believe). But perhaps I am = over-interpreting the statement ?. [phil] correct, it doesnt latch into a state where every pkt is marked = for N secs regardless of the state of the token bucket. i think by "all" = it was trying to contrast with the excess marking, where some pkts are = always unmarked (up to the excess-traffic-rate). hopefully when it gets = to teh formal description of the metering behaviour this is clear, i'll = look how to improve the Intro text (maybe just deleting 'all' is enough] > Section 2.4, bullet 1 : Is it possible to make a reference to the = motivation behind this in B.6 ? [phil] - it is! para 4, "This avoids over- termination (with some edge behaviours) in the event that the PCN- traffic passes through multiple bottlenecks in the PCN-domain [I-D.charny-pcn-comparison = ]. " > > Section 2.4, MTU : As a reader I get a bit confused here. My = (application view) interpretation of MTU is the maximum allowed packet = size that is discovered by an endpoint (is this refered to as path-MTU = ?). In this context however I believe it is the maximum experienced = packet size on the link. > =20 Phil, packet-size-independent marking can be achieved for excess marking simply by letting the token bucket counter become negative. When the counter is larger than zero, the packet is not marked, otherwise it is marked. This eliminates unclarities about MTUs and simplifies = configuration. [phil] ingemar, you're right. i'll get rid of the MTU term which is = adding only unclearness.=20 [phil] michael, true, that seems to be a way of implementing it (btw = what do you do if another pkt arrives whilst TB is negative? - dont = think paper mentions this). i'm not sure it's the best way here, which = is description to make clear the objective /behaviour of the metering, = without implying a particualr implementation.=20 > Section B.1, Competing-non-PCN-traffic: "In such cases PCN-traffic and = competing-non-PCN-traffic are distinguished by different values of the = ECN field [I-D.ietf-pcn-baseline-encoding]" > I would suggest that the sentence is slightly rewritten as > "In such cases, and if baseline encoding = [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and = competing-non-PCN-traffic are distinguished by different values of the = ECN field" > The reason is that it may not be possible to do this distinction with = other encoding schemas. > =20 I believe that any encoding for PCN traffic needs to make sure that PCN traffic can be differentiated from non-PCN traffic. I do not think that we need to make this statement depending on any encoding scheme. [phil] ingemar, this really comes out of the disussions about encoding, = and how baseline & future extensions relate to each other - and as = michael says, way of distinguishing pcn & competing-non-pcn traffic in = way that doesnt depend on the coding scheme. anyway, to shift the = discussion onto the encoding draft! - i just copied what the baseline = encoding says. It defines (S5) "Rules for Experimental Encoding = Schemes": o The 00 codepoint in the ECN field SHALL indicate not-PCN and MUST NOT be changed to any otehr codepoint within a PCN-domain. Therefore an ingress node wishing to disable PCN marking for a packet within a PCN-compatible DiffServ Codepoint MUST set the ECN field to 00. i guess your idea is that with some exptal encoding (you have in mind?) = the pcn & competing-non-pcn traffic might be differentiated by something = other than the ecn field? (maybe dscp??) perhaps some other verb than = "are distinguished" would be better (which perhaps implies a method = ratehr than a potential method?) (maybe re-phrase as: "they differ in = their values of the ECN field"?). sory if i don't get your point = proprely thanks phil Regards, Michael > > Regards > Ingemar > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > =20 -- 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/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Wed May 13 09:34: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 49BE13A6C80 for ; Wed, 13 May 2009 09:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3HrcznNSd2s for ; Wed, 13 May 2009 09:34:23 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 12EFD3A6B77 for ; Wed, 13 May 2009 09:34:23 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C3A23A0717; Wed, 13 May 2009 18:35:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B73EAA06F0; Wed, 13 May 2009 18:35:52 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A2CCFA06E4; Wed, 13 May 2009 18:35:52 +0200 (CEST) Message-ID: <4A0AF6E9.9050901@informatik.uni-wuerzburg.de> Date: Wed, 13 May 2009 18:35:53 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: philip.eardley@bt.com References: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> <4A098277.9020301@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: ingemar.s.johansson@ericsson.com, pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 16:34:24 -0000 Hi Phil, Ingemar, and others, >> Section 2.4, MTU : As a reader I get a bit confused here. My (application view) interpretation of MTU is the maximum allowed packet size that is discovered by an endpoint (is this refered to as path-MTU ?). In this context however I believe it is the maximum experienced packet size on the link. >> >> > Phil, packet-size-independent marking can be achieved for excess marking > simply by letting the token bucket counter become negative. When the > counter is larger than zero, the packet is not marked, otherwise it is > marked. This eliminates unclarities about MTUs and simplifies configuration. > > > [phil] ingemar, you're right. i'll get rid of the MTU term which is adding only unclearness. > > [phil] michael, true, that seems to be a way of implementing it (btw what do you do if another pkt arrives whilst TB is negative? - dont think paper mentions this). [Michael] The algorithms says: mark if TB is negative (no matter if another packet was marked before) > i'm not sure it's the best way here, which is description to make clear the objective /behaviour of the metering, without implying a particualr implementation. > [Michael] I believe the simple example helps to show that packet-size independent marking is simple to implement. Other implementations are of course possible. If the text does not give an idea, packet-size independent marking remains a mysterious desire for most readers. 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/31-86644 (new), fax: (+49)-931/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From sblake@extremenetworks.com Wed May 13 12:18:59 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 F38533A7002 for ; Wed, 13 May 2009 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60icOQIm+smd for ; Wed, 13 May 2009 12:18:58 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id 17B173A7005 for ; Wed, 13 May 2009 12:18:26 -0700 (PDT) Received: from [10.5.2.44] (10.5.2.44) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server id 8.1.291.1; Wed, 13 May 2009 12:19:58 -0700 From: Steven Blake To: "pcn@ietf.org" In-Reply-To: References: Content-Type: text/plain Organization: Extreme Networks Date: Wed, 13 May 2009 19:19:56 +0000 Message-ID: <1242242396.3782.19.camel@ecliptic.corp.extremenetworks.com> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Wed, 13 May 2009 19:18:59 -0000 On Tue, 2009-04-28 at 09:47 -0700, slblake@petri-meat.com wrote: > The working group last call for draft-ietf-pcn-baseline-encoding-03.txt > starts now, and will end in two weeks (Tuesday May 12). Please send > comments to the list. > > http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding The WGLC for this draft was scheduled to close yesterday, but I only saw comments from Philip Eardley. If you have any comments on this draft, please submit them this week. Regards, ///////////////////////////////////////////// Steven Blake sblake@extremenetworks.com Extreme Networks +1 919-884-3211 From toby.moncaster@bt.com Thu May 14 02:20:03 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 8E5803A6AFB for ; Thu, 14 May 2009 02:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7W+DHHEWdBf for ; Thu, 14 May 2009 02:20:01 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 666B13A67D4 for ; Thu, 14 May 2009 02:20:00 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 10:21:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: AqLe CvmZ FaEM HmRU J81i KHKq LqdR N2J0 PpQO QPXY QZRj Q++V S1mR TTxJ UHeZ WAgf; 2; cABjAG4AQABpAGUAdABmAC4AbwByAGcAOwBzAGwAYgBsAGEAawBlAEAAcABlAHQAcgBpAC0AbQBlAGEAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {C055C5AA-1175-47E4-899E-1FAEF03BAA40}; dABvAGIAeQAuAG0AbwBuAGMAYQBzAHQAZQByAEAAYgB0AC4AYwBvAG0A; Thu, 14 May 2009 09:21:21 GMT; RgBXADoAIABTAG8AbQBlACAAYwBvAG0AbQBlAG4AdABzACAAIABvAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcABjAG4ALQBiAGEAcwBlAGwAaQBuAGUALQBlAG4AYwBvAGQAaQBuAGcALQAwADIA x-cr-puzzleid: {C055C5AA-1175-47E4-899E-1FAEF03BAA40} Content-class: urn:content-classes:message Date: Thu, 14 May 2009 10:21:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-ietf-pcn-baseline-encoding-02 Thread-Index: AcnNoZqBGi7uUbWQQ+ypsAFFHkcQogG0y9SQ From: To: X-OriginalArrivalTime: 14 May 2009 09:21:32.0037 (UTC) FILETIME=[5E9CDB50:01C9D475] Cc: pcn@ietf.org Subject: [PCN] FW: Some comments on draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Thu, 14 May 2009 09:20:03 -0000 There were some effectively LC comments from Gorry that were posted to the list (and copied below). http://www.ietf.org/mail-archive/web/pcn/current/msg02090.html Toby -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=20 Sent: 05 May 2009 17:50 To: Moncaster,T,Toby,CXR9 R Cc: pcn@ietf.org Subject: Re: Some comments on draft-ietf-pcn-baseline-encoding-02 Greetings Toby! Thanks, I was pleased to see many of the comments had been addressed. There are some comments that you may like to consider further as you process any other LC comments (marked **). I hope this helps, this document seems quite mature and looks nearly finished. Best wishes, Gorry toby.moncaster@bt.com wrote: > Hi Gorry, > =20 > here is your list of comments with my annotations of how I addressed them in version 03 (the current version which is in WGLC). My comments marked {TM}... > =20 > Toby >=20 > ________________________________ >=20 > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Fri 27/03/2009 18:20 > To: pcn@ietf.org > Cc: Briscoe,RJ,Bob,CXR9 R; Moncaster,T,Toby,CXR9 R; menth@informatik.uni-wuerzburg.de; Gorry > Subject: Some comments on draft-ietf-pcn-baseline-encoding-02 >=20 >=20 >=20 > Here are some comments on pcn baseline encoding, the document seems in > good shape, but there are probably a few things I would update to help > others to read this document. >=20 > Gorry >=20 >=20 > General comments: >=20 > - It would be really nice to see the explanation. >=20 > {TM} this comment really applies to lots of the drafts.=20 > We have now concocted a new Intro paragraph (elevator pitch) > to set the scene + I re-wrote the abstract (see later) >=20 True. I found the new abstract is much clearer, if i had read this and the new introduction I do not think that I would have made that comment. > - I had problems reading this to understand what was the implication on > packet forwarding - the key thing that I thought was missing, I later > found in 4.2. Have the authors thought about placing this section ahead > of the others and then explicitly calling out with a [very short] > subsection on what to do if there were a DSCP conflict and how the > original traffic could be mapped to not-PCN and the where to find > details on how to traffic ECN-enabled traffic on this DSCP (i.e. tunnel?). >=20 > {TM}I still need to write a sub-section to address this, but am not=20 > sure where it should fit in the structure. Probably within 4.3 or as a > new subsection 4.3.1. I can then refer to it in the intro... >=20 >=20 > - I found Table 2 hard to understand, then discovered there were some > encodings missing. >=20 > {TM} Completely replaced with text sections for ingress and egress=20 > + a new table for the interior nodes. > Let me know if this is any clearer (not sure how else to clarify > it as there are so many posisble transitions) >=20 Looks good. > - I think the security considerations could be improved. >=20 > {TM} Did my best but they are still not ideal.=20 > Any suggestions on additions gratefully received! >=20 > - To me, Appendix A.2 seems reasonable. > ** This point seems weak: "o Leakage of traffic into PCN-domain: ECT(1) is slightly less likely" I think you should be stronger e.g.: "Overall this seemed to suggest ECT(0) was most appropriate to use." - e.g. On the basis of the above considerations, ECT(0) was selected for use. >=20 > ---------------------- > Specific comments: >=20 > Abstract > - English seems to me to need a little polishing. > s/in order// ? > - Please mention ECN code points in the abstract. > - Later you say a sentence such as: > The PCN encoding states are defined using a combination of the DSCP > and ECN fields within the IP header. The baseline PCN encoding > closely follows the semantics of ECN [RFC3168]. >=20 > {TM} re-wrote abstract completely. Let me know if you think it is better or not >=20 > Abstract > " below the physical link rate." - This seems very odd to me, I thought > this was about the link capacity. >=20 > {TM} I think its about link rate but this is more to do with the architecture > and marking behaviour. The new intro which has been agreed by most=20 > people > uses rate not capacity... >=20 > Abstract > "states but such schemes will be described in other documents." > ^ > - insert comma, or better still separate this into two sentences (to me > it seems an odd way for a PS abstract to finish). >=20 The rewrite looks good to me. > S1 > Makes no mention of ECN fields, which would be nice for people wanting > to look for documents that show the meaning of the ECN-field. >=20 > {TM} It now mentions ECN ** Good, although a NIT is it would be nice to see the term "ECN" defined (expanded) the first time it appears in the introduction. >=20 > S1 > "Other extensions have also been suggested all of which can build on the > baseline encoding." > - Seems very bold. is the WG sure that *ALL* can build on this? >=20 > {TM} removed claim and replaced with "can be easily extended" plus=20 > pointed out the guidelines later in doc (but no xref) >=20 ** NiT: I misread /states and rules/ when I first read this, perhaps you could put some punctuation in here? e.g. /However, the encoding can be easily extended to provide more states. Rules for such extensions are given in this document./ > S1 > "MUST extend this baseline scheme" > - How? - The draft places a normative requirement, but doesn't say what > is intended. Is this by updating this specification? By obsoleting this > spec? using some common part of the same framework? - I don't see what > is being required. >=20 > {TM} removed this >=20 OK - that avoids this issue. > S3, bullet 2 > o PCN-marked - codepoint indicating packets that have been marked at > a PCN-interior-node using some PCN marking behaviour > [pcn-marking-behaviour]. Also PM. > ^^^^^^^ > - is this an alternative or a definition of the term PN? >=20 > {TM} its the official abbreviation. I've clarified all these definitions >=20 > S3: > o Not-marked - codepoint indicating packets that are PCN-capable but > ^ > - comma? > S3: > are not PCN-marked. Also NM. > ^^^^^^^ > - is this an alternative or, as I think, a definition of the term NM? >=20 >=20 > S3: > By definition packets carrying such codepoints are PCN-packets. > ^ > - comma? >=20 > S3: > o PCN-compatible Diffserv codepoint - a Diffserv codepoint for which > the ECN field is used to carry PCN markings rather than [RFC3168] > markings. > - Could this definition be placed as bullet one or bullet two? >=20 > {TM} re-ordered all the definitions... >=20 Fine now. > S3: > In addition the document uses the terminology defined in [pcn-arch]. > ^ > - comma? >=20 > S4: > allows for traffic that is not PCN capable to be marked as such (Not- > PCN). > - I'd like to see this more clearly called out. The reader of this spec > may be trying to figure out how these codepoints are used with PCN and > how to transport the traditional use of ECN or where the DSCP is already > used for non PCN traffic. The structure of the document did not really > help me in this case at all (although the framework seems to be > addressing this case). A very short section that simply sets out the NON-PCN >=20 > {TM} This probably still needs to be addressed. If I add a section as=20 > asked for above on DSCPs this would naturally sit there. But not sure=20 where > best to insert the section? > ** This question still seems to need an answer. >=20 > S4 > to prevent any possible future compatability issues. > - remove /any/ - or are sure? >=20 > {TM} I was fairly sure but I removed it anyway >=20 done. >=20 > S4 > o Any packet that is not PCN-enabled (Not-PCN) but which shares the > ^ >=20 > S4 > Table 2 is not easily understood. In fact, I got pretty confused, then > discovered there were some encodings missing. I'd really like to see all > the encodings or a different table format. >=20 > {TM} see comment above >=20 > S4 > packet MUST be treated as if it were NM. > ^^^^^^ > - as if it carried the NM marking? >=20 > {TM} yep >=20 > S4 > End 4.0 has a truncated sentence >=20 > {TM} Ooops! Don't know what happened there. Over-enthusiastic use of delete key >=20 >=20 > 4.1 says: > If the packet is being tunneled then only the 11 codepoint gets copied > into the inner header upon decapsulation. >=20 > - This language seems odd to me. >=20 > {TM} rephrased this to hopefully make it clearer=20 > - and people will have to read Bob's ECN tunnel draft (which is much > clearer in its new form) to find out more >=20 >=20 > An additional constraint is the need to minimise > the use of DiffServ codepoints as > ^^ > -English? - because? >=20 > {TM} sorry, missed this one... >=20 ** Please fix > S4.1 > The encoding scheme above seems to meet all these constraints and > - is this WG consensus, or author's? ** Seems fine, then I'd be happier making this decision and saying "This was judged by the PCN WG to ..." >=20 > {TM} I think its more or less WG consensus by now...=20 > It took a lot of arguing to get to this scheme and many dead ends... >=20 > S4.2 > Enabling PCN for a DSCP switches on PCN marking behaviour for packets > ^^^^^^^^^^^^^ > - Better phrase here? >=20 > {TM} I've tried to improve the phrasing >=20 OK > S4.2 > but only if those packets also have their ECN field > set to indicate a codepoint other than Not-PCN. > - presumably this refers to PCN router behaviour within a PCN domain? >=20 > {TM} Yes. Probably I should add this is only relevant within the PCN-domain >=20 ** I think your proposed change would be an improvement. > S4.2 > Enabling PCN marking behaviour disables any other marking behaviour > - OK, but I think this should be clearer that this is for only for a > specific DSCP. >=20 > {TM} missed this one >=20 ** I think this should be changed. > S5 > o The 00 codepoint in the ECN field MUST mean Not-PCN. > - not sure /mean/ is the correct word, should it be /indicate/ (and > following points) > - and should this also say and /MUST NOT be changed to any other > codepoint within a PCN domain/? >=20 > {TM} Yes - and now does say this. Also corrected to indicate >=20 OK > S5 > o Once set the 11 codepoint in the ECN field MUST NOT be changed to > ^ > - insert comma > - /doesn't/ change to /does not/ >=20 > S5 > o Any experimental scheme MUST include details of all valid and > invalid codepoint transitions at any PCN nodes. > - OK, you could say it MUST NOT update 00 or 11 (or is this now implicit?) >=20 > {TM} added. Hopefully everyone agrees with this... >=20 > S8 > Packets claim entitlement to be PCN marked by carrying a PCN- > - English? I think the document should say that that a PCN domain has > been pre-configured with domain edges, and that this document describes > behaviour within the domain. >=20 > {TM} I re-wrote section 8. Can you look and see if you think I addressed > most of these comments? >=20 Better > S8 > However there is a > requirement to keep inter-domain scenarios in mind when defining the > PCN encoding. > - I found this rather vague, or more precisely too vague for me to > understand the implications. >=20 Fixed. > S8 > Then any one domain's security against its neighbours would > be described as part of the proposed edge-node behaviour document. > - I could not understand what the security implication was and what was > being requested of people who followed this document with new proposals. >=20 > {TM} On re-reading I found this unhelpful so I removed and changed it >=20 OK > S9 > It also allows for the co- > existence of competing traffic within the same DSCP so long as that > traffic doesn't require end-to-end ECN support. > s/doesn't/does not/ > - This sounds categorical that this is not possible, but presumably > tunnels may be used. Is there better language that could be chosen? >=20 > {TM} I missed this one. I should probably clarify that ECN can be=20 > tunneled but that it is effectively disabled within the PCN-domain. >=20 ** Not sure I understand what you propose that the new text would say. I think that ECN markings may be tunneled across an ECN domain, by encapsulating an IP packet with a tunnel header. How would the outer header of the tunnel be treated if the tunnel egress endpoint was outside the PCN domain? ** Section 8 also describes behaviour when IPsec is used to tunnel PCN marked packets. > S11 > - Should be removed by RFC-Ed? > {TM} yes >=20 Done. > S12: Refs. > - Are there no normative architecture specifications to define what PCN > is? - Seems odd for a PS, could this be [pcn-arch]. >=20 > {TM} indeed it does seem odd but that is what the charter states.=20 > I think it is sort of trying to follow the lead of DiffServ where the > architecture is an informational document. I have tried to refer to > marking behaviour more often as that is standards track. >=20 Seems to be addressed. > S12: Refs. > - Why is RFC3168 also not normative? > done. >=20 > A.1 > domain includes lower speed links > ^^^^^^^^^^^^^^^^^^ > - Is this really the issue??? Or does this describe a PCN network link > with a link with low flow aggregation as an example of the case where > other appropriate use is needed. If this is not the case, we should > quantify what is meant by "lower speed" and be much more clear about the > guidance here. Either way, I find this confusing. >=20 > {TM} I have left this as is. Can others comment on whether they find > this confusing also? It might almost be easier just to remove this > section altogether> > The new text seems better. ** The terms "higher" and "lower" are comparative terms, and am I right that here it relates to the ratio between the rates of the admitted flows and the link rate (i.e. level of statistical multipelxing)? > - A.1, suggests there is no fixed DSCP for PCN, this seems a pity from > the point of view of a router knowing whether PCN is to be invoked, it > therefore becomes yet one more thing that could be misconfigured. I > presume this decision has been extensively discussed within the PCN WG, > so this probably does not need action? >=20 > {TM} This follows advice from the ADs concerning how slow it is to=20 > get a standards track DSCP assigned. I believe the hope is that PCN > will be rolled out by 1 or 2 operators and found to be successful. > We can then come back and try for a complete set of DSCPs. > Also this baseline encoding is a slight red herring as it is really > just an enabler for experiments to see which alternative encoding is > most sensible (and to see if encodings offering more codepoints are > actually necessary). Current simulation results suggest schemes with > a single marked state are less good than those with 2 marked states >=20 Understood, and I assume the ADs would support this. See comment at end. > A.2 > o Leakage of traffic into PCN-domain: ECT(1) is less often correct. > - This does not make seem to make sense. >=20 > {TM} can't remember why we worked that out but it seemed to make sense at > the time... However I have tried to re-phrase this. > ** Not sure this really answers the question. You seem already to have reasons, if you can not clarify this, could you consider omitting it? >=20 > o Leakage of traffic out of PCN-domainL Either ECT is equally unsafe > ^ > - Character? /./ >=20 done. > A.2 > o Incremental deployment: Either ECT is suitable as long as they are > ^ ^^^^^^^^^^^^^^^^ > - Please insert /codepoint/ and s/as long as/, providing that the > codepoints are/ >=20 done. > Editorial question should it be "PCN capable" or "PCN-capable"? >=20 done. >=20 ** New nits: Please change /any otehr/ to /any other/ and in abstract: /t o/ to /to/. S4: / codepoint as PCN-enabled traffic MUST have the ECN field equal to 00./ - This relates to the outer IP header, right? S4.3: / Equipment complying with the baseline PCN encoding MUST allow PCN to be enabled for certain Diffserv codepoints. / - I understand this, but if this is a requirement, I should have noted that "certain" is probably not sufficient for a manufacturer to claim compliance. Would it be compliant if the manufacturer supported this only one DSCP value - and if so is there any interoperability between different vendors. Maybe I am wrong, but I would expect manufacturers to allow configuration of these codepoints from a a range of required codepoints? I observe you use both the keywords: MUST and SHALL, it is worth checking these are consistently used - or consider changing all MUST to SHALL. Last, at the end of section 6 you write: " It should be noted that this baseline encoding effectively disables end- to-end ECN except where mechanisms are put in place to tunnel such traffic across the PCN-domain." - I udnerstand this, but if I was reading this as someone wanting to preserve normal ECN semantics, I am not sure I would clearly see what would happen. If I setup a tunnel across the DS domain, then the tunneled packets ECN behaviour would be preserved, right? However, within the PCN domain then I would see a different ECN behaviour, which would be ... End. From ingemar.s.johansson@ericsson.com Thu May 14 04:48:15 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 0B31628C253 for ; Thu, 14 May 2009 04:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXsnufgfZUoV for ; Thu, 14 May 2009 04:48:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F277B3A6C3B for ; Thu, 14 May 2009 04:48:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-4f-4a0be8540226 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E2.F8.02531.458EB0A4; Thu, 14 May 2009 11:45:57 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 11:08:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2009 11:08:19 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C01134406@esealmw109.eemea.ericsson.se> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments Thread-Index: AcnTCvAMTR0KeykKRQi5j3pvrIFBFAAyIpZ1ACdvMBA= References: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se> <4A098277.9020301@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> From: "Ingemar Johansson S" To: , X-OriginalArrivalTime: 14 May 2009 09:08:20.0481 (UTC) FILETIME=[86CEFF10:01C9D473] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 11:48:15 -0000 Hi Comments inline=20 Regards Ingemar > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: den 13 maj 2009 17:58 > To: menth@informatik.uni-wuerzburg.de; Ingemar Johansson S > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-marking-behaviour-03.txt,=20 > some comments >=20 > ingemar, > i dont seem to have got your email, so sorry for what i dont answer! >=20 > ________________________________ >=20 > From: pcn-bounces@ietf.org on behalf of Michael Menth > Sent: Tue 12/05/2009 15:06 > To: Ingemar Johansson S > Cc: pcn@ietf.org > Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt,=20 > some comments >=20 >=20 >=20 > Hi Ingemar, hi Phil, >=20 > Ingemar Johansson S schrieb: > > Hi > > > > I have some comments on=20 > draft-ietf-pcn-marking-behaviour-03. I would=20 > > believe that all the comments are of the nit-picking kind=20 > also it has=20 > > been a few moons since I had time to delve into this area and I may=20 > > have missed something so I trust you to disagree where needed :-) > > > > Section 1, bullet 1 : "its objective is to mark all packets...". > > Is it necessary to have "all" in the sentence ?. > > As I see it it is likely that a token bucket will introduce=20 > a threshold marking pattern that is not a continuous=20 > threshold-mark for all packets, this mecause the bucket level=20 > may be either above or below the threshold when a packet=20 > arrives. The word "all" in the sentence gives me that all=20 > packets within some given time frame are marked and my=20 > understand that this is not the case (I believe). But perhaps=20 > I am over-interpreting the statement ?. >=20 >=20 > [phil] correct, it doesnt latch into a state where every pkt=20 > is marked for N secs regardless of the state of the token=20 > bucket. i think by "all" it was trying to contrast with the=20 > excess marking, where some pkts are always unmarked (up to=20 > the excess-traffic-rate). hopefully when it gets to teh=20 > formal description of the metering behaviour this is clear,=20 > i'll look how to improve the Intro text (maybe just deleting=20 > 'all' is enough] [Ingemar] Now I understand the intention, I don't have any strong = opinion on this, if nobody else has problems with this statment it is = probably Ok >=20 >=20 > > Section 2.4, bullet 1 : Is it possible to make a reference=20 > to the motivation behind this in B.6 ? >=20 > [phil] - it is! para 4, "This avoids over- > termination (with some edge behaviours) in the event that the PCN- > traffic passes through multiple bottlenecks in the PCN-domain > [I-D.charny-pcn-comparison=20 > 20draft-ietf-pcn-marking-behaviour-03.txt,%20some%20comments.E > ML/1_text.htm#ref-I-D.charny-pcn-comparison> ]. " [Ingemar] OK, sorry will read with the glasses on next time :-) >=20 >=20 > > > > Section 2.4, MTU : As a reader I get a bit confused here.=20 > My (application view) interpretation of MTU is the maximum=20 > allowed packet size that is discovered by an endpoint (is=20 > this refered to as path-MTU ?). In this context however I=20 > believe it is the maximum experienced packet size on the link. > > =20 > Phil, packet-size-independent marking can be achieved for=20 > excess marking simply by letting the token bucket counter=20 > become negative. When the counter is larger than zero, the=20 > packet is not marked, otherwise it is marked. This eliminates=20 > unclarities about MTUs and simplifies configuration. >=20 >=20 > [phil] ingemar, you're right. i'll get rid of the MTU term=20 > which is adding only unclearness.=20 [Ingemar] OK, maybe good it it is possible and does not cause any other = problems >=20 > [phil] michael, true, that seems to be a way of implementing=20 > it (btw what do you do if another pkt arrives whilst TB is=20 > negative? - dont think paper mentions this). i'm not sure=20 > it's the best way here, which is description to make clear=20 > the objective /behaviour of the metering, without implying a=20 > particualr implementation.=20 >=20 > > Section B.1, Competing-non-PCN-traffic: "In such cases=20 > PCN-traffic and competing-non-PCN-traffic are distinguished=20 > by different values of the ECN field [I-D.ietf-pcn-baseline-encoding]" > > I would suggest that the sentence is slightly rewritten=20 > as "In such=20 > > cases, and if baseline encoding=20 > [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and=20 > competing-non-PCN-traffic are distinguished by different=20 > values of the ECN field" > > The reason is that it may not be possible to do this=20 > distinction with other encoding schemas. > > =20 > I believe that any encoding for PCN traffic needs to make=20 > sure that PCN traffic can be differentiated from non-PCN=20 > traffic. I do not think that we need to make this statement=20 > depending on any encoding scheme. >=20 >=20 > [phil] ingemar, this really comes out of the disussions about=20 > encoding, and how baseline & future extensions relate to each=20 > other - and as michael says, way of distinguishing pcn &=20 > competing-non-pcn traffic in way that doesnt depend on the=20 > coding scheme. anyway, to shift the discussion onto the=20 > encoding draft! - i just copied what the baseline encoding=20 > says. It defines (S5) "Rules for Experimental Encoding Schemes": >=20 > o The 00 codepoint in the ECN field SHALL indicate=20 > not-PCN and MUST > NOT be changed to any otehr codepoint within a PCN-domain. > Therefore an ingress node wishing to disable PCN marking for a > packet within a PCN-compatible DiffServ Codepoint MUST=20 > set the ECN > field to 00. > i guess your idea is that with some exptal encoding (you=20 > have in mind?) the pcn & competing-non-pcn traffic might be=20 > differentiated by something other than the ecn field? (maybe=20 > dscp??) perhaps some other verb than "are distinguished"=20 > would be better (which perhaps implies a method ratehr than a=20 > potential method?) (maybe re-phrase as: "they differ in their=20 > values of the ECN field"?). sory if i don't get your point proprely [Ingemar] It is possible that this is not an issue. My concern is around = the support for e2e ECN semantics implemented with the help of extra = DSCP. In this case the ECN info at the PCN-ingress is carried by a = combination of ECN and DSCP to the PCN egrees. Is it possible to = distinguish between PCN and competing-non-PCN in such cases ? >=20 > thanks >=20 > phil > Regards, >=20 > Michael >=20 >=20 > > > > Regards > > Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > =20 >=20 > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am=20 > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/31-86644 (new), fax: (+49)-931/8888-6632=20 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn >=20 >=20 >=20 From toby.moncaster@bt.com Thu May 14 05:48:35 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 885463A6A39 for ; Thu, 14 May 2009 05:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvFerwUT0GDH for ; Thu, 14 May 2009 05:48:34 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 89CDF3A687B for ; Thu, 14 May 2009 05:48:33 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 13:50:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2009 13:49:39 +0100 Message-ID: In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C01134406@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments Thread-Index: AcnTCvAMTR0KeykKRQi5j3pvrIFBFAAyIpZ1ACdvMBAACB2nUA== References: <130EBB38279E9847BAAAE0B8F9905F8C010D1CA1@esealmw109.eemea.ericsson.se><4A098277.9020301@informatik.uni-wuerzburg.de><4A916DBC72536E419A0BD955EDECEDEC044411A1@E03MVB1-UKBR.domain1.systemhost.net> <130EBB38279E9847BAAAE0B8F9905F8C01134406@esealmw109.eemea.ericsson.se> From: To: , , X-OriginalArrivalTime: 14 May 2009 12:50:02.0809 (UTC) FILETIME=[7F9D2A90:01C9D492] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 12:48:35 -0000 One comment inline Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Ingemar Johansson S > Sent: 14 May 2009 10:08 > To: Eardley,PL,Philip,CXR9 R; menth@informatik.uni-wuerzburg.de > Cc: Ingemar Johansson S; pcn@ietf.org > Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some > comments >=20 > Hi >=20 > Comments inline >=20 > Regards > Ingemar >=20 > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: den 13 maj 2009 17:58 > > To: menth@informatik.uni-wuerzburg.de; Ingemar Johansson S > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, > > some comments > > > > ingemar, > > i dont seem to have got your email, so sorry for what i dont answer! > > > > ________________________________ > > > > From: pcn-bounces@ietf.org on behalf of Michael Menth > > Sent: Tue 12/05/2009 15:06 > > To: Ingemar Johansson S > > Cc: pcn@ietf.org > > Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, > > some comments > > > > > > > > Hi Ingemar, hi Phil, > > > > Ingemar Johansson S schrieb: > > > Hi > > > > > > I have some comments on > > draft-ietf-pcn-marking-behaviour-03. I would > > > believe that all the comments are of the nit-picking kind > > also it has > > > been a few moons since I had time to delve into this area and I = may > > > have missed something so I trust you to disagree where needed :-) > > > > > > Section 1, bullet 1 : "its objective is to mark all packets...". > > > Is it necessary to have "all" in the sentence ?. > > > As I see it it is likely that a token bucket will introduce > > a threshold marking pattern that is not a continuous > > threshold-mark for all packets, this mecause the bucket level > > may be either above or below the threshold when a packet > > arrives. The word "all" in the sentence gives me that all > > packets within some given time frame are marked and my > > understand that this is not the case (I believe). But perhaps > > I am over-interpreting the statement ?. > > > > > > [phil] correct, it doesnt latch into a state where every pkt > > is marked for N secs regardless of the state of the token > > bucket. i think by "all" it was trying to contrast with the > > excess marking, where some pkts are always unmarked (up to > > the excess-traffic-rate). hopefully when it gets to teh > > formal description of the metering behaviour this is clear, > > i'll look how to improve the Intro text (maybe just deleting > > 'all' is enough] > [Ingemar] Now I understand the intention, I don't have any strong > opinion on this, if nobody else has problems with this statment it is > probably Ok >=20 > > > > > > > Section 2.4, bullet 1 : Is it possible to make a reference > > to the motivation behind this in B.6 ? > > > > [phil] - it is! para 4, "This avoids over- > > termination (with some edge behaviours) in the event that the = PCN- > > traffic passes through multiple bottlenecks in the PCN-domain > > [I-D.charny-pcn-comparison > > > 20draft-ietf-pcn-marking-behaviour-03.txt,%20some%20comments.E > > ML/1_text.htm#ref-I-D.charny-pcn-comparison> ]. " > [Ingemar] OK, sorry will read with the glasses on next time :-) >=20 > > > > > > > > > > Section 2.4, MTU : As a reader I get a bit confused here. > > My (application view) interpretation of MTU is the maximum > > allowed packet size that is discovered by an endpoint (is > > this refered to as path-MTU ?). In this context however I > > believe it is the maximum experienced packet size on the link. > > > > > Phil, packet-size-independent marking can be achieved for > > excess marking simply by letting the token bucket counter > > become negative. When the counter is larger than zero, the > > packet is not marked, otherwise it is marked. This eliminates > > unclarities about MTUs and simplifies configuration. > > > > > > [phil] ingemar, you're right. i'll get rid of the MTU term > > which is adding only unclearness. > [Ingemar] OK, maybe good it it is possible and does not cause any = other > problems >=20 > > > > [phil] michael, true, that seems to be a way of implementing > > it (btw what do you do if another pkt arrives whilst TB is > > negative? - dont think paper mentions this). i'm not sure > > it's the best way here, which is description to make clear > > the objective /behaviour of the metering, without implying a > > particualr implementation. > > > > > Section B.1, Competing-non-PCN-traffic: "In such cases > > PCN-traffic and competing-non-PCN-traffic are distinguished > > by different values of the ECN field [I-D.ietf-pcn-baseline- > encoding]" > > > I would suggest that the sentence is slightly rewritten > > as "In such > > > cases, and if baseline encoding > > [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and > > competing-non-PCN-traffic are distinguished by different > > values of the ECN field" > > > The reason is that it may not be possible to do this > > distinction with other encoding schemas. > > > > > I believe that any encoding for PCN traffic needs to make > > sure that PCN traffic can be differentiated from non-PCN > > traffic. I do not think that we need to make this statement > > depending on any encoding scheme. > > > > > > [phil] ingemar, this really comes out of the disussions about > > encoding, and how baseline & future extensions relate to each > > other - and as michael says, way of distinguishing pcn & > > competing-non-pcn traffic in way that doesnt depend on the > > coding scheme. anyway, to shift the discussion onto the > > encoding draft! - i just copied what the baseline encoding > > says. It defines (S5) "Rules for Experimental Encoding Schemes": > > > > o The 00 codepoint in the ECN field SHALL indicate > > not-PCN and MUST > > NOT be changed to any otehr codepoint within a PCN-domain. > > Therefore an ingress node wishing to disable PCN marking for a > > packet within a PCN-compatible DiffServ Codepoint MUST > > set the ECN > > field to 00. > > i guess your idea is that with some exptal encoding (you > > have in mind?) the pcn & competing-non-pcn traffic might be > > differentiated by something other than the ecn field? (maybe > > dscp??) perhaps some other verb than "are distinguished" > > would be better (which perhaps implies a method ratehr than a > > potential method?) (maybe re-phrase as: "they differ in their > > values of the ECN field"?). sory if i don't get your point proprely > [Ingemar] It is possible that this is not an issue. My concern is > around the support for e2e ECN semantics implemented with the help of > extra DSCP. In this case the ECN info at the PCN-ingress is carried by > a combination of ECN and DSCP to the PCN egrees. Is it possible to > distinguish between PCN and competing-non-PCN in such cases ? >=20 [Toby] Yes, I think e2e ECN can be supported using the 3 state encoding = scheme. If you look at draft-ietf-3-state-encoding-00 it will hopefully = be clear.=20 > > > > thanks > > > > phil > > Regards, > > > > Michael > > > > > > > > > > Regards > > > Ingemar > > > ******************************************* > > > Ingemar Johansson > > > Senior Research Engineer, IETF "nethead" > > > EAB/TVP - Multimedia Technologies > > > Ericsson Research Ericsson AB > > > Box 920 S-971 28 Lule=E5, Sweden > > > Tel: +46 (0)10 7143042 > > > ECN: 852-43042 > > > ECC: 852-19042 > > > Mobile: +46 (0)730 783289 > > > Visit http://labs.ericsson.com ! > > > ******************************************* > > > _______________________________________________ > > > 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/8888-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 toby.moncaster@bt.com Mon May 18 08:20: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 75E033A6E08 for ; Mon, 18 May 2009 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1cUhpYbJ3zl for ; Mon, 18 May 2009 08:20:17 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 157A33A6EF1 for ; Mon, 18 May 2009 08:20:16 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:21:51 +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: Mon, 18 May 2009 16:22:10 +0100 Message-ID: In-Reply-To: <1242244511.3782.22.camel@ecliptic.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt Thread-Index: AcnUBLx87WarBonAR6OIDKQGgay1QwDxkCiA References: <1242242396.3782.19.camel@ecliptic.corp.extremenetworks.com> <1242244511.3782.22.camel@ecliptic.corp.extremenetworks.com> From: To: X-OriginalArrivalTime: 18 May 2009 15:21:51.0731 (UTC) FILETIME=[5E9B5C30:01C9D7CC] Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Mon, 18 May 2009 15:20:24 -0000 All, I'm trying to address various WGLC comments I've received from Gorry and Phil to do with baseline encoding. One comment that Gorry had relates to the choice of DSCP and whether these need to be standardised. I think our discussions led to the conclusion that we would rather wait till we see whether PCN is successful before we try and get a standards DSCP out of IANA and meantime will have PCN as an optional behaviour that can be turned on within a controlled domain. However this leads to a question of inter-operability between different vendors (a requirement for standards track protocols I believe). My suggestion is that we (PCN WG) maintain a list of the DSCPs different vendors have designated as PCN-compatible (just as we are going to maintain a list of the experimental DSCPs for the experimental extensions). We also need to address another concern - will we need to notify IANA that we are proposing a new marking behaviour that can be applied to certain "appropriate" DSCPs. Should we in fact as a WG define the set of existing DSCPs that we believe can use PCN? This moves well outside my area of expertise so I would welcome an answer from a DiffServ expert. Currently I am proposing making the IANA considerations section read: "This document makes no direct request to IANA. However this document allows for a set of DiffServ Codepoints to be assigned different ECN semantics within a controlled domain as described in RFC4774. A list of such DSCPs will be maintained by the PCN working group." Would this be sufficient or do we need to be more precise? For instance should we define that only those DSCPs for real-time traffic are suitable, or those for admission controlled traffic, or what? Toby From Ruediger.Geib@telekom.de Mon May 18 23:41:37 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DFD3A6948 for ; Mon, 18 May 2009 23:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-4lzuExdJxO for ; Mon, 18 May 2009 23:41:36 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id E931A3A6929 for ; Mon, 18 May 2009 23:41:35 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 19 May 2009 08:43:07 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 08:42:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 08:42:51 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5013BDD2A@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt Thread-Index: AcnUBLx87WarBonAR6OIDKQGgay1QwDxkCiAACBeXrA= References: <1242242396.3782.19.camel@ecliptic.corp.extremenetworks.com><1242244511.3782.22.camel@ecliptic.corp.extremenetworks.com> From: To: X-OriginalArrivalTime: 19 May 2009 06:42:53.0888 (UTC) FILETIME=[096B5400:01C9D84D] Cc: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Tue, 19 May 2009 06:41:37 -0000 Toby, to me your proposal to stay experimental is sound, but also the=20 argument to have certain reserved DSCP values for PCN experiments=20 is a good one.=20 Maybe the chairs could provide some guidance on the best way to=20 proceed?=20 Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Monday, May 18, 2009 5:22 PM To: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt All, I'm trying to address various WGLC comments I've received from Gorry and Phil to do with baseline encoding. One comment that Gorry had relates to the choice of DSCP and whether these need to be standardised. I think our discussions led to the conclusion that we would rather wait till we see whether PCN is successful before we try and get a standards DSCP out of IANA and meantime will have PCN as an optional behaviour that can be turned on within a controlled domain. However this leads to a question of inter-operability between different vendors (a requirement for standards track protocols I believe). My suggestion is that we (PCN WG) maintain a list of the DSCPs different vendors have designated as PCN-compatible (just as we are going to maintain a list of the experimental DSCPs for the experimental extensions). We also need to address another concern - will we need to notify IANA that we are proposing a new marking behaviour that can be applied to certain "appropriate" DSCPs. Should we in fact as a WG define the set of existing DSCPs that we believe can use PCN? This moves well outside my area of expertise so I would welcome an answer from a DiffServ expert. Currently I am proposing making the IANA considerations section read: "This document makes no direct request to IANA. However this document allows for a set of DiffServ Codepoints to be assigned different ECN semantics within a controlled domain as described in RFC4774. A list of such DSCPs will be maintained by the PCN working group." Would this be sufficient or do we need to be more precise? For instance should we define that only those DSCPs for real-time traffic are suitable, or those for admission controlled traffic, or what? Toby _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From slblake@petri-meat.com Tue May 19 05:26:16 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85C53A6D13 for ; Tue, 19 May 2009 05:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ihOnk+1+jg for ; Tue, 19 May 2009 05:26:16 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id B43E53A6DAB for ; Tue, 19 May 2009 05:26:02 -0700 (PDT) Received: from cpe-066-057-118-226.nc.res.rr.com ([66.57.118.226]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1M6OPu-0003kF-K0; Tue, 19 May 2009 08:27:34 -0400 From: Steven Blake To: Ruediger.Geib@telekom.de In-Reply-To: <151C164FE2E066418D8D44D0801543A5013BDD2A@S4DE8PSAAQA.mitte.t-com.de> References: <1242242396.3782.19.camel@ecliptic.corp.extremenetworks.com> <1242244511.3782.22.camel@ecliptic.corp.extremenetworks.com> <151C164FE2E066418D8D44D0801543A5013BDD2A@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain Date: Tue, 19 May 2009 08:27:34 -0400 Message-Id: <1242736054.6532.17.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Tue, 19 May 2009 12:26:17 -0000 On Tue, 2009-05-19 at 08:42 +0200, Ruediger.Geib@telekom.de wrote: > Toby, > > to me your proposal to stay experimental is sound, but also the > argument to have certain reserved DSCP values for PCN experiments > is a good one. > > Maybe the chairs could provide some guidance on the best way to > proceed? I expect that getting one or more Pool 1 (standards-action) DSCP values assigned to PCN at this stage would be highly unlikely to happen. So as mentioned before, we can choose some Pool 2/3 (experimental/local use) values for experimentation and announce them to the world. There may be some value in recommending certain "appropriate" DSCPs for use by flows/applications that can/should receive PCN treatment. On the other hand, we assume flow classification at the edges, so it might not help that much. Regards, // Steve From toby.moncaster@bt.com Tue May 19 07:53:35 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 9F3503A6AB7 for ; Tue, 19 May 2009 07:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSxgk1+xZjvH for ; Tue, 19 May 2009 07:53:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A20D23A6A93 for ; Tue, 19 May 2009 07:53:34 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 15:55:10 +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, 19 May 2009 15:55:02 +0100 Message-ID: In-Reply-To: <1242736054.6532.17.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt Thread-Index: AcnYfTZktiqjgvaqSW6nbqVn/OzZkQAFGK+Q References: <1242242396.3782.19.camel@ecliptic.corp.extremenetworks.com> <1242244511.3782.22.camel@ecliptic.corp.extremenetworks.com> <151C164FE2E066418D8D44D0801543A5013BDD2A@S4DE8PSAAQA.mitte.t-com.de> <1242736054.6532.17.camel@tachyon> From: To: , X-OriginalArrivalTime: 19 May 2009 14:55:10.0383 (UTC) FILETIME=[CE8ACBF0:01C9D891] Cc: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Tue, 19 May 2009 14:53:35 -0000 I will post a revised document probably tomorrow morning. Hopefully it will suitably address this point as well as the other WGLC points that have been raised. Toby > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: 19 May 2009 13:28 > To: Ruediger.Geib@telekom.de > Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt >=20 > On Tue, 2009-05-19 at 08:42 +0200, Ruediger.Geib@telekom.de wrote: >=20 > > Toby, > > > > to me your proposal to stay experimental is sound, but also the > > argument to have certain reserved DSCP values for PCN experiments > > is a good one. > > > > Maybe the chairs could provide some guidance on the best way to > > proceed? >=20 > I expect that getting one or more Pool 1 (standards-action) DSCP values > assigned to PCN at this stage would be highly unlikely to happen. So > as > mentioned before, we can choose some Pool 2/3 (experimental/local use) > values for experimentation and announce them to the world. >=20 > There may be some value in recommending certain "appropriate" DSCPs for > use by flows/applications that can/should receive PCN treatment. On > the > other hand, we assume flow classification at the edges, so it might not > help that much. >=20 >=20 > Regards, >=20 > // Steve From root@core3.amsl.com Wed May 20 03: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 125753A6CA7; Wed, 20 May 2009 03: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: <20090520103002.125753A6CA7@core3.amsl.com> Date: Wed, 20 May 2009 03:30:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-04.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: Wed, 20 May 2009 10: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-04.txt Pages : 13 Date : 2009-05-20 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 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-20032052.I-D@ietf.org> --NextPart-- From toby.moncaster@bt.com Wed May 20 03:39:02 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2917D3A6C10 for ; Wed, 20 May 2009 03:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffk-D3NIshQA for ; Wed, 20 May 2009 03:39:01 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 130A13A6883 for ; Wed, 20 May 2009 03:39:00 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 11:40:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 11:40:34 +0100 Message-ID: In-Reply-To: <20090520103002.125753A6CA7@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-04.txt Thread-Index: AcnZNjcBfDEOa8mKS1q6j8dXgem0iAAAKORQ References: <20090520103002.125753A6CA7@core3.amsl.com> From: To: X-OriginalArrivalTime: 20 May 2009 10:40:37.0302 (UTC) FILETIME=[697D5560:01C9D937] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-04.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: Wed, 20 May 2009 10:39:02 -0000 All, I think this revision addresses most of the comments received during the WGLC. The significant changes are a new sub-section clarifying why we have a not-PCN state, a number of mentions that the WG will maintain a list of PCN-compatible DSCPs and some clarifications about end-to-end ECN and tunnelling. I also clarified the valid state transitions bit in 4.1 as requested by Phil... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 20 May 2009 11:30 > To: i-d-announce@ietf.org > Cc: pcn@ietf.org > Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-04.txt >=20 > 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. >=20 >=20 > Title : Baseline Encoding and Transport of Pre- > Congestion Information > Author(s) : T. Moncaster, et al. > Filename : draft-ietf-pcn-baseline-encoding-04.txt > Pages : 13 > Date : 2009-05-20 >=20 > 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 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding- > 04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From sob@harvard.edu Thu May 21 17:22:00 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4FF3A6B9E for ; Thu, 21 May 2009 17:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj3lXmurgG+B for ; Thu, 21 May 2009 17:21:59 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 42D8B3A6928 for ; Thu, 21 May 2009 17:21:59 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 70B0E175296D; Thu, 21 May 2009 20:23:34 -0400 (EDT) To: pcn@ietf.org Message-Id: <20090522002334.70B0E175296D@newdev.eecs.harvard.edu> Date: Thu, 21 May 2009 20:23:34 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] pcn agenda topics for Stockholm 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, 22 May 2009 00:22:00 -0000 please send pcn agenda topics to the list tnx Scott & Steve From philip.eardley@bt.com Thu May 28 04:39:05 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61ED73A69CA for ; Thu, 28 May 2009 04:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR9pLgYbnS0n for ; Thu, 28 May 2009 04:39:00 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C81E33A6C90 for ; Thu, 28 May 2009 04:38:59 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 12:40:03 +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: Thu, 28 May 2009 12:40:19 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7C38@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1242736054.6532.17.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt Thread-Index: AcnYfVKr+cuSU+lzQx24aSO2010oWQHCrFPg From: To: , X-OriginalArrivalTime: 28 May 2009 11:40:03.0945 (UTC) FILETIME=[0AADDD90:01C9DF89] Cc: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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: , X-List-Received-Date: Thu, 28 May 2009 11:39:05 -0000 Exptal DSCP seems OK to me, due to practical issues of releasing stds dscps. I assume it's correct for the i-d to be stds track (it makes sense to me, as the draft is more than just a dscp) Also, my understanding is that the dscp assigned in draft-ietf-tsvwg-admitted-realtime-dscp is suitable for pcn (eg PCN meets the requirements of S2.2 Capacity admission control). Not sure of the progress of that doc though? Best wishes phil=20 { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Steven Blake { Sent: 19 May 2009 13:28 { To: Ruediger.Geib@telekom.de { Cc: pcn@ietf.org { Subject: Re: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-03.txt {=20 { On Tue, 2009-05-19 at 08:42 +0200, Ruediger.Geib@telekom.de wrote: {=20 { > Toby, { > { > to me your proposal to stay experimental is sound, but also the { > argument to have certain reserved DSCP values for PCN experiments { > is a good one. { > { > Maybe the chairs could provide some guidance on the best way to { > proceed? {=20 { I expect that getting one or more Pool 1 (standards-action) DSCP values { assigned to PCN at this stage would be highly unlikely to happen. So as { mentioned before, we can choose some Pool 2/3 (experimental/local use) { values for experimentation and announce them to the world. {=20 { There may be some value in recommending certain "appropriate" DSCPs for { use by flows/applications that can/should receive PCN treatment. On the { other hand, we assume flow classification at the edges, so it might not { help that much. {=20 {=20 { Regards, {=20 { // Steve {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn