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

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 08 Mar 2010 17:22:09 -0500

Please notice the submission of the the latest Encoding Comparison draft.
Please review and provide comments to the list (preferred) or the co-authors.

If possible, we wish to finish this draft in the near future.
Hoping for more review => better document => WGLC.

Thanks!
-- Co-Authors of Encoding Comparison draft --

>Date: Mon, 08 Mar 2010 13:30:02 -0800 (PST)
>From: [email-masked]
>Subject: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-02.txt
>Sender: [email-masked]
>To: [email-masked]
>Cc: [email-masked]
>List-Post: <mailto:[email-masked]>
>List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>,
>         <mailto:[email-masked]?subject=subscribe>
>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Id: PCN WG list <pcn.ietf.org>
>Original-recipient: rfc822;@usams01-in.huawei.com:[email-masked]
>
>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           : Pre-Congestion Notification Encoding Comparison
>         Author(s)       : K. Chan, et al.
>         Filename        : draft-ietf-pcn-encoding-comparison-02.txt
>         Pages           : 37
>         Date            : 2010-03-08
>
>Pre-congestion notification (PCN) is a link-specific and load-
>dependent packet marking mechanism for Differentiated Services
>networks.  The packet markings are evaluated by egress nodes of PCN
>domains and the result is used for admission control and flow
>termination decisions.  Two different types of markings have been
>defined.  This document gives a summary of the marking requirements,
>the constraints to encode them in the current IP header (version 4
>and above), and it explains why the PCN WG currently supports
>different encoding schemes for PCN marking.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-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.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-02.txt>
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2010 13:51:56 +0000

Kwok and co-authors,

Thank you for the monumental effort re-writing this.

I promise to review it fully, but in the mean time, I would just like 
to post a couple of comments that I noticed while scanning it.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Appendix C.  Encoding Using DSCP Field

                                                         ... Note that
    all additional and experimental DSCP values are representing and are
    associated with the same PHB.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Appendix C.1.  Benefits of Using DSCP Field

...
    o  it is not affected by the PCN tunneling issues.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

I believe this is incorrect.

Tunnels can be configured to either propagate the DSCP or not 
(respectively the uniform and pipe conceptual models [RFC2983]). The 
IPsec architecture [RFC4301] allows IPsec tunnels to be configured 
using the pipe model in order to block the use of the DSCP as a 
covert channel between protected and unprotected domains (see 
S.5.1.2). I believe in practice many IPsec tunnel products use the pipe model.

If the pipe model is configured, such tunnels will not propagate PCN 
signalling. This wouldn't be a problem for PCN if the PCN region were 
wholly within a pipe-model tunnel, but the draft should mention that 
this type of tunnel would otherwise preclude the use of the DSCP for PCN.

Bob

>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-02.txt>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 10 Mar 2010 15:03:41 +0100

Hi Bob

Thank you very much for the comments!

We will fix them! 

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Briscoe
> Sent: woensdag 10 maart 2010 14:52
> To: Kwok Ho Chan
> Cc: [email-masked]
> Subject: Re: [PCN] Fwd: I-D 
> Action:draft-ietf-pcn-encoding-comparison-02.txt
> 
> Kwok and co-authors,
> 
> I promise to review it fully, but in the mean time, I would 
> just like to post a couple of comments that I noticed while 
> scanning it.
> 
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 10 Mar 2010 09:35:18 -0500

Hi Bob:
Thank you for your comments.
Please see in line below.
We will make the changes appropriately for the next version.
-- Kwok --

At 08:51 AM 3/10/2010, Bob Briscoe wrote:
>I promise to review it fully, but in the mean time, I would just 
>like to post a couple of comments that I noticed while scanning it.
>
>
>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.

Agree that PCN is another dimension and when using DSCPs as encoding for PCN,
it can become a multiplying factor per original DSCP.
We will clarify this point and correct the text appropriately.

>signalling. This wouldn't be a problem for PCN if the PCN region 
>were wholly within a pipe-model tunnel, but the draft should mention 
>that this type of tunnel would otherwise preclude the use of the DSCP for PCN.

Agree that the current text needs to be expanded to better describe 
the tunnelling scenarios.

---

From: Michael Menth <[email-masked]>
Date: Wed, 10 Mar 2010 17:41:41 +0100

Hi Bob and all,

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

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.

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?

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.

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: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2010 17:51:41 +0000

Michael,

At 16:41 10/03/2010, Michael Menth wrote:
>>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?

Yes.

>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

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

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.

>main body of the encoding draft.

Yup.
Thanks

Bob

---

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 10 Mar 2010 13:18:00 -0500

Hi all
This E-Mail message only replies to Bob's first issue (DSCP 
multiplicity issue).
Please see inline under the first issue.
Thanks!
-- Kwok --

>like to post a couple of comments that I noticed while scanning it.

<KHC Start>
Agreeing on the need of N PCN Encoding-State DSCPs per each of the 
original Z DSCPs.
Hence the N multiplying factor of PCN DSCP usage.

With the fact that the original Z DSCPs already indicate the ECN 
field should be interpreted
using PCN semantics.  There is slight possibility we may already 
requiring an additional
DSCP for traffic that use both ECN and PCN.

Also, the PCN DSCPs should not change the queuing behavior of the 
original Z DSCPs
(in the aggregate) with the exception of the dropper as indicated in 
section 2.2.4 of
EncodingComp-02.  The PCN DSCPs are used for PCN behavior indication only.

Hence we are trying to use as few PCN DSCPs as possible to achieve the required
encoding functionality.

Now if the aggregation (tunnel) is totally contained in the PCN 
domain, then the N x Z DSCPs
are only in the PCN domain, this is feasible with additional 
complexity (should try to avoid
the additional complexity).

The message of trying to use as few DSCP for PCN is in the main body 
of the EncodingComp-02 draft.
If the above discussion adds value to the text, we can add it or use 
it to help clarify the text.

This confirms we need the tunneling draft be RFC to try keep N = 1. :)
<KHC End>

---

From: Michael Menth <[email-masked]>
Date: Wed, 10 Mar 2010 21:24:47 +0100

Hi Kwok, hi Bob,

I added the recent discussion to the main body of the document. It's in 
the attachment. I also streamlined Section 3 to improve readability. 
Kwok, could you take care of these changes, please?

Best wishes,

    Michael

Bob Briscoe schrieb:
> 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.

---

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 10 Mar 2010 15:44:44 -0500

Hi Michael:
I have started the -03 version of the draft and tentatively putting these
changes into -03.  Waiting to see if there are further discussion of this.
-- Kwok --

At 03:24 PM 3/10/2010, Michael Menth wrote:
>Hi Kwok, hi Bob,
>
>I added the recent discussion to the main body of the document. It's 
>in the attachment. I also streamlined Section 3 to improve 
>readability. Kwok, could you take care of these changes, please?
>
>Best wishes,
>
>    Michael
>
>Bob Briscoe schrieb:
>>Michael,
>>
>>>>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) 
>>>with different DSCPs (say i, j, k) may use PCN service. The 
>>>question is how to restore the DSCP at the egress node?
>>>This information - when validated - should probably also go into 
>>>the main body of the encoding draft.
>>
>>Yup.
>>Thanks
>>
>>
>>Bob
>>
>>
>>>Best wishes,
>>>
>>>    Michael
>>>
>>>--

---

From: <[email-masked]>
Date: Thu, 11 Mar 2010 08:28:27 +0100

Hi Michael, 

looking at it with carrier glasses, scaleability is the issue
a) may be viable (depends on the tunnel mechanism, may eg. work with MPLS or Pseudo Wires)
b) is sound for an IP network, but doesn't work with MPLS and any other layer restricted 
   to 8 QoS classes and codepoints. 
c) doesn't scale with backbone network elements. 

If a) with IP over MPLS tunnels or an Ethernet based solution using Pseudo Wires, GRE or 
something similar is compared to to c), something similar may result. You can have an 
inner header QoS class and an outer header one. Proposal a) scales better, as it can 
be implemented in hardware.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Wednesday, March 10, 2010 5:42 PM
To: Bob Briscoe
Cc: [email-masked]
Subject: Re: [PCN] Fwd: I-D Action:draft-ietf-pcn-encoding-comparison-02.txt

Hi Bob and all,

Best wishes,

    Michael

-- 

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Rüdiger Geib
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2747 (Tel.)
+49 251 7985 209 (Fax)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

---

From: Michael Menth <[email-masked]>
Date: Thu, 11 Mar 2010 10:19:04 +0100

Hi Rüdiger,

thanks, I added your comments.

Best wishes,

    Michael

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 11 Mar 2010 17:02:11 +0000

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:
>>>(rather than one per original DSCP) then it would become 
>>>impossible to map PCN-marked traffic to the correct PHB on deaggregation.
>>

---

From: Michael Menth <[email-masked]>
Date: Thu, 11 Mar 2010 20:18:33 +0100

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:
> 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.
>
> 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:
>
> if inner headers are decapsulated along the path, the markings need to 
> be automatically propagated to the next higher layer. The encoding 
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.

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

> - ECMP is in a separate category, as it's possible to turn it off, but 
> it it would be better not to have to.
> Here's a fuller list of the requirements we were originally working to 
> (taken from the contents of draft-briscoe-tsvwg-cl-phb-03)
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?

> 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

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 15 Mar 2010 12:19:42 +0000

Michael,

>used for load balancing and then re-marked packets take a different route?

The measurements of PCN markings that an egress meters assume that 
the egress can distinguish a set of packets that have all traversed 
the same path (a PCN ingress-egress aggregate (IEA)). ECMP is a 
requirement in some networks. It can lead to a PCN egress placing 
packets that have taken different paths into the same IEA. This can 
lead to measurement errors.
This problem can be solved in a number of ways. One way proposed has 
been to include affected marking in the encoding. Others have argued 
Affected Marking doesn't work very well in many realistic cases.

However, that doesn't mean we should simply not mention the original 
ECMP requirement. Even if none of the proposed encodings fully meet 
the requirement.

BTW, that doesn't mean the ECMP problem isn't solvable - it just 
doesn't seem to be solvable by using a modified encoding.

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

That doesn't mean it's not a requirement.

I'm not sure whether you are saying you don't understand the proposed 
mechanisms, or that you understand them, but suspect they won't work.

>Also that I haven't understood so far.

A lot of time was spent in the early days of PCN documenting all the 
possible modes of misconfiguration in order to choose between 
otherwise equally useful encodings. However, since the tunnelling 
issues became predominant, we have so few usable options left that 
slightly better resilience to misconfiguration is no longer a deciding factor.

But that still doesn't mean it's not a requirement and that we 
shouldn't mention why it is not a gating factor any more.

>How is that to be measured?

There was text in the early PCN drafts comparing the cycles used for 
marking different types of encodings.

>>expected to avoid choices that would make anti-cheating difficult 
>>to add in the future.
>>

It's not relevant because the ECN nonce mechanism requires reliable, 
ordered delivery (it was tied heavily to TCP). PCN is between 
internal edge nodes that may not receive packets in order, and don't 
typically do reliability.

But if this draft is meant to be recording the history of how we 
decided on particular encodings, part of that process was to discount 
the nonce as an issue. That decision then allowed certain encodings 
to be considered that were previously less favoured because they 
didn't propagate a nonce.

...

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

3-in-2 supports e2e ECN if leakage of PCN markings is supported by 
the endpoints and they signal this requirement to the PCN edge nodes.

This is theoretical, because AFAIK no-one has designed or implemented 
such a scheme. But it might workable. That's one of the reasons why 
this is only an option within a draft that is only experimental track anyway.

I agree that, without negotiating leakage, 3-in-2 can only provide 
limited e2e ECN support. Limited means it can only propagate non-CE 
codepoints (Not-ECT, ECT(0) and ECT(1) but CE must be dropped at 
ingress), which makes it very limited. We need to update the draft to 
say that more clearly.

Cheers

Bob