Re: [PCN] Fwd: I-D Action:draft-ietf-pcn-encoding-comparison-02.txt

[Bob Briscoe <[e-mail]>]

Co-authors,

[I have included the PCN list in the distr for my review comments, 
just in case it prompts anyone else to comment. Hope that's OK.]

It's great that this one is finally getting into shape. I like the 
new focus on just the main schemes that have come through the w-g process.

I have only posted comments and suggested text on the body of the I-D 
up to S.8. I will comment on the appendices when I get time later. 
Suffice to say we ought to cut down their length. I see Appx E is 
redundant - it merely repeats what the Conclusions section says.

Main points (always bearing in mind we want to put this one to bed 
quickly, as it's only a historical record):

* The first 13 pages recap other RFCs. Each time we introduce another 
RFC, we need to say something like "This is an attempt to briefly 
summarise RFC XXX. If there is any contradiction, the original RFC 
takes precedence."

* 1. Intro 1st para.
Need to state applicability of AC & FT only to inelastic traffic.

* 1. Intro 3rd para
The DSCP and the ECN field "...have been selected..." doesn't say 
why. There's a very good reason, which we ought to articulate in this 
doc, as this is for the record. This can be picked up from the 
appendices, but it's best to say something like the following up front:

"Pre-congestion notification needs to be encoded in a field with 
broadly similar semantics to the ECN field in the IP header. 
Specifically, a field is needed that is expected to be initialised to 
a not-marked state by a transport layer function at a 'bump in the 
wire'. It must be possible to alter the field without breaking any 
integrity, authentication or encryption schemes in use. The field 
might be altered (marked) at any (pre-)congested network node along 
the path. PCN expects network nodes to mark the outermost header, but 
if inner headers are decapsulated along the path, the markings need 
to be automatically propagated to the next higher layer. The encoding 
schemes chosen by the PCN working group mostly used ECN field because 
treatment of it by various pre-existing network functions already 
broadly provides all these basic properties. The differentiated 
services field was used in combination with the ECN field in one 
scheme, as it also broadly meets these basic criteria.

It must also be possible to distinguish between packets that are 
PCN-compatible and those that are not, so that network nodes only add 
PCN markings to packets travelling between ingress and egress 
functions that will understand them. The differentiated services code 
point (DSCP) was chosen in combination with the ECN field for this 
purpose, as recommended in RFC3168 and RFC4774.
"

* 2. General PCN Encoding Requirements.
We ought to include the following as additional requirements:
- ECMP
- anti-cheating
- safety in the presence of misconfiguration or partial deployment
   (referring to Appx B.7 & D.3)
- Processing costs (both marking and metering the marks)

- The last two are 'would be nice' requirements.
- ECMP is in a separate category, as it's possible to turn it off, 
but it it would be better not to have to.
- Anti-cheating isn't required for the initial charter, but we are 
expected to avoid choices that would make anti-cheating difficult to 
add in the future.

Here's a fuller list of the requirements we were originally working 
to (taken from the contents of draft-briscoe-tsvwg-cl-phb-03)
          11.6.1. How compatible is the encoding scheme with RFC 3168 ECN?
          11.6.2. Does the encoding scheme allow an "ECN-nonce"?
          11.6.3. Does the encoding scheme require new DSCP(s)?
          11.6.4. Impact on measurements
          11.6.5. Other issues

* 3.2. Constraints from the DSCP

"  Therefore, the DSCP
    should be used to indicate that traffic is subject to PCN metering
    and marking, but not to differentiate differently marked PCN traffic.
"
This unnecessarily precludes 3-in-2. A better wording would be:

"  Therefore, is would be better to solely use the DSCP to indicate 
that traffic is subject to PCN metering and marking, and only use the 
DSCP to distinguish between different PCN markings if unavoidable.
"

* S.3.3.2. Constraints Imposed by the Redefinition of the ECN Field
It's not clear that this subsection is talking about e2e ECN support. 
I will suggest suitable amended text.

Also, the comparison of encoding options (S.4.) needs to mention this 
constraint wrt each option - it currently only mentions it where it 
is supported, not where it isn't.

* 3.4 Constraints from Tunneling Rules

This section seems rather long, but I can't immediately think of a 
way to shorten it, so we should probably leave it as is.

After the introductory text (just before 3.4.1), I'd like to add to 
the last sentence as follows:

"  Two different modes are defined in [RFC3168]
    for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec
    tunnels. They are recapped below. A proposal to harmonise these 
divergent ECN tunneling behaviours and to better support PCN is on 
the IETF standards track [ID.ietf-tsvwg-ecn-tunnel]. It is also 
summarised below.
"

* 3.4.x
In each of the first three subsections of 3.4 (limited, full & 
IPsec), it would be much easier to understand if the constraints due 
to the encap behaviour were identified separately from the 
constraints due to the decap behaviour. I can provide suitable text amendments.

* 3.4.1 Limited Functionality Option

The last two sentences (repeated below) are incorrect and should be 
deleted (no need to replace them).

"  However, the PCN ingress may use this
    mode to tunnel traffic with ECN semantics to the PCN egress to
    preserve the ECN field in the inner header while the ECN field of the
    outer header is used with PCN semantics within the PCN domain.
    Hence, this mode may be useful to support (A) in Section 3.2.2.
"
If limited funtionality mode were used, the PCN ingress would 
initialise all packets to Not-ECT and PCN wouldn't work.
To use tunneling between PCN ingress and egress, the most important 
step is to ensure the PCN *egress* sets the outer ECN field to 
Not-ECT before the tunnel decap function. Then any ECN tunnel decap 
will preserve the inner header (as in the first column of Fig 6, 
which is the same for all ECN tunnelling modes).

This is NOT the same as limited functionality mode, which sets 
Not-ECT at the *ingress*.

* 4.1 Baseline Encoding

"  [...] mentioned before, SM-PCN may be inaccurate and a missing FT function
    is also a severe disadvantage.
"
Surely SM is not missing an FT function???

* 4.3. Encoding with 2 DSCPs Providing 3 or More States

"  Moreover, the direct application of this encoding scheme to other
    technologies like MPLS where even fewer bits are available for the
    encoding of DSCPs is more than difficult.
"
Delete this sentence - it's incorrect.

Both DSCP and ECN are encoded in the MPLS Traffic Class field (3 
bits) [RFC5462]. Therefore it makes no difference to MPLS whether PCN 
is encoded in the DS field or the ECN field in the IP header.

* 4.4. Encoding for Packet Specific Dual Marking (PSDM)

No disadvantages are listed. Is PSDM perfect? ;)
But then the conclusions don't choose it  :|

* 6. Security Implications

All the text after the first para isn't really relevant and could be 
deleted, because it's about the security of the PCN architecture in 
general, nothing specifically about the security of PCN encodings 
(actually the very final sentence is about encodings, but it doesn't 
really add anything).

* 6. Security Implications

We should add the following text:

"PCN is initially chartered to only consider deployment in a domain 
operated by a single trust entity. However the charter asks that a 
potential extension to multi-domain is kept in mind when making 
design choices, so that components will be more likely to be 
sufficiently general to support such extensions in the future.

A proposal has been made to extend the CL edge behaviour to multiple 
domains using the 3-in-1 encoding [ID.briscoe-re-pcn-border-cheat]. 
This proposal has so far been subject to only informal attempts to 
find weaknesses, but no vulnerabilities have yet been identified.

The PSDM encoding is the only one where PCN ingress nodes can choose 
how to initialise PCN-packets in such a way as to prevent 
pre-congested interior nodes from marking PCN-packets in certain 
ways. For instance, an ingress node is meant to send probe packets as 
subject-to-threshold-marking (Not-ThM), but it can make its flows 
immune to threshold marking by sending probes as 
subject-to-excess-traffic-marking (Not-ETM). Then, if an interior 
node is threshold marking PCN packets, a cheating ingress can 
continue admitting new flows, while others have to block theirs.

It would be hard for a network to detect or prevent this abuse of 
PSDM, particularly if the operators of the network and the edge nodes 
were distinct (e.g. an ISP and a supplier of underlying 
packet-transport service). For instance, the edge nodes could use 
IPsec to prevent the network knowing which packets represented the 
start of new flows.
"

* 8. Acknowledgements

We should ack the additional authors of the appendices of 
[ID.briscoe-tsvwg-cl-phb], from which this draft was originally derived:
David Songhurst, Francois Le Faucheur, Anna Charny, Vassilis Liatsos, 
Jozef Babiarz, Stephen Dudley, Attila Bader and Lars Westberg.


* I will also provide an annotated copy of the draft for all the 
editorial nits I have noted (lots).


HTH


Bob

At 17:51 10/03/2010, Bob Briscoe wrote:
>Michael,
>
>At 16:41 10/03/2010, Michael Menth wrote:
>>Hi Bob and all,
>>
>>>It should be made clear that schemes that use more than one DSCP 
>>>will require that many extra DSCPs for *each DSCP* being used with 
>>>PCN. Not just each PHB. Sometimes numerous DSCPs are mapped to one 
>>>PHB across aggregated networks (where PCN is particularly 
>>>applicable). They are kept as separate DSCPs, even though they are 
>>>aggregated into one PHB, so that they can be mapped to separate 
>>>PHBs in the access network at the receiver side [RFC5127]. If only 
>>>one DSCP were used for each type of pre-congestion notification 
>>>(rather than one per original DSCP) then it would become 
>>>impossible to map PCN-marked traffic to the correct PHB on deaggregation.
>>
>>Your statement triggers me. My understanding is that we need (at 
>>least) one DSCP for which the ECN field is interpreted as PCN 
>>encoding. This DSCP belongs to a high-priority PHB. However, flows 
>>with different DSCPs (say i, j, k) may use PCN service. The 
>>question is how to restore the DSCP at the egress node?
>>a) Tunneling using the pipe model - Is that an option?
>
>Yes.
>
>>b) One-to-one mapping of DSCPs to PCN-capable DSCPs
>>Multiple PCN-capable DSCPs (say  m, n, o) are needed and a 
>>one-to-one mapping:
>>DSCP i -> DSCP m
>>DSCP j -> DSCP n
>>DSCP k -> DSCP o
>>Then, the egress can restore the original DSCP without per-flow information.
>
>It would be more straightforward to config the machines within the 
>PCN domain to consider i,j,k as
>PCN-compatible DSCPs
>
>
>My point (which Kwok acknowledged) was that if an encoding scheme 
>uses 2 DSCPs for PCN marking, the three DSCPs i,j,k will expand to 
>three pairs (i1,i2),(j1,j2),(k1,k2) if approach b) is used.
>>c) Restoration from a per-flow context
>>Just one PCN-capable DSPC (say n) is needed. When a new PCN flow 
>>with DSCP i arrives, DSCP i is signalled to the egress node.
>>Ingress re-marks: DSCP i -> DSCP n
>>Egress re-marks: DSCP n -> DSCP i for that specific flow
>>Is this feasible? If so how? If not, why?
>
>It's feasible. It would need extra support in the signalling protocol.
>
>None of this is impossible, but I suspect implementers would be 
>happier to keep data-plane mappings that depend on flow-state to a minimum.
>
>
>>This is very similar to the way we may or may not preserve the ECN field.
>>a) tunnel with limited functionality / compatibility mode
>>b) maybe some advanced encoding, but I still have doubts ...
>>
>>This information - when validated - should probably also go into 
>>the main body of the encoding draft.
>
>Yup.
>Thanks
>
>
>Bob
>
>
>>Best wishes,
>>
>>    Michael
>>
>>--
>>Dr. habil. Michael Menth, Assistant Professor
>>University of Wuerzburg, Institute of Computer Science
>>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>phone: [phone] (new), fax: [phone] (new)
>>mailto:[e-mail]
>>http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design