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

From: <[email-masked]>
Date: Wed, 8 Apr 2009 09:35:59 +0100

Thanks bob, agree with nearly all of them - a few follow-ups below
phil

{ -----Original Message-----
{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Sent: 23 March 2009 23:53
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt
{ 
{ 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/

[phil] agree this is too detailed for terminology & will delete. In
addition, I think this part of S2.5 would be better in Appendix than
main body (will follow-up about that shortly)

{ 
{ 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.
{ "

[phil] disagree with moving this to start of section. The section starts
"A PCN-packet SHOULD NOT be metered (by this excess traffic meter
function) in the following two cases: ...". I think it's better to keep
the SHOULD NOT outside the MUST! 

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

[phil] this is basically already discussed in B.4. I'll add a refernce
fwd. 

{ 
{ 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.]

[phil] suggestion how to relax it?

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

[phil] you mean threshold-marking

{ 
{ 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:
{ >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.
{ >_______________________________________________
{ >PCN mailing list
{ >[email-masked]
{ >https://www.ietf.org/mailman/listinfo/pcn
{ 
{ ________________________________________________________________
{ Bob Briscoe,               Networks Research Centre, BT Research

---

From: <[email-masked]>
Date: Wed, 8 Apr 2009 10:38:37 +0100

I realise I disagree with this one:

{ { 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/

suppose the PCN-pkts & competing-non-pcn-pkts used separate queues, but
the same link [an alternative implementation to common queue - B.4 & as
you mentioned later in your mail]
so I think "link" is correct.