Re: [PCN] PCN encoding options and tunnelling

["Kwok-Ho Chan" <[e-mail]>]

Bob, all:
Why can't we consider the use of PCN as establishing a PCN VPN?
This view goes well with the use of DSCP to differentiate PCN 
packets/traffic from all other
packets/traffic.  With the definition of the PCN PHB as the behavior 
for such a PCN VPN.
In essences, the PCN packets/traffic travels in a VPN "tunnel" defined for it.
This view allows clear definitions of:
1. PCN VPN support on a per domain basis.
2. SLAs for interfacing the PCN VPN between different domains.
3. How such a PCN VPN may be extended through multiple domains, 
possibly end to end.

With the PCN VPN thinking, the other non PCN packets/traffic can be 
viewed as being packets
in VPNs/tunnels different from the PCN VPN/tunnel.  Then the PCN 
domain is the world inside
the PCN VPN.

With such a PCN VPN in mind, I would like to ask:
1. How does the VPNs in use today need to consider the ECN bits?
2. How does the VPNs in use today need to worry about mixing of each 
VPNs' packets/traffic
     together and separating them?
3. Does the VPNs in use today have to worry about other VPNs/tunnels:
     a. Starting the ingress end of one (or more) of the other 
VPN/tunnel inside its VPN?
     b. Endng the egress end of one (or more) of the other VPN/tunnel 
inside its VPN?
     c. Have both the ingress and egress endw of one (or more) of the 
other VPN/tunnel inside its VPN?
     If yes to any of the above, how are they being solved and can 
PCN adopt the same solution?
4. Can SLAs be written to handle both the DSCP and ECN bits so they 
are clearly defined
     in the PCN VPN ingress and egress points (PCN domain edges)?

I have the PCN VPN thinking in mind from the beginning and this is 
the reason I support the
use of DiffServ and DSCP to separate the PCN packets/traffic from the 
other packets/traffic.
Hopefully allowing many of the problems to be understood, solved, or 
worked arounded.

Section 2.2.7 on page 11 of
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-03.txt
have that thinking in mind and started putting some of the packet 
"leakage" issues
as exceptions rather then the norm.

Thanks!
-- Kwok --


At 07:53 AM 3/10/2008, Bob Briscoe wrote:
>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