Subject: [Gen-art] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt

From: <[email-masked]>
Date: Thu, 18 Jun 2009 15:31:31 -0400

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 resolve these comments along with any other Last Call
comments  you may receive. 

Document: draft-ietf-pcn-marking-behaviour-03.txt
Reviewer: David L. Black
Review Date: 18 June 2008
IETF LC End Date: 18 June 2008

Summary: 
This draft is basically ready for publication, but has nits that
should be fixed before publication.

Comments:

This draft specified requirements on how the diffserv components
in a PCN node need to behave in order to support PCN.  In addition
to specifying the requirements, an example algorithm (Appendix
A) and extensive implementation notes (Appendix B) are provided.
The implementation notes are very useful - the WG should be
commended for working through the practical implementation
considerations for this functionality up front as opposed to
leaving them to implementers to puzzle out.

All of my comments are on relatively minor points:

"PCN-excess-rate" strikes me as a bad name for a configured
throughput rate - I suggest choosing another term.  Intuitively,
I would expect PCN-excess-rate to refer to traffic that is in
excess of a PCN configured rate.

Section 2.1, 1st paragraph and Section B.3 need to cite a
reference for how the DSCP and ECN field values are used to
decide whether a packet is PCN or not.

In Section 2.2, first bullet, what is "scheduling rate"?  Please
supply a definition.

Section 2.4 - the second bullet also applies to competing non-PCN
traffic (if that traffic is metered).  The text needs to be adjusted
to allow for this.  Try:

  A packet SHOULD NOT be metered ...

  o If the PCN-packet is already ....

  o If this PCN-node drops the packet.

Section 2.5 could use a reminder that while competing non-PCN packets
may be metered, they MUST NOT be marked.  This may have implications
for the marking behavior that are probably most usefully discussed
in Appendix B.

Nits:
- At the end of the first paragraph in B.1
	"there needs to be" --> "there should be"
  The "should" is lower case.

- idnits 2.11.11 noted that there is now a -04 version of the
	pcn-baseline-encoding draft, as was noted in the draft
	shepherd's writeup.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 19 Jun 2009 13:56:41 +0100

David,
Thanks for your review & comments.

{ The implementation notes are very useful - the WG should be
{ commended for working through the practical implementation
{ considerations for this functionality up front as opposed to
{ leaving them to implementers to puzzle out.
Thanks!

{ "PCN-excess-rate" strikes me as a bad name for a configured
{ throughput rate - I suggest choosing another term.  
To be honest, I think it's too late to change it, as it's defined/used
in the PCN architecture doc, which has just become RFC5559.

{ Section 2.1, 1st paragraph and Section B.3 need to cite a
{ reference for how the DSCP and ECN field values are used to
{ decide whether a packet is PCN or not.
Ok, will add "For instance, the baseline encoding [ref]."

{ 
{ In Section 2.2, first bullet, what is "scheduling rate"?  Please
{ supply a definition.

I think the bullet needs re-phrasing. Here's what it says at the
moment:- 
<<On all links in the PCN-domain, dropping MAY be done by:
   o  metering all metered-packets to determine if the rate of metered-
      traffic is greater than its scheduling rate (ie determine if any
      packets are out-of-profile).

how about the following?
   On all links in the PCN-domain, dropping MAY be done by:
   o  metering all metered-packets to determine if the rate of metered-
      traffic on the link is greater than the rate allowed for such
traffic.

{ 
{ Section 2.4 - the second bullet also applies to competing non-PCN
{ traffic (if that traffic is metered).  The text needs to be adjusted
{ to allow for this.  Try:
{ 
{   A packet SHOULD NOT be metered ...
{ 
{   o If the PCN-packet is already ....
{ 
{   o If this PCN-node drops the packet.

Good spot, thanks

{ 
{ Section 2.5 could use a reminder that while competing non-PCN packets
{ may be metered, they MUST NOT be marked.  This may have implications
{ for the marking behavior that are probably most usefully discussed
{ in Appendix B.

ok, will add reminder. 

{ 
{ Nits:
{ - At the end of the first paragraph in B.1
{ 	"there needs to be" --> "there should be"
{   The "should" is lower case.
{ 
{ - idnits 2.11.11 noted that there is now a -04 version of the
{ 	pcn-baseline-encoding draft, as was noted in the draft
{ 	shepherd's writeup.
{ 
{ Thanks,
{ --David
{ ----------------------------------------------------
{ David L. Black, Distinguished Engineer
{ EMC Corporation, 176 South St., Hopkinton, MA  01748
{ +1 (508) 293-7953             FAX: +1 (508) 293-7786
{ [email-masked]        Mobile: +1 (978) 394-7754
{ ----------------------------------------------------

---

From: Michael Menth <[email-masked]>
Date: Fri, 19 Jun 2009 18:51:51 +0200

Hi Phil, hi David,

> in the PCN architecture doc, which has just become RFC5559.
An alternative is to simply talk about the reference rate of the 
excess/threshold meter and marker. I just want to say that there is no 
need to use the expression at all. The reference rates of the meters and 
markers are then configured with some specific values (e.g. admissible 
or supportable rates which were defined in the architecture draft).

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/8888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Fri, 19 Jun 2009 15:30:36 -0400

Philip,

These suggested changes look fine, and I like Michael Menth's
idea of rephrasing the text to discuss "reference rates of the
meters and markers" instead of "PCN-excess-rate".

Thanks,
--David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, June 19, 2009 8:57 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Gen-ART review 
> ofdraft-ietf-pcn-marking-behaviour-03.txt
> 
> David,
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
> 
>