Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt

From: [email-masked]
Date: Thu, 5 Mar 2009 08:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : Marking behaviour of PCN-nodes
	Author(s)       : P. Eardley
	Filename        : draft-ietf-pcn-marking-behaviour-02.txt
	Pages           : 20
	Date            : 2009-03-05

This document standardises the two marking behaviours of PCN-nodes:
threshold marking and excess traffic marking.  Threshold marking
marks all PCN-packets if the PCN traffic rate is greater than a
configured rate ("PCN-threshold-rate").  Excess traffic marking marks
a proportion of PCN-packets, such that the amount marked equals the
traffic rate in excess of a configured rate ("PCN-excess-rate").
Setting the configured rates below the physical link rates enables
PCN-nodes to provide information to support admission control and
flow termination in order to protect the quality of service of
established inelastic flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 16:47:30 -0000

I updated the draft. 
http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-02.
txt 

6.1.  Changes to -02 from -01

   Updates as follows:

   o  added notes (end of S1.1 & 2.5) to clarify what "excess-traffic-
      marked" means when there is only one encoding for PCN-marking

   o  added explanations for in Section B.4 and B.6 about why various
      things are SHOULD or SHOULD NOT rather than MUST or MUST NOT.

   o  Deleted a couple of paragraphs about encoding states, as they are
      relevant to encoding documents rather than this document.

I also corrected the editorial nits the Ruediger pointed out. 

There is the on-going suggestion from Daisuke (currently writing an
email) - but apart from this issue I think that the document is done
(there have been no changes to normative text since the -00 version of
2nd Oct 2008).

Thanks
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 05 March 2009 16:15
{ To: [email-masked]
{ Cc: [email-masked]
{ Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt
{ 
{ A New Internet-Draft is available from the on-line Internet-Drafts
{ directories.
{ This draft is a work item of the Congestion and Pre-Congestion
{ Notification Working Group of the IETF.
{ 
{ 
{ 	Title           : Marking behaviour of PCN-nodes
{ 	Author(s)       : P. Eardley
{ 	Filename        : draft-ietf-pcn-marking-behaviour-02.txt
{ 	Pages           : 20
{ 	Date            : 2009-03-05
{ 
{ This document standardises the two marking behaviours of PCN-nodes:
{ threshold marking and excess traffic marking.  Threshold marking
{ marks all PCN-packets if the PCN traffic rate is greater than a
{ configured rate ("PCN-threshold-rate").  Excess traffic marking marks
{ a proportion of PCN-packets, such that the amount marked equals the
{ traffic rate in excess of a configured rate ("PCN-excess-rate").
{ Setting the configured rates below the physical link rates enables
{ PCN-nodes to provide information to support admission control and
{ flow termination in order to protect the quality of service of
{ established inelastic flows.
{ 
{ A URL for this Internet-Draft is:
{ http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-
{ 02.txt
{ 
{ Internet-Drafts are also available by anonymous FTP at:
{ ftp://ftp.ietf.org/internet-drafts/
{ 
{ Below is the data which will enable a MIME compliant mail reader
{ implementation to automatically retrieve the ASCII version of the
{ Internet-Draft.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 23 Mar 2009 23:52:38 +0000

Phil,

Review comments below. Nothing substantive, just editorial mostly.

Abstract:
s/standardises/specifies/ [I think the IESG objects to RFCs using the 
'standard' word]

1. Intro
s/Other documents/Other documents introduced below/

1.1 Terminology
s/Competing-non-PCN-packet: a non PCN-packet that shares a link with/
  /Competing-non-PCN-packet: a non PCN-packet that shares a queue with/

"                [I-D.ietf-pcn-baseline-encoding] defines only two PCN
       encoding states available (PCN-marked and not-marked); the
       deployment MUST choose whether PCN-marked is interpreted as
       excess-traffic-marked or threshold-marked; a consistent choice
       MUST be made throughout a PCN-domain.
"This sentence is too detailed and normative for the terminology 
section and would be better merged in with the other text about the 
same subject in S.2.5. With the following additional changes:
s/the deployment MUST choose/in this case the deployment MUST choose/

2. Specified PCN-marking behaviour

s/This section specifies the PCN-marking behaviour.
  /This section specifies the PCN-marking behaviours./

2.4. Excess traffic meter function

Move this para to the start of the section:
"  A PCN-node MUST implement an Excess traffic Meter that has behaviour
    functionally equivalent to the following.
"

References.

Suggest one or two references to original research on virtual queues, 
to provide some legitimacy, rather than implying this is all just 
invented out of thin air with no theoretical backing. E.g. the 
original Courcoubetis paper in the context of ATM.

B.1. Competing-non-PCN-traffic

s/and there is voice-admit traffic in the PCN-domain./
  /and there is non-PCN voice-admit traffic in the PCN-domain./

Somewhere, we need to explain that PCN & non-PCN voice-admit traffic 
probably differ only in the ECN field, not the DSCP. Some networks 
might schedule them in separate queues distinguished only by ECN 
field, while others might schedule them together.

B.2 Scope

s/such considerations are out of scope of PCN./
  /such considerations are out of scope of this document./

An RFC exists beyond the lifetime of a w-g, so the current scope of 
the w-g is irrelevant in an RFC.

B.4 Traffic conditioning

s/wold/would/

s/In brief, the reason is that this avoids over-termination, with the 
CL/SM edge behaviour, in the event of/
  /In brief, the reason is that with the CL/SM edge behaviour this 
avoids over-terminationin in the event of/

B.5. Threshold metering

s/However the implementation is not standardised./
  /However the description is not intended to standardise implementation./

"     *  leave TBthreshold.fill unaltered and indicate threshold-mark to
          the Marking function.
"
[By you definition of functionally equivalent, this isn't. But I 
think you need to relax the definition, rather than preclude this 
implementation.]

B.6. Excess traffic metering
s/However the implementation is not standardised./
  /However the description is not intended to standardise implementation./

s/substantially pre-congested and hence PCN-marking all packets.)/
  /substantially pre-congested and hence excess-rate-marking all packets.)/

s/and the impact of not doing it is moderate/
  /and the impact of not doing it is undesirable but moderate/

Bob

At 16:47 05/03/2009, [email-masked] wrote:
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 00:25:19 -0000

thanks bob. will include in the next update. great that only editorial comments. i'll ponder the one about "functionally equivalent" (I'm not even sure whether it's necessary to define it - i think this would be unique for ietf doc to try & say something on these lines rather than leave it vague?)
 
on the refences, re referring to the first research that generated PCN-like adm control concept: we should do this once within the PCN document set. am thhinking that the archiecture draft would probably be the more appropriate than this draft? but am happy to include it in the marking behaviour doc instead. 
 
the old CL draft included the following text [which seems to be not in the pcn-architecture draft]. this would seem a good starting point. please send the courcoubetis reference (& others that should be added)
 
The admission control mechanism evolved from the work led by Martin 
   Karsten on the Guaranteed Stream Provider developed in the M3I 
   project [GSPa, GSP-TR], which in turn was based on the theoretical 
   work of Gibbens and Kelly [DCAC]. 
 
thanks
phil

________________________________

From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: Mon 23/03/2009 23:52
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt

Phil,

Abstract:

1. Intro

1.1 Terminology

References.

B.2 Scope

B.4 Traffic conditioning

s/wold/would/

B.5. Threshold metering

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Mar 2009 14:23:00 +0000

Phil,

On a 'seminal reference' I thought the marking draft (rather than the 
architecture) would be the best place to put a ref to a scholarly 
paper on why virtual queues are useful and what they are. Here's the 
original paper:

@ARTICLE{Courcou96:Vq,
   author = {Costas Courcoubetis and Richard Weber},
   affiliation = {1: ICS FORTH; 2: Cam Uni},
   year = 1996,
   title = {Buffer Overflow Asymptotics for a Switch Handling Many Traffic
           Sources},
   journal = {Journal Applied Probability},
   volume = 33,
   pages = {886--903},
   keywords = {Data Communication, Networks, ATM, Quality of Service, QoS,
              Congestion Control, Rate Control, Policy, Admission Control,
              Protocols, Signalling, Architecture, Algorithms},
   entryby = {RJB},
   entry = {1 Oct 2002}
}

Bob

At 00:25 24/03/2009, [email-masked] wrote:
>thanks bob. will include in the next update. great that only 
>editorial comments. i'll ponder the one about "functionally 
>equivalent" (I'm not even sure whether it's necessary to define it - 
>i think this would be unique for ietf doc to try & say something on 
>these lines rather than leave it vague?)
>
>on the refences, re referring to the first research that generated 
>PCN-like adm control concept: we should do this once within the PCN 
>document set. am thhinking that the archiecture draft would probably 
>be the more appropriate than this draft? but am happy to include it 
>in the marking behaviour doc instead.
>
>the old CL draft included the following text [which seems to be not 
>in the pcn-architecture draft]. this would seem a good starting 
>point. please send the courcoubetis reference (& others that should be added)
>