Subject: [PCN] Comments on draft-ietf-pcn-encoding-comparison-02

From: <[email-masked]>
Date: Mon, 29 Mar 2010 23:26:58 +0100

Comments on draft-ietf-pcn-encoding-comparison-02

The draft is better (and i know there's a -03 version in progress that i havent read), but I still think it should give a much better sense of why the baseline encoding was chosen and what are the pros and cons of the WG extension encodings. The information is in there, but rather hidden - I think it would be good to draw this out near the start. As a kind of summary, with forward pointers to the rest of the document.

I tried for some text (see end) [before I read Appendix A first part (ie before A.1) - which is quite nice.]. it needs more work, but I think something on these lines would be helpful. I'm thinking of something pretty short that gives the flavour of why the baseline was chosen, and the flavour of the rationale for the various extensions. Definitely not something that provides an explanation with all the gory detail - this is what the rest of the document is for!

Abstract

the 'standard' PCN abstract has been re-written(!) In any case, I disagree with it ("PCN" is not the marking mechanism, but the QoS mechanism).

Intro

Similar comment to abstract. 

AC, FT, DR are unneeded abbreviations. 

"metering and marking algorithm" - no, "behaviour" (repeat comment throughput doc)

"Since unused codepoints.." - ugly sentence

2.1 last sentence - re-phrase. And may be wrong - since ETM can't be re-marked to ThM.

2.2.1

Fig is useful

i'd delete everything from "We briefly summarise the concept..."

2.2.2

Same comments as 2.2.1

Dual marking and single marking - I don't these terms have been used in this way in previous PCN docs. For instance, single marking has been used in the context of a particular edge behaviour. If only one codepoint is available you might not do "single marking [that] uses only excess-traffic-marking" - instead you might do only threshold-marking and admission control only.

Am inclined to think it would make sense to scrap the sections and move the pics into S4.

2.2.3

PSDM section is odd - It doesn't seem comparable to 2.2.1 & 2.2.2.

The section uses the term "probing" - which is a banned term. 

2.2.4

Badly written. Marking behaviour [not termination, not algorithms] states [not proposed. You refer to it both being 'recommended' and 'must'. Etc

3.2 para 1 last sentence

"but not to..." - eh?

3.3.1 delete first sentence

3.3.2 lay out para 2 better [use bullets]

S4

Are you going to mention both the 3-in-2 variants?

4.3 

"currently unused and proposes one way how to reuse them" - rephrase, this is contradictory

S6

Stick with security implications of encoding, or refer to other docs. A general security discussion (and one that uses wrong terminology) seems pointless.

Didn't read the Appendix

-------

Something on these lines for an overall summary near the start:-

* statement

** explanation

== Baseline ==

* Uses the DSCP and ECN fields. 

** Codepoints in the IP header are in short supply. It fits with current use of these fields to use them to indicate QoS class and congestion marking.

* Uses only one DSCP - 

** DSCPs are in short supply, especially in some MPLS domains

* Allows non-PCN traffic to use the same DSCP; Such traffic is marked 00

** Again because of shortage of DSCPs.. 

* PCN-marking uses the 11 codepoint 

** so Works whatever sort of tunnel is in operation in the PCN-domain. 

* Defines 10 is defined as not PCN-marked and 01 is defined as Experimental (for use by the experimental extension encodings)

** Allows the baseline encoding to be extended - in some PCN-domains the above restrictions do not apply. Then other encodings can be used that allow extra PCN encodings. "Extended" means that the baseline encoding is compatible and doesn't break disastrously [this sentiment is phrased better in the baseline encoding doc]: 

* Restriction: ECN-marking is switched off for traffic using the DSCP

** because the ECN field is used for PCN-marking

Experimental extension encoding #1

* It uses the Experimental codepoint (01) to indicate admission-marked, whilst the 11 codepoint indicates excess-traffic-marked. 

** It assumes that the restriction imposed on the Baseline encoding by tunnel behaviours doesn't apply. For example, it might be known that there are no tunnels in the PCN-domain, or routers in the PCN-domain may be upgraded with the tunnelling behaviour defined in draft-ietf-tsvwg-....

Experimental extension encoding #2

* it uses 2 DSCPs; 11 with one DSCP indicates threshold-marking, and 11 with the other DSCp indicates excess-traffic-marking

** assumes that 2 DSCPs are available

Experimental extension encoding #3

* same as #2, but uses the unused codepoints to transmit ECN-markings across the PCN-domain

** may be useful. But limited functionality - the ECN-markings cannot always be transmitted. 

Experimental extension encoding #4

* it uses 2 different markings for packets that are _not_ PCN-marked: 10 for not-excess-traffic-marked and 01 for not-threshold-marked. The PCN-ingress-node sets the PCN codepoint to 01 for packets corresponding to a control message such as RSVP xx, whilst it sets it to 10 for data pkts

** assumes that the two types of not-PCN-marked packets can be distinguished at a higher layer at the PCN-ingress-node and PCN-egress-node. Overhead to perform this.