Subject: Re: [PCN] Effect of RFC 6040 on PCN

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Mar 2011 16:29:21 -0400

This does meet my concern, thanks. The thought flitted through my mind 
that this is how things would work. I will have to make sure the 
language of the CL and SM drafts reflects this behaviour. That will 
probably satisfy David's comments on the subject of ECN.

On 13/03/2011 2:42 PM, Bob Briscoe wrote:
> Tom,
>
> [Feel free to cc your response to the PCN list, if you think this will
> be generally helpful.]
>
> See S.7 bullet 2, 2nd para of RFC6040.
>
> The idea of RFC6040 is to have two independent functions:
> - tunnelling behaviour
> - PCN ingress behaviour
> Then there doesn't have to be any conditional code in one dependent on
> whether the other is on the same box.
>
> RFC6040 is defined in such a way that, if a PCN ingress creates a tunnel
> across the PCN region, the PCN ingress behaviour can be applied to the
> outer header logically /after/ the RFC6040 tunnel ingress behaviour has
> been applied (even if on the same physical box).
>
> So the tunnel ingress function copies the arriving ECN field to the
> outer, then the PCN ingress function resets the outer ECN field to NM (10).
>
> If, on the other hand, there's a tunnel ingress within the PCN region,
> the RFC6040 behaviour will propagate any previously applied PCN markings
> into the outer, which is the desired behaviour (esp. for Excess-Rate
> marking, which depends on any marking applied earlier in the PCN region).
>
> Does that remove your concern?
>
>
> Bob
>
>
> At 01:24 12/03/2011, Tom Taylor wrote:
>> I can see how the ingress marking rules in RFC 6040 help for
>> inter-domain operation of PCN, but they seem hostile to the operation
>> of PCN in a single domain. Reproducing Figure 3 from RFC 6040, we have:
>>
>> +-----------------+-------------------------------+
>> | Incoming Header | Departing Outer Header |
>> | (also equal to +---------------+---------------+
>> | departing Inner | Compatibility | Normal |
>> | Header) | Mode | Mode |
>> +-----------------+---------------+---------------+
>> | Not-ECT | Not-ECT | Not-ECT |
>> | ECT(0) | Not-ECT | ECT(0) |
>> | ECT(1) | Not-ECT | ECT(1) |
>> | CE | Not-ECT | CE |
>> +-----------------+---------------+---------------+
>>
>> Figure 3: New IP in IP Encapsulation Behaviours
>>
>> If I look at Table 1 from RFC 5696, I see:
>>
>> +---------------+-------------+-------------+-------------+---------+
>> | ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) |
>> | | (00) | | | |
>> +---------------+-------------+-------------+-------------+---------+
>> | DSCP n | not-PCN | NM | EXP | PM |
>> +---------------+-------------+-------------+-------------+---------+
>>
>> Table 1: Encoding PCN in IP
>>
>> CL uses the EXP codepoint to mean "threshold-marked". So what RFC 6040
>> seems to be saying is that if someone upstream is using the ECN nonce
>> and an ECT(1)-marked packet arrives at the PCN-domain boundary, PCN
>> has to admit the tunneled packet as threshold-marked from the outset
>> or give it a different DSCP from PCN.
>>
>> Am I missing something?
>>
>> Tom Taylor
>>
>
> ________________________________________________________________
> Bob Briscoe, BT Innovate & Design
>

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 13 Mar 2011 21:04:33 +0000

Tom,

Yes, the idea is that the things with alternate semantics have to put 
in the work to say how best to achieve the alternate semantics in the 
presence of tunnels, while any vanilla tunnel should 'just work' by 
doing what RFC6040 says.

Bob

At 20:29 13/03/2011, Tom Taylor wrote:
>This does meet my concern, thanks. The thought flitted through my 
>mind that this is how things would work. I will have to make sure 
>the language of the CL and SM drafts reflects this behaviour. That 
>will probably satisfy David's comments on the subject of ECN.
>