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

[Bob Briscoe <[e-mail]>]

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).

== 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