Subject: [PCN] ECN handling with 3-in-1

From: Michael Menth <[email-masked]>
Date: Thu, 31 Mar 2011 11:27:21 +0200

Hi Bob,

I save this short writeup for the list. I believe that these are the 
options we have to handle ECN traffic carried over PCN domains. 
Hopefully this helps to resolve the issue.

Handling of ECN traffic
* ECN traffic not sharing a PCN-compatible DSCP
     - no action needed
* ECN traffic sharing a PCN-compatible DSCP but not being subject to PCN 
control
     - ingress tunnels that traffic with an non-PCN-compatible DSCP in 
the outer header (any tunnel may be used)
     - ingress maps the DSCP to a local DSCP and egress re-maps it to 
the original PCN-compatible DSCP
* ECN traffic sharing a PCN-compatible DSCP and being subject to PCN control
     - ingress drops CE-marked packets and egress zeros ECN field of PCN 
packets which disables end-to-end ECN
     - ingress tunnels that traffic with a PCN-compatible DSCP in the 
outer header and the egress zeros ECN-field before decapsulation (any 
tunnel may be used)
* ECN traffic sharing a PCN-compatible DSCP, being subject to PCN 
control, and the receiver has indicated to receive PCN marks
     - ingress tunnels that traffic with a PCN-compatible DSCP but the 
egress does not zero the ECN field before decapsulation according to 
RFC6040 normal mode

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 31 Mar 2011 10:47:48 +0100

Nearly, but not quite...

I would suggest the first bullet is pointless and redundant -- we don't care
about /any/ traffic not sharing the PCN DSCP. If we list this are we meant
to list every conceivable option where traffic doesn't interact with PCN?

There is one option (at least) missing, namely taking advantage of the
not-PCN codepoint for non-PCN traffic in the PCN DSCP -- see inline for
details.

Finally, I am not sure you have it quite right for the option on leaking PCN
marks -- see inline.

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: 31 March 2011 10:27
> To: Bob Briscoe; [email-masked]
> Subject: [PCN] ECN handling with 3-in-1
> 
> Hi Bob,
> 

Or ingress IP-in-IP tunnels that traffic within the PCN DSCP, but marks it
as not-PCN for its journey through the PCN-domain

> egress does not zero the ECN field before decapsulation according to

Actually I think the PCN-egress node function has to be different in this
case. If signalling has shown this is a viable option that sender and
receiver both want, the PCN-egress node SHOULD NOT zero the ECN field. This
allows the more severe of the outer or inner marking to proceed to the
receiver... This would of course potentially run into issues with the ECN
nonce, but I think consensus is that the nonce is dead (as it was
experimental and there has been no report of successful deployment).

Toby

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

---

From: Michael Menth <[email-masked]>
Date: Thu, 31 Mar 2011 23:17:25 +0200

Hi Toby, Bob, all,

> not-PCN codepoint for non-PCN traffic in the PCN DSCP -- see inline for

I see that we approach the same problem from two different views.
1) My viewpoint is "Handling of ECN traffic across PCN domains" and
2) your viewpoint is "Handling of non-PCN traffic sharing the PCN-DSCP".
I think both approaches are valid and lead essentially to the same 
result. The difference is that 1)  considers ECN traffic for 
non-PCN-DSCPs which is an non-critical issue while 2) considers PCN 
traffic for which PCN codepoints are not used at all.

The reason why I chose approach 1) is because we might have traffic 
arriving with a non-PCN DSCP outside the domain for which PCN-based 
AC/FT is done within the PCN domain and which thereby becomes PCN 
traffic. This traffic might also be ECN-capable. To express this more 
clearly, we should speak about:
ECN traffic not sharing a PCN-compatible DSCP and not being subject to PCN
ECN traffic sharing a PCN-compatible DSCP and not being subject to PCN
ECN traffic being subject to PCN (whether this traffic had a 
PCN-compatible DSCP before entering the PCN domain does not matter with 
regard to ECN treatment)

> as not-PCN for its journey through the PCN-domain
Good point! But question: is it possible to have AQM for non-PCN-ECN 
traffic in a PCN domain? Then this option is inferior to what I have 
proposed as it turns of ECN for non-PCN-ECN traffic within the 
considered PCN domain. Should we still recommend that as another option?

> experimental and there has been no report of successful deployment).
Yes, it's good to point out that this kind of tunneling hurts the nonce. 
Does this hold for RFC6040, too, and also for Bob's guidelines draft in 
tsvwg?

Here is the updated text for better readability:

Handling of ECN traffic
* ECN traffic not sharing a PCN-compatible DSCP
     - no action needed
* ECN traffic sharing a PCN-compatible DSCP but not being subject to PCN 
control
     - ingress tunnels that traffic with an non-PCN-compatible DSCP in 
the outer header (any tunnel may be used)
     - alternative: ingress maps the DSCP to a local DSCP and egress 
re-maps it to the original PCN-compatible DSCP
     - alternative: ingress tunnels that traffic with not-PCN in the 
outer header (any tunnel may be used); note that this turns of ECN for 
this traffic within the PCN domain.
* ECN traffic being subject to PCN control
     - ingress drops CE-marked packets and egress zeros ECN field of PCN 
packets which disables end-to-end ECN
     - alternative: ingress tunnels that traffic with a PCN-compatible 
DSCP in the outer header and the egress zeros ECN-field before 
decapsulation (any tunnel may be used)
* ECN traffic being subject to PCN control, and the receiver has 
indicated to receive PCN marks
     - ingress tunnels that traffic with a PCN-compatible DSCP but the 
egress SHOULD NOT zero the ECN field before decapsulation according to 
RFC6040 normal mode; note that this may turn ECT(0) into ECT(1) so that 
the nonce is modified.

Another two questions
* Traffic may arrive with a non-PCN DSCP and is subject to PCN-based 
AC/FT. Do we care about the original DSCP? This seems to be a similar issue.
* How is the ECN-field of traffic with a PCN-compatible DSCP interpreted 
outside a PCN domain? I guess with ECN semantics? Have we stated that 
somewhere. Do we need to state it?

Best wishes,

     Michael