[PCN] PCN encoding options and tunnelling

[Bob Briscoe <[e-mail]>]

Kwok, George, Toby, Michael,

I believe tunneling represents the greatest constraint on the choice 
of codepoints in the ECN field, so it nearly decides this issue for us...

First I believe we have to allow for the likely possibility of a 
tunnel starting and ending within a PCN region (as in S.5.7 of the 
PCN arch I-D). For example, a multi-site VPN that is one big PCN 
region under one operator's control joined together over the public 
Internet by IPSec VPNs. If the customer-sites are part of the PCN 
region they could have typical paths across the VPN like this:
Sender > PCN_ingress > IPSec_encap > IPSec_decap > PCN_egress > Receiver

Then I suggest the following requirement sentence in S.2.2.7 of PCN 
encoding Comparision about tunnels:
=============================================================================
"Tunnel endpoints, whether encapsulators or decapsulators, should not 
require any new behaviour to handle PCN-capable packets. Expecting 
vendors of all IPSec and all IP in IP tunnel endpoints to cater 
specifically for PCN would be unrealistic, and require complex 
backward compatibility rules for tunnels prior to PCN. If tunnels did 
require PCN-specific behaviour, the resulting patchy and error-prone 
deployment would probably cause PCN to suffer byzantine feature 
interactions with poorly implemented tunnels.

Tunnel endpoints should not have to detect that a packet's DSCP is 
PCN and implement special PCN-specific encapsulating or decapsulating 
behaviour. The rules that already exist for tunnel endpoints to 
handle both the Diffserv field and the ECN field should 'just work' 
when handling packets with a PCN Diffserv codepoint."
=============================================================================

That sounds reasonable, but it puts strong further constraints on our 
PCN encoding options. Decapsulation in both RFC3168 'full 
functionality [tunnelling] mode' and the old and new RFC4301 IPSec 
architecture discards all ECN codepoints in the outer header except 
11, forwarding the inner header unchanged.

If we find this leaves us with no PCN encoding options, we might have 
to require all tunnel decapsulators within a PCN region to be changed 
(as currently implied in S.5.7 of the PCN architecture), but let's 
see whether we have to first...

With this constraint, it seems that none of 00, 01 or 10 of the ECN 
field can be used for encoding AM (admission marked) or TM 
(termination marked), without risking losing markings on 
decapsulation that were added to the outer header due to congestion 
in the middle of the tunnel.

Further, 00 cannot be used for the unmarked (UM) state, because a 
tunnel decapsulator will drop a packet if the inner header is marked 
00 and the outer anything but 11. That leaves only 01 or 10 for UM.

So far, if we use the ECN field at all, we're left with 01 or 10 for 
the unmarked state and only 11 for anything else.

Further, if either of 01 or 10 were used for UM, there would be a 
risk of losing the UM meaning if a tunnel straddled the PCN ingress 
but not the PCN egress, because the inner header is forwarded and the 
outer header discarded if the outer is 01 or 10. I think it would be 
reasonable for PCN standards to mandate that tunnel decapsulators 
take special account of PCN encodings if the encapsulator is not also 
in the region.

We also now have to work around RFC5129 recently standardising ECN in 
MPLS (with discussion of PCN in an appendix). I don't think that 
constrains us further, but I'll check. I'll also check I can still do 
the anti-cheating trick I'm proposing if we re-charter for multiple 
domains (I suspect this will be hard now).

Diffserv code points
--------------------
For PCN to work at all, we would have to mandate that all tunnel 
decapsulators within a PCN region used the uniform model of RFC2983 
(copying outer DSCP to inner).

The disadvantage of using /only/ DSCPs to encode PCN are as follows:

a) If an operator wants to have multiple PCN PHBs (e.g. for data 
plane as well as signalled precedence for emergency traffic), it has 
to use 1 more DSCP to /each/ PHB in order to add termination and 1 
more /each/ to add admission marking. Whereas using 11 in the ECN 
field for AM or TM requires only 1 DSCP per PHB. If an operator wants 
AM and TM, and data plane precedence it seems to have no choice but 
to use up multiple DSCPs, but at least it can use 11 in the ECN field 
for one of the markings.

b) If the operator uses equal cost multipath (ECMP) routing within 
the PCN region, and the vendor's ECMP algorithm depends on the DSCP 
in each packet, ideally we don't want to admission mark by changing 
DSCPs because this will throw some packets of each flow onto 
different routes, causing re-ordering. Ideally we don't want 
termination marking to change DSCPs either, but given all the 
constraints we might have to live with some packet re-ordering in all 
flows until some have been terminated, as this is becoming a bit of a 
corner case.

In summary
----------
It looks like we have two main option families left:
1/ use only the DSCP field for all PCN marking and the PCN ingress 
would have to set the ECN field to 01 or 10. No PCN interior nodes 
would change the ECN field.
2/ Use 01 or 10 in the ECN field for UM. Use 11 in the ECN field for 
AM. Use an extra DSCP for TM.

Option 2/ seems a slightly better compromise because of a) & b) above.

In either case, use another DSCP for affected marking if it is 
required at all (but see next email).

If there's one lesson from this,...
--------------------------------
...it's that encoding into a tightly constrained field should be 
standardised very very carefully. Most of our problems come from all 
the changes of mind concerning ECN that have happened over the years, 
leaving us no space to manoeuvre between all the backward 
compatibility constraints.

That doesn't mean we should standardise slowly. But it does mean we 
should get a design team of experts to focus on this one issue, all 
locked in a room until they are all happy. That means now. On this issue.

For instance, I believe Option 1/ would be better if we want to allow 
for end-to-end ECN as well. But I haven't thought that all through. 
And I also strongly believe that we shouldn't allow adaptive codecs 
to use PCN unless they explicitly signal that they are going to. 
Otherwise all PCN's admission control assurances break. If endpoints 
explicitly signal they want to be adaptive, I think we can manage 
forwarding ECN markings properly.

Further reading?
----------------
All the background to why ECN tunneling is like it is, and how it 
will need to change in the future, is explained in the draft I did 
for tsvwg on tunneling congestion notification, which I highlighted 
to the PCN list at the time. Bruce Davie & David Black have been 
helping with it and may become co-authors.

TSVWG and the area directors agreed to put that I-D on hold until the 
PCN w-g had got closer to a decision on encodings, but it was written 
to help PCN in that task. It recently expired, because we didn't 
think PCN encodings would take this long! You can still access an 
archived copy from my publications page:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#ecn-tunnel>

To save time you can cut to S.5 and onwards, if you just want to know 
the encap/decap behaviours and the variants that you have to be 
backward compatible with. Earlier sections explain why. Appendix A 
specifically discusses PCN tunneling, but I hadn't thought the 
encoding constrints through like I just did above.

Essentially, discarding 00, 01 & 10 from the outer header was 
unfortunately necessary in RFC3168 and RFC4301 for backward 
compatibility with the first experimental RFC2481 ECN, which 
satisfied possible concerns at the time about the ECN field being 
abused as a covert channel from the public Internet into an IPSec 
tunnel. Since then the security area has decided these concerns were 
unwarranted and the risk can be managed.

In the PCN sessions this week, I can repeat some of the slides from 
the summary presentation of this I gave to the tsvwg last Jun:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0707ecn-tunnel>
but I believe Toby will now be covering this in his slides anyway.


Bob


____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone] 


_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn