Subject: [PCN] Effect of RFC 6040 on PCN

From: Tom Taylor <[email-masked]>
Date: Fri, 11 Mar 2011 21:02:48 -0500

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

---

From: Michael Menth <[email-masked]>
Date: Sun, 13 Mar 2011 14:11:44 +0100

Hi Tom and all,

from my perspective ECN support MUST ends at a PCN ingress as the PCN 
ingress sets NM in all packets. The exception is when tunneling is used. 
Then packets are tunnelled from the ingress to the egress in the 
compatibility mode, then the ingress set NM in the packets, the egress 
resets Not-ECT, and decapsulates according to the compatibility mode. 
That's how I understand it. But as far as I know, this is nowhere 
explicitly described and I am not sure either whether other people share 
my view.

Best wishes,

     Michael

Am 12.03.2011 03:02, schrieb Tom Taylor:
> 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:
>
> 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
>
>
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
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: Bob Briscoe <[email-masked]>
Date: Sun, 13 Mar 2011 21:35:11 +0000

Michael,

Did my response to Tom (in the offlist email he cc'd to the list) 
change your view?

Basically, if PCN boundary nodes create a tunnel, they should create 
a Normal mode tunnel logically outside the PCN region.

As long as the PCN ingress function sets the outer header to NM after 
the tunnelling function has been run, it doesn't actually matter 
whether the tunnel ingress was Normal mode or Compatibility mode.

However, compatibility mode of RFC6040 isn't necessary here - it's 
only intended for special cases and a PCN node wouldn't even need to 
implement it.

The idea of RFC6040 is that one standard module of tunnel code should 
serve all tunnelling purposes, including for a PCN ingress.

Bob

At 13:11 13/03/2011, Michael Menth wrote:
>Hi Tom and all,
>
>from my perspective ECN support MUST ends at a PCN ingress as the 
>PCN ingress sets NM in all packets. The exception is when tunneling 
>is used. Then packets are tunnelled from the ingress to the egress 
>in the compatibility mode, then the ingress set NM in the packets, 
>the egress resets Not-ECT, and decapsulates according to the 
>compatibility mode. That's how I understand it. But as far as I 
>know, this is nowhere explicitly described and I am not sure either 
>whether other people share my view.
>
>Best wishes,
>
>     Michael
>
>>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:
>>
>>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: Michael Menth <[email-masked]>
Date: Mon, 14 Mar 2011 08:06:53 +0100

Hi Bob,

Am 13.03.2011 22:35, schrieb Bob Briscoe:
> Basically, if PCN boundary nodes create a tunnel, they should create a 
> Normal mode tunnel logically outside the PCN region.
>
Correct.

> serve all tunnelling purposes, including for a PCN ingress.
The prerequisite for the system to work is that the egress node resets 
the outer header codepoints to not-ECT and then decapsulation 
automatically restores the original ECN codepoints according to 
http://tools.ietf.org/html/rfc6040#section-4.2 Is it that? That's just 
my assumption, but I haven't seen it anywhere spelled out.

Or is resetting to NM also an option? RFC6040 marks some relevant fields 
with (!) and (!!!). I do not understand what the decapsulation rules in 
http://tools.ietf.org/html/rfc6040#section-7 want to tell me for PCN.

Best wishes,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 11:07:01 +0000

Michael,

At 07:06 14/03/2011, Michael Menth wrote:
>>The idea of RFC6040 is that one standard module of tunnel code 
>>should serve all tunnelling purposes, including for a PCN ingress.
>The prerequisite for the system to work is that the egress node 
>resets the outer header codepoints to not-ECT and then decapsulation 
>http://tools.ietf.org/html/rfc6040#section-4.2 Is it that? That's 
>just my assumption, but I haven't seen it anywhere spelled out.

That's correct. It's not spelled out anywhere, because RFC6040 isn't 
the right place to have any specific text about PCN, and no PCN docs 
about supporting e2e ECN have yet been written since RFC6040.

I'm not sure where the best place is now to write about e2e ECN. I 
guess we could add it to pcn-3-in-1-encoding to show how it can 
support e2e ECN as well.

>Or is resetting to NM also an option? RFC6040 marks some relevant 
>fields with (!) and (!!!).

Superficially, the PCN egress resetting to NM and Not-ECT both look 
like they would work the same (the two columns look similar in Fig 
4). However, the less obvious differences make resetting to NM 
incorrect, for 2 reasons:
    i) it's not logically correct for the PCN egress to indicate in 
packets to a subsequent tunnel egress that the outer supports ECN but 
there has been no ECN marking (which is what NM means).
    ii) in practice, this could lead the tunnel egress to raise 
alarms where there are (!!!) symbols, which in turn might lead it to 
drop such packets.

[[[BTW, it would also be possible to 'leak' PCN markings to the 
destination endpoint by:
- deploying a 6040 tunnel around the PCN region
- at PCN ingress, resetting the outer ECN field to NM
- at PCN egress, leaving the outer ECT field unchanged (not resetting it).
This would allow adaptive codecs to know when to adapt, but still 
remove any pre-existing ECN markings at the PCN ingress so they don't 
confuse admission control or flow termination.
]]]

>I do not understand what the decapsulation rules in 

Well, S.7 doesn't need to say anything for PCN. An RFC6040 tunnel is 
designed to work for most cases (including PCN) as is. So PCN doesn't 
need alternate ECN tunnelling semantics.

However S.7 should describe the principles by which a RFC6040 tunnel 
is designed. So it should be relevant to PCN. Perhaps it will help to 
bear in mind that there are two ways tunnels might impact PCN:
- PCN has to propagate correctly through arbitrary tunnel endpoints 
that might be deployed within a PCN-region (the focus of RFC6040)
- an operator might deliberately set up a tunnel to insulate a PCN 
region from e2e ECN.

In the latter case, a PCN spec can just use an RFC6040 tunnel in a 
certain configuration (as already discussed in this email) to achieve 
the desired insulation from e2e ECN. That has to be described in a 
PCN document.

RFC6040 describes the behaviour of a tunnel, so it can be used. It 
doesn't do the reverse: describe all the possible ways RFC6040 
tunnels might be used because of how they have been designed to behave.

Cheers

Bob

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 14 Mar 2011 12:07:05 +0100

Hi Michael

I think that the reply of Bob in a previous emails might solve your concern,
see below:

--------------

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

-----------------

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: maandag 14 maart 2011 8:07
> To: Bob Briscoe
> Cc: [email-masked]
> Subject: Re: [PCN] Effect of RFC 6040 on PCN
> 
> Hi Bob,
> 
> The prerequisite for the system to work is that the egress 
> node resets the outer header codepoints to not-ECT and then 
> decapsulation automatically restores the original ECN 
> codepoints according to
> http://tools.ietf.org/html/rfc6040#section-4.2 Is it that? 
> That's just my assumption, but I haven't seen it anywhere spelled out.
> 
> Or is resetting to NM also an option? RFC6040 marks some 
> relevant fields with (!) and (!!!). I do not understand what 
> the decapsulation rules in

---

From: Michael Menth <[email-masked]>
Date: Mon, 14 Mar 2011 16:09:37 +0100

Hi Bob,

> about supporting e2e ECN have yet been written since RFC6040.

Yes, sure. That's the job of PCN documents, which is still to be done, 
right?

> guess we could add it to pcn-3-in-1-encoding to show how it can 

I also think so.

> like they would work the same (the two columns look similar in Fig 4). 
> However, the less obvious differences make resetting to NM incorrect, 
> for 2 reasons:
>    ii) in practice, this could lead the tunnel egress to raise alarms 
> where there are (!!!) symbols, which in turn might lead it to drop 
> such packets.

That means that the PCN egress must generally reset codepoints to 
not-ECN. If the PCN egress node is a tunnel endpoint, it then 
decapsulates the traffic and thereby restores original codepoints. This 
is plausible and works the way I always supposed. But it needs to be 
written down somewhere. I think 3-in-1 encoding is a good place, in 
particular as it requires RFC6040 (which is in contrast to baseline 
encoding.)

> confuse admission control or flow termination.

Yes, but that's a different story as it requires additional signalling 
to tell the PCN egress that the receiver is able to correctly interpret 
the signals. True?

> the desired insulation from e2e ECN. That has to be described in a PCN 
> document.

100% agree

> doesn't do the reverse: describe all the possible ways RFC6040 tunnels 
> might be used because of how they have been designed to behave.

I never expected that.

Best wishes,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 17:55:42 +0000

Michael,

At 15:09 14/03/2011, Michael Menth wrote:
>>remove any pre-existing ECN markings at the PCN ingress so they 
>>don't confuse admission control or flow termination.
>>]]]
>
>Yes, but that's a different story as it requires additional 
>signalling to tell the PCN egress that the receiver is able to 
>correctly interpret the signals. True?

Actually, thinking about it, maybe it doesn't require additional 
signalling. If the receiver cannot interpret ECN, then it won't 
adapt. If it can it will. There's no harm leaking out the signals in 
case the receiver understands.

Whether or not the receiver adapts, PCN will still do admission 
control & flow termination.

Bob

---

From: Michael Menth <[email-masked]>
Date: Mon, 14 Mar 2011 23:56:03 +0100

Hi Bob,

Am 14.03.2011 18:55, schrieb Bob Briscoe:
> signalling. If the receiver cannot interpret ECN, then it won't adapt. 
This is against the spirit of RFC4774 because not-ECT can become ECT(0), 
ECT(1), or CE without the receiver being able to react appropriately.

> If it can it will. There's no harm leaking out the signals in case the 
> receiver understands.
Yes, that's true. If CE results only from excess-traffic-marking, 
applications would back off in such a situation like otherwise only 
under imminent congestion or during congestion. That's certainly an 
interesting point to be studied. If CE results from threshold marking, 
then this is a very severe congestion signal that hits all admitted 
connections, I don't think this will provide desirable results.

Best wishes,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 23:56:06 +0000

Michael,

At 22:56 14/03/2011, Michael Menth wrote:
>This is against the spirit of RFC4774 because not-ECT can become 
>ECT(0), ECT(1), or CE without the receiver being able to react appropriately.

By additional signalling, I thought you meant for the endpoints to 
signal to the PCN edge nodes that they were rate adaptive. I was just 
meaning they wouldn't need to do this, because a transport that can't 
adapt is not much different from a rate adaptive node that chooses 
not to adapt. Either way, if the transport doesn't adapt, the PCN 
mechanism has force majeure with admission control or flow termination.

I didn't mean it would leak PCN if the inner was Not-ECT. The tunnel 
arrangement described would ensure that didn't happen.

>>If it can it will. There's no harm leaking out the signals in case 
>>the receiver understands.
>interesting point to be studied. If CE results from threshold 
>marking, then this is a very severe congestion signal that hits all 
>admitted connections, I don't think this will provide desirable results.

Just because it's a step increase in marking doesn't mean it needs a 
huge decrease in rate to remove the condition. The important 
parameter is how much excess traffic there is, not how much marking there is.

If a severe congestion signal hits all connections, they might all 
adapt and remove the congestion condition before anyone needs to be 
admission controlled. Even if only some adapt, it may alleviate 
congestion sufficiently.

Bob

---

From: Michael Menth <[email-masked]>
Date: Tue, 15 Mar 2011 08:43:38 +0100

Hi Bob,

Am 15.03.2011 00:56, schrieb Bob Briscoe:
> adapt is not much different from a rate adaptive node that chooses not 
> to adapt. Either way, if the transport doesn't adapt, the PCN 

Ok, now I understand what you mean. You take the tunnel mechanism and 
the still non-defined fields marked with (!!!) in 
http://tools.ietf.org/html/rfc6040#section-4.2 to assure that not-ECT 
packets leave the PCN domain with not-ECT. That works. Without 
tunnelling that wouldn't work. Clever!

> huge decrease in rate to remove the condition. The important parameter 
> is how much excess traffic there is, not how much marking there is.
>

I think that's interesting. Let's see what we can do.

Best wishes,

     Michael