Subject: [PCN] Full review of draft-eardley-pcn-marking-behaviour-01

From: Bob Briscoe <[email-masked]>
Date: Thu, 31 Jul 2008 16:46:44 +0100

Phil,

I've annotated all the minor comments into a 
MS-Word/PDF here: 
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/ipe2eqos/pcn/marking/draft-eardley-pcn-marking-behaviour-01_rvw_rjb.pdf>

Below I've listed those that are more high level, 
which you seem to have largely accepted already - 
but I'm documenting them here for the list to comment on if desired.

==========================================================================
Throughout:
-----------
Remove stuff that's about per-domain behaviour, 
keeping only per-hop marking behaviour.

Keep stuff that refers to PCN-arch, but not as 
the /only/ architecture in which this marking is 
valid, only as a concrete example.

However you then need to say: "If admission 
control or flow termination are required, this 
per-hop marking behaviour does NOT provide these 
functions on its own. For these, the per-hop 
marking behaviour needs to be part of some wider 
domain behaviour, which combined with the PHBs provides AC & FT.

1. Introduction

Say what this draft is: "A definition of an 
alternative congestion marking behaviour as allowed by RFC3168."

And how the draft is expected to be used: 
"Definitions of PHBs can refer to this document 
to define a congestion marking behaviour that is 
an alternative to the broadly RED-like default defined in RFC3168."

And possibly, that this draft also, in itself, 
associates its marking behaviour with packets of 
a certain existing PHB(s) if the ECN codepoint is not-ECN. (???)

1.1. Terminology.
...
    o  Other-traffic: traffic that uses the same DS codepoint as PCN-
       traffic...

NOTE: Other traffic doesn't have to have the same 
DS codepoint as PCN-traffic – it just has to share the same queue.

Rather than saying {priority|other}-traffic may 
not be present, use the opportunity to be more 
assertive up front: "Note: Appendix XX does not 
recommend {priority|other}-traffic in a PCN-domain."

2.2 Classify Function

The classify function doesn't determine which 
DSCPs are PCN-capable. That's a configuration 
matter before any packets arrive. Classification 
merely determines whether a packet matches DSCPs 
that have been configured as PCN-capable. For the 
ECN field, PCN-capability may be determined by 
configuration or by standards action, depending 
on whether we end up standardising just one 
experimental encoding scheme or not.

2.3 Traffic conditioning function

"<you might argue that other-packets should get harsher
          treatment since they're not subject to PCN's adm & termination
          control, only subject to the weaker DiffServ style static TCAs
          at the PCN-ingress-node>"
I suggest you refer here to a short appendix and 
in the appendix say this (as a SHOULD, not a 
'might should'). Include Intserv over Diffserv 
[RFC2998], as well as just Diffserv static TCAs [RFC2575].

B.1 Scope

Suggested text for the controversial double MUST:
"   Note that even if only two encoding states are used, it is still REQUIRED
    that both the meters
    are implemented, in order to ease compatibility between
    equipment and remove a configuration option and associated
    complexity.  Hardware with limited availability of instances of token
    buckets MAY be configured to only run one or 
the other meter at a time, but
    it MUST be possible to enable either meter and preferably both.
"

B.2 Classify

Add final sentence:
"   For this and other reasons already given, 
allowing Priority-traffic or Other–traffic to 
compete with PCN traffic in the same queue is NOT RECOMMENDED."

B.3. Traffic Conditioning {or in another appropriate place}
Add:
"   Assuming admission control and flow 
termination as per-domain behaviours, the length 
of the real queue should be kept small. The size 
of the real buffers for these small queues of PCN 
traffic should also be kept small to minimise the 
risk of over-termination of flows following an 
episode of excess traffic [ref Zhang TBA]. "

"   Exactly what "preferentially dropped" means is left to the
    implementation.  It is also left to the implementation what to do if
    there are no excess-traffic-marked PCN-packets available at a
    particular instant.

    <should we leave it this open or give some options, eg: definitely
    drop an excess-traffic-marked packet or drop with a higher
    probability; or, if there are no excess rate marked PCN-packets
    available, drop any PCN-packet, drop the next excess-traffic-marked
    PCN-packet>"
My view: Delete the second sentence (ie leave it 
open what implementers should do). (For instance, 
a really simple mechanism would suffice, e.g. 
consider the allowed queue before drop 1 MTU 
shorter for already marked packets than for others.)

B.4 Threshold Metering

Add:
"   The description deliberately marks a packet 
that has caused the bucket to cross the threshold 
without explicit additional bias for the packet's size.
"

Give a definition of 'functionally equivalent' in 
terms of external behaviour of a black box being broadly similar.
Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn