Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05

From: <[email-masked]>
Date: Tue, 1 Sep 2009 16:21:54 +0100

I see there has been a lot of on & off list discussion about Spencer's
first comment (ie the abstract uses Diffserv domain, not PCN-domain). I
wasn't able to read all the discussion because it has grown to 35 pages
(!!!!) 

I guess I disagree with Spencer's comment.  my view is that the general
reader is more likely to know what a Diffserv domain is, so that's a
better term to use in the abstract. (if the reader wants to understand
exactly what a PCN-domain is then they read further). But if insisted
on, the easy solution is just to add "called a PCN-domain" after
"Diffserv domain". Problem solved.

I disagree with the direction that the revised abstract has been going.
It seems to be trying to write a (longish) paragraph summary of what PCN
is. I think that is not needed & in fact is quite a bad idea - it's a
job for the introduction. I think the abstract should just say what the
Baseline encoding is about. However, I think it's probably ok to start
with one sentence about the objective of PCN, or a reference to rfc5559.

However, I think it might be worth adding to the abstract to explain why
this is called the "baseline" encoding, ie there are other encodings
building on this one that differentiate two severity levels of
PCN-marking. In fact, allowing (/ constraining) encoding extensions is
an important part of the baseline doc.

My suggested abstract is {..optional text..}:-

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain
{called a PCN-domain}.
Within the {PCN-}domain, PCN-nodes mark PCN-packets if the rate of
PCN-traffic is too high {as defined in [ref marking behaviour]}. This
document defines how such marks are encoded in the IP header for a
'baseline' encoding that provides for two PCN encoding states
(not-marked and PCN-marked). It reuses the ECN codepoint. Other
encodings can build on this baseline encoding to provide more than two
encoding states, in order to distinguish two severity levels of
PCN-marking. 

Toby, I'll leave it to you to decide what you want to do with my
comments, as I think there's been plenty enough suggestions already.

Best wishes,
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars
{ Eggert
{ Sent: 25 August 2009 15:12
{ To: [email-masked]
{ Subject: [PCN] Fwd: [Gen-art] Gen-ART Review
ofdraft-ietf-pcn-baseline-
{ encoding-05
{ 
{ 
{ 
{ Begin forwarded message:
{ 
{ > From: Spencer Dawkins <[email-masked]>
{ > Date: August 25, 2009 14:47:49 GMT+02:00
{ > To: "[email-masked]"
<draft-ietf-
{ [email-masked]
{ > >
{ > Cc: General Area Review Team <[email-masked]>,
"[email-masked]
{ > " 	<[email-masked]>
{ > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-
{ > encoding-05
{ >
{ > I have been selected as the General Area Review Team (Gen-ART)
{ > reviewer for
{ > this draft (for background on Gen-ART, please see
{ > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
{ >
{ > Please wait for direction from your document shepherd or AD before
{ > posting a
{ > new version of the draft.
{ >
{ > Document: draft-ietf-pcn-baseline-encoding-05
{ > Reviewer: Spencer Dawkins
{ > IETF LC End Date: 2009-09-03
{ > Review Date: 2009-08-21
{ > IESG Telechat date: (not known)
{ >
{ > Summary: this specification is almost ready for publication as a
{ > Proposed
{ > Standard. I have one minor question below (flagged as "Spencer
{ > (minor)"),
{ > along with some editorial suggestions to be considered when this
{ > document is
{ > edited (either in the working group or by the RFC Editor).
{ >
{ > Abstract
{ >
{ >   The objective of Pre-Congestion Notification (PCN) is to protect
the
{ >   quality of service (QoS) of inelastic flows within a Diffserv
{ > domain.
{ >
{ > Spencer (clarity): I'm not sure what the relationship between a
{ > Diffserv
{ > domain and a PCN-domain is - this couuld be clearer, especially in
an
{ > Abstract. I note that RFC 5559 doesn't use the term PCN-domain in
its
{ > Abstract ... I can guess, but I'm just guessing.
{ >
{ >   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.
{ >
{ > 4.  Encoding two PCN States in IP
{ >
{ >   The following rules apply to all PCN traffic:
{ >
{ >   o  PCN-traffic MUST be marked with a PCN-compatible Diffserv
{ >      Codepoint.  To conserve DSCPs, Diffserv Codepoints SHOULD be
{ >      chosen that are already defined for use with admission
controlled
{ >      traffic.  Appendix A.1 gives guidance to implementiors on
{ > suitable
{ >
{ > Spencer (clarity): s/implementiors/implementers/?
{ >
{ >      DSCPs.  Guidelines for mixing traffic-types within a PCN-domain
{ >      are given in [I-D.ietf-pcn-marking-behaviour].
{ >
{ >   o  Any packet that is not-PCN but which shares the same Diffserv
{ >      codepoint as PCN-enabled traffic MUST have the ECN field of its
{ >      outermost IP header equal to 00.
{ >
{ > Spencer (minor): this is the only point in the specification (that I
{ > can
{ > find) that makes reference to the "outermost IP header". I'm not
sure
{ > whether to suggest s/outermost// here or to ask that a statement be
{ > added
{ > earlier in the document to clearly state that PCN encoding only
{ > protects
{ > inelastic traffic when it's used for the outermost IP header, but
the
{ > current text seems to call attention to this in a way that makes the
{ > reader
{ > wonder what is special about THIS requirement that isn't true of the
{ > other
{ > requirements listed.
{ >
{ > 4.3.  PCN-Compatible Diffserv Codepoints
{ >
{ >   Enabling PCN marking behaviour for a specific DSCP disables any
{ > other
{ >   marking behaviour (e.g. enabling PCN disables the default ECN
{ > marking
{ >   behaviour introduced in [RFC3168]).  All traffic metering and
{ > marking
{ >
{ > Spencer (clarity): here, and in Section 6, the text uses "disables"
to
{ > describe the relationship between PCN and ECN. If I understand the
{ > point,
{ > the domain is substituting one behavior for another. I might suggest
{ > "replaces" to describe the relationship in both locations.
{ >
{ >   behaviours are discussed in [I-D.ietf-pcn-marking-behaviour].
This
{ >   ensures compliance with the BCP guidance set out in [RFC4774].
{ >
{ > 4.3.1.  Co-existence of PCN and not-PCN traffic
{ >
{ >   The scarcity of pool 1 DSCPs coupled with the fact that PCN is
{ >   envisaged as a marking behaviour that could be applied to a number
{ > of
{ >   different DSCPs makes it essential that we provide a not-PCN
state.
{ >   As stated above (and expanded in Appendix A.1) the aim is for PCN
to
{ >   re-use existing DSCPs.  Because PCN re-defines the meaning of the
{ > ECN
{ >
{ > Spencer (clarity): here, the text uses "re-defines", which I like
{ > better
{ > than "disables", but if you go for "replaces" previously and in
{ > section 6,
{ > you might want to use the same wording here.
{ >
{ >   field for such DSCPs it is important to allow an operator to still
{ >   use the DSCP for traffic that isn't PCN-enabled.  This is achieved
{ > by
{ >   providing a not-PCN state within the encoding scheme.
{ >
{ > A.1.  Choice of Suitable DSCPs
{ >
{ >   The PCN Working Group chose not to define a single DSCP for use
with
{ >   PCN for several reasons.  Firstly the PCN mechanism is applicable
to
{ >   a variety of different traffic classes.  Secondly standards track
{ >   DSCPs are in increasingly short supply.  Thirdly PCN should be
seen
{ >   as being essentially a marking behaviour similar to ECN but
intended
{ >   for inelastic traffic.  The choice of which DSCP is most suitable
{ > for
{ >   a given PCN-domain is dependent on the nature of the traffic
{ > entering
{ >   that domain and the link rates of all the links making up that
{ >   domain.  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
{ >
{ > Spencer (clarity): is this 2119 language (apparently not, since this
{ > section
{ > is not normative), or are you saying "suggests"? My suggestion is
{ > that we
{ > not use 2119 language, even lowercased, except for normative text -
{ > this
{ > seems to cause confusion from time to time. But please check with
your
{ > shepherding AD to see if he agrees.
{ >
{ >   admission control for the following service classes:
{ >
{ >   o  Telephony (EF)
{ >
{ >   o  Real-time interactive (CS4)
{ >
{ >   o  Broadcast Video (CS3)
{ >
{ >   o  Multimedia Conferencing (AF4)
{ >
{ > _______________________________________________
{ > Gen-art mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Fri, 4 Sep 2009 12:14:51 +0100

As the IETF LC has now finished with no further comments, I am in the
process of completing the revised draft for the IESG to approve.

I have decided that Phil has a sound point about the abstract - what we
had ended up with last week was effectively a complete introduction to
the PCN architecture as a whole. I have now crafted a final abstract for
people to see if they approve. I will actually submit the revised
version by 1600 GMT this afternoon so if people disagree they need to
shout quickly!

Before I give the abstract, a few words to explain where it is coming
from. I think the abstract for the baseline encoding needs to do the
following: introduce readers to PCN - by which I mean give them a hint
as to what field this is in, NOT describe PCN in detail...; Then
introduce PCN marking; then finally explain that this is the baseline
encoding for that marking...

   The pre-congestion notification (PCN) architecture is intended to 
   protect the QoS of inelastic flows within a DiffServ domain. In order
   to do this, packets belonging to PCN-flows are marked when the rate
   of traffic exceeds pre-configured thresholds on a link. These marks
   can then be evaluated to determine how close the domain is to being
   congested. This document specifies how such marks are encoded into 
   the IP header by redefining the Explicit Congestion Notification 
   (ECN) codepoints within such domains.  The baseline encoding 
   described here provides only two PCN encoding states: not-marked 
   and PCN-marked. Future extensions to this encoding may be needed to
   provide more than one level of marking severity.

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 01 September 2009 16:22
> To: [email-masked]
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Reviewofdraft-ietf-pcn-
> baseline-encoding-05
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 4 Sep 2009 14:11:14 +0100

Replying to my own email. On reading back what I wrote I actually think
it would sound better as:

   The objective of the pre-congestion notification (PCN) architecture 
   is to protect the QoS of inelastic flows within a DiffServ domain. It
   achieves this by marking packets belonging to PCN-flows when the rate
   of traffic exceeds certain configured thresholds on links in the 
   domain.  These marks can then be evaluated to determine how close the

   domain is to being congested.  This document specifies how such marks

   are encoded into the IP header by redefining the Explicit Congestion 
   Notification (ECN) codepoints within such domains.  The baseline 
   encoding described here provides only two PCN encoding states: 
   not-marked and PCN-marked. Future extensions to this encoding may be 
   needed in order to provide more than one level of marking severity.

As I said below this does 3 things: introduces the PCN architecture (if
someone has found this document they probably already know about that),
it explains what PCN-marks are and how they are generated and then it
explains how to encode these into the IP header. The final bit was as
suggested by Phil - we need to give a hint as to why this is a baseline
encoding...

Unless I get really strong pushback against this then I will run with it
when I release the update in the next couple of hours...

> [email-masked]
> Sent: 04 September 2009 12:15
> To: Eardley,PL,Philip,DER3 R; [email-masked]
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReviewofdraft-ietf-pcn-
> baseline-encoding-05
> 
> > first comment (ie the abstract uses Diffserv domain, not
PCN-domain).
> I
> > { >   boundary nodes to make decisions about whether to admit or
> block
> > a
> > { > Spencer (minor): this is the only point in the specification
> (that
> > I
> > { > can
> > { > not use 2119 language, even lowercased, except for normative
text
> -