[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05
Thanks, I will add these to the other corrections/comments...
1 inline response
> -----Original Message-----
> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 21 August 2009 11:45
> To: Moncaster,T,Toby,DER3 R; Eardley,PL,Philip,DER3 R; pcn at ietf.org;
> lars.eggert at nokia.com
> Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-
> baseline-encoding-05
>
> Toby,
>
> I just re-reviewed -05 as a whole and my list of comments included
> every single one of Phil's comments (even tho I hadn't read his email
> first).
>
> == S.4.1. para 2 ==
> " The only valid codepoint transitions within a PCN-interior-node are
> ... and from EXP to
> PM (which MAY be allowed by some future experimental extensions)."
>
> Delete parenthesis and add:
>
> PCN nodes that only implement the baseline encoding MUST be able to
> PCN mark packets that arrive with the EXP codepoint. This should ease
> the design of experimental schemes that want to allow partial
> deployment of experimental nodes alongside nodes that only implement
> the baseline encoding.
>
> The codepoint transition constraints given here apply only to the
> baseline encoding scheme. Constraints on codepoint transitions for
> future experimental scheme are discussed in S.5.
>
> == Table 2. ==
> s/* This SHOULD cause an alarm/
> /* This MAY cause an alarm/
>
> == S.6. last sentence ==
> " 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.
> "
> Rather than ruling out tunnel endpoints, I suggest you refer to the
> tunnel guidelines in RFC5559, which lays down the conditions under
> which tunnel endpoints can be used (i.e. the tunnel endpoint must act
> as an appropriate PCN edge node).
>
> Nits:
> == S.4.3 last line ==
> s/appendix Appendix/Appendix/
>
> == S.5. ==
> s/a packet within a PCN-compatible Diffserv Codepoint
> /a packet with a PCN-compatible Diffserv Codepoint/
>
> === 5th bullet ===
> " o Any experimental scheme MUST NOT update the meaning of the 00
and
> 11 codepoints defined above.
> "
> Same problem here as Phil pointed out for the 2nd bullet. An
> experimental scheme will probably refine the meaning of the 11
> codepoint (which would update the meaning contrary to the literal
> interpretation of this rule).
My response here is the same as my response to Phil's comment - this
document defines 11 as meaning PCN-marked. PCN-marked is defined as
having been marked as a result of a PCN-marking function - it doesn't
specify which sort of mark this is. In the context of the baseline
encoding, any experimental scheme also needs to ensure that 11 means
PCN-marked...
>
> == S.6. ==
> s/Standard IP-in-IP or IPsec tunnels/
> /RFC3168 IP-in-IP or RFC4301 IPsec tunnels/
> == S.8. 1st para ==
>
> " PCN-marking only carries a meaning within the confines of a PCN-
> domain. Packets wishing to be treated as belonging to a PCN-flow
> must carry a PCN-compatible DSCP and a PCN-Enabled ECN codepoint.
> This encoding document is intended to stand independently of the
> architecture used to determine how specific packets are authorised
> to
> be PCN-marked, which will be described in separate documents on
> PCN-
> boundary-node behaviour.
> "
> Delete the middle (2nd) sentence, which could be read as implying
> that packets arriving at the PCN ingress have to already carry a
> PCN-compatible DSCP and a PCN-Enabled ECN codepoint.
>
> == Repetitions that read OK, but may not have been intended ==
>
> 2nd sentence of S.4.1. repeats the last bullet of the preceding
> section (but they are both relevant in their respective sections).
>
> Opening sentences of A.1 repeat 3rd para of S.4.3.
>
>
> HTH
>
>
> Bob
>
>
> At 09:24 21/08/2009, toby.moncaster at bt.com wrote:
> >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