Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05

[<[e-mail]>]

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; [e-mail];
> [e-mail]
> 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, [e-mail] 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; [e-mail]; [e-mail]
> > > 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of
> > > { [e-mail]
> > > { Sent: 20 August 2009 16:19
> > > { To: [e-mail]; [e-mail]
> > > { 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, <[e-mail]> Networks Research
Centre,
> BT
> > > { B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
> > > {
> > > {
> > > {
> > > { -----Original Message-----
> > > { From: IETF I-D Submission Tool [mailto:[e-mail]]
> > > { Sent: 20 August 2009 16:17
> > > { To: Moncaster,T,Toby,DER3 R
> > > { Cc: Briscoe,RJ,Bob,DER3 R; [e-mail]
> > > { 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
> > > { [e-mail]
> > > { https://www.ietf.org/mailman/listinfo/pcn
> >_______________________________________________
> >PCN mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/pcn