Hi Phil,
Thanks for the comments. I will try and incorporate all of them into
the (hopefully) final version after the IETF LC ends in 2 weeks time.
More inline
> -----Original Message-----
> From: Eardley,PL,Philip,DER3 R
> Sent: 20 August 2009 17:37
> To: Moncaster,T,Toby,DER3 R; pcn at ietf.org; lars.eggert at nokia.com
> Subject: RE: [PCN] FW: New Version Notification fordraft-ietf-pcn-
> baseline-encoding-05
>
> Few minor comments:
>
> Table 1 has
> >EXP(01)*
> >Valid* [in IN EXP(01) OUT PM(11) box]
> > * This SHOULD cause an alarm to be raised at a higher layer. The
> packet MUST be treated as if it carried the NM codepoint.
>
> I think your comment ["*This SHOULD.."] really only applies to the
> "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as
> this shouldn't happen.
I think that is what I meant, yes. I will have a look at re-jigging
the table to clarify
>
> Both the "Valid" boxes in this row could have a comment:
> ** these transitions MAY be allowed be some future experimental
> extensions to the baseline encoding. However a PCN-node that hasn't be
> upgraded (ie is still doing baseline) mustn't block this so it MUST
> treat this transition as valid; it MAY also raise an alarm.
> [Not sure " MAY also raise an alarm" is needed, since alarm already
> raised since EXP(01) is the codepoint in]
Or something about "In order not to block future extensions from
using these transitions..."? I will try and sort something out
>
> > alarm to be raised at a higher layer
> is 'higher layer' right? how about "management alarm"?
Yep, by higher layer I meant control or management layer
>
>
> > A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
> packets it forwards out of the PCN-domain. The only exception to
> this is if the PCN-egress-node is certain that revealing other
> codepoints outside the PCN-domain won't contravene the guidance
> given
> in [RFC4774].
> I wonder if this needs a bit more explanation about how to do this, or
> where to find more guidance?
Would an example count as guidance? "For example where the
PCN-egress-node has been explicitly informed by the PCN-ingress-node
that this flow is ECN-capable" In terms of where to find guidance,
currently only in experimental schemes (I think)
>
> 4.3.1
> Co-existence of PCN and not-PCN traffic
> I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf-
> pcn-marking-behaviour Section B.1) which says
> >> It is not advised to have competing-non-PCN-traffic but, if there
> is such traffic, there needs to be a mechanism to limit it.
> "Competing-non-PCN-traffic" means traffic that shares a link with
> PCN-traffic and competes for its forwarding bandwidth. Hence,
> more competing-non-PCN-traffic results in poorer QoS for PCN.
> Further, the unpredictable amount of competing-non-PCN-traffic
> makes the PCN mechanisms less accurate and so reduces PCN's
> ability to protect the QoS of admitted PCN-flows.
>
Yep, will do
> 5
> > The 11 codepoint in the ECN field MUST indicate PCN-marked (though
> this does not exclude the 01 Experimental codepoint from carrying
> the same meaning).
> I think better would be " Experimental codepoint from also indicating
> PCN-marking" [it would indicate a 2nd level of pcn-marking, which you
> could say is not the "same" meaning]
But I define PCN-marked as having the meaning "...codepoint
indicating packets that have been marked at a PCN-interior-node
using some PCN marking behaviour..." Which is the same regardless of
the relative level of each of those marks! However I am happy to be
explicit and say EXP is not excluded from meaning PCN-marked
>
> A.1
> The approach & wording is basically good.
> >In PCN-domains with uniformly high link rates, the
> appropriate DSCPs would currently be those for the Real Time Traffic
> Class [RFC5127]. To be clear the PCN Working Group recommends using
> admission control for the following service classes:
>
> o Telephony (EF)
>
> o Real-time interactive (CS4)
>
> o Broadcast Video (CS3)
>
> o Multimedia Conferencing (AF4)
>
> I think "sufficient aggregation" would be better than "uniformly high
> link rates" [similarly, "sufficiently" not "highly" in the next para]
Yep
> " Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at
> least in Fig 2
> you might want to say why CS5 is excluded from pcn (all the other dscps
> in the RT treatement aggregate are included]
> rfc4594 needed as a ref somewhere here as that defines these dscps
Will just put "CS5 is excluded since PCN is not expected to be
applied to signalling traffic". However that does raise an
interesting question with regards to Michael's proposed approach of
using admission marking on RSVP PATH messages in PSDM as I would
count those as signalling traffic?
>
>
> Typos etc
> Abstract
> >This document specifies how such marks are to be encoded
> delete 'to be'
OK
>
> 4.0 >implementiors
Already spotted...
>
> 4.2
> > There are a number of factors that
> were considered before choosing to set 10
> could have a new paragraph before this
>
OK
> 4.3.0
> > Thirdly PCN
> should be seen as being essentially a marking behaviour similar to
> ECN but intended for inelastic traffic.
> Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it
> should be seen as being essentially a marking behaviour similar to ECN
> but intended for inelastic traffic.
>
OK
> 6
> > in decapsulation
> 'upon' better?
>
Will decide
> 6
> > If an
> operator wishes to allow ECN to exist end-to-end they must ensure
> there are no tunnel end-points within the PCN-domain to prevent any
> risk of PCN-markings being exposed to endpoints.
> Earlier in the paragraph you talk about a tunnel across the pcn-domain
> - then there might be another tunnel wholly within the pcn-domain, and
> this would be ok. (I know what you mean - perhaps slight re-ordering of
> the para would do the trick)
Will have a think about whether I can word this any better...
>
> A.1
> >PCn region
> PCN-domain
>
Oops!
> Thanks
> phil
>
> { -----Original Message-----
> { From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
> { toby.moncaster at bt.com
> { Sent: 20 August 2009 16:19
> { To: pcn at ietf.org; lars.eggert at nokia.com
> { Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-
> baseline-
> { encoding-05
> {
> { I hope this accurately reflects the ML discussions over the past few
> days?
> { I have also corrected all the nits and hopefully haven't left any
> spelling
> { mistakes or typos...
> {
> { Toby
> {
> { ____________________________________________________________________
> { Toby Moncaster, <toby.moncaster at bt.com> Networks Research Centre, BT
> { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170
> {
> {
> {
> { -----Original Message-----
> { From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
> { Sent: 20 August 2009 16:17
> { To: Moncaster,T,Toby,DER3 R
> { Cc: Briscoe,RJ,Bob,DER3 R; menth at informatik.uni-wuerzburg.de
> { Subject: New Version Notification for draft-ietf-pcn-baseline-
> encoding-05
> {
> {
> { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has
> been
> { successfuly submitted by T Moncaster and posted to the IETF
> repository.
> {
> { Filename: draft-ietf-pcn-baseline-encoding
> { Revision: 05
> { Title: Baseline Encoding and Transport of Pre-Congestion
> { Information
> { Creation_date: 2009-08-20
> { WG ID: pcn
> { Number_of_pages: 14
> {
> { Abstract:
> { 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.
> {
> {
> {
> { The IETF Secretariat.
> {
> {
> { _______________________________________________
> { PCN mailing list
> { PCN at ietf.org
> { https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn