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

[Michael Menth <[e-mail]>]

Hi Bob,

thanks a lot for your feedback. I added some remarks if some bullets 
were not clear to me. Then new text needs some more explanation. See 
inline ...

Bob Briscoe schrieb:
> 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
Why does ECMP matter here? Is it because if you change bits that are 
used for load balancing and then re-marked packets take a different route?

> - anti-cheating
So far I have not understood how anti-cheating mechanisms for PCN could 
work.

> - safety in the presence of misconfiguration or partial deployment
>   (referring to Appx B.7 & D.3)
Also that I haven't understood so far.

> - Processing costs (both marking and metering the marks)
How is that to be measured?

>
> - 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?
I think this is covered in Section 3.

>          11.6.2. Does the encoding scheme allow an "ECN-nonce"?
I have never understood this discussion. Is this issue still relevant?

>          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.
You mean were e2e ECN is supported? I think none of the encodings fully 
supports it. Also extended 3-in-2 encoding supports it only for 
not-marked packets, but not for re-marked packets.

Best wishes,

    Michael

>
> * 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 

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