Subject: [PCN] Some more issues regarding 3-in-1 encoding

From: Michael Menth <[email-masked]>
Date: Mon, 21 Mar 2011 17:50:08 +0100

Hi Bob,

1)

When reading the encoding comparison draft, I found some useful 
information that should be added to the 3-in-1-draft after Section 3.2 
in form of an own section to argue that ETM must be more severe than 
ThM. I propose the following text which may also be added in different 
words:

Requirements Imposed by New Tunneling Rules [RFC6040]

RFC6040 provides for new tunneling rules so that the codepoint of an 
outer header
ECN field are propagated correctly into the inner header ECN field upon 
decapsulation.
The assumption is that a packet was re-marked to ECT(1) or to CE. Upon 
encapsulation
within a PCN domain, the codepoint of the inner header ECN field is 
copied to the
outer header PCN field using the normal mode. Upon decapsulation, a CE 
codepoint in
the outer header overwrites a ECT(1) codepoint in the inner header, but 
not vice-versa.
Hence, re-marking to CE always survives while re-marking to ECT(1)
survives only if the inner packet header is not CE. Hence, CE must be a 
more severe
marking than ECT(1) so that outer header markings can always propagated 
to the
inner header upon decapsulation.

2)

Do we have that somewhere in the standards?

    The re-use of the ECN field for PCN encoding has some impact on the
    deployment of PCN.  First, routers within a PCN domain must not apply
    ECN re-marking when the ECN field has PCN semantics.  Second, before
    a PCN packet leaves the PCN domain, the egress nodes must either (A)
    reset the ECN field of the packet to the contents it had when
    entering the PCN domain or (B) reset its ECN field to not-ECT.
    According to Section 3.3.3, tunneling ECN traffic through a PCN
    domain may help to implement (A).  When (B) applies, CE-marked
    packets must never become PCN packets within a PCN domain as the
    egress node resets their ECN field to not-ECT.  The ingress node may
    drop such traffic instead.

I already wrote an email that handling of ECN traffic should be 
discussed in the encoding draft. Do we also have the information 
somewhere that CE packets need to be dropped when the PCN-egress-node 
cannot restore the CE codepoint? This is important and should be added 
either to the encoding drafts or to the edge behavior drafts. If this is 
added to the encoding drafts, we need an update of RFC5696 unless the 
information is already there.

3)

Why have you chosen the name "compatibility mode" in RFC6040?

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: Mon, 21 Mar 2011 18:45:25 -0000

I would be REALLY cautious about spelling out details of RFC6040 within this
standard. It introduces a risk that you end up creating contradictions if
and when either standard is updated. I would prefer just to make it clear
that RFC6040 is a requirement for this standard.

I also worry that we are going to end up adding huge amounts of extra
information to this standard that is either replicated elsewhere or just
serves to confuse things. I know you are always very keen to leave no
possible ambiguity in anyone's mind, which is laudable, but equally if you
put too much detail in you end up confusing other people.

Where standards are concerned I am a great believer in the idea that "less
is more".

More inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: 21 March 2011 16:50
> To: Bob Briscoe; [email-masked]
> Subject: [PCN] Some more issues regarding 3-in-1 encoding
> 
> Hi Bob,
> 
> 1)
> 

I don't mind having a sentence or two about this, but adding in a whole
section is too much, not least as it effectively just spells out what
RFC6040 says anyway... We mustn't spoon feed developers - they are perfectly
capable of looking up a reference if we tell them that it is a co-dependent
standard

>     drop such traffic instead.

Have a look at appendix B of RFC5696. I /think/ that covers it

> Why have you chosen the name "compatibility mode" in RFC6040?

I assumed that was because that mode is compatible with all previous
standards (albeit only because it clears the header).

Toby

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2011 21:39:28 +0000

Michael,

At 16:50 21/03/2011, Michael Menth wrote:
>information that should be added to the 3-in-1-draft after Section 
>3.2 in form of an own section to argue that ETM must be more severe 
>than ThM. I propose the following text which may also be added in 
>different words:
>
>ECN field are propagated correctly into the inner header ECN field 
>upon decapsulation.
>The assumption is that a packet was re-marked to ECT(1) or to CE. 
>Upon encapsulation
>outer header PCN field using the normal mode. Upon decapsulation, a 
>CE codepoint in
>the outer header overwrites a ECT(1) codepoint in the inner header, 
>but not vice-versa.
>survives only if the inner packet header is not CE. Hence, CE must 
>be a more severe
>marking than ECT(1) so that outer header markings can always propagated to the

Yes. And I'm sure we can write this more succinctly. It should go at 
the end of S.3.1. Here's a suggestion:

OLD TEXT:
"  Therefore, a fourth PCN
    marking state indicating that a packet is marked by both markers is
    not needed.  However a fourth codepoint is required to indicate
    packets that are not PCN-capable (the not-PCN codepoint).

    In all current PCN edge behaviors that use two marking schemes
    [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
    is configured with a larger reference rate than threshold-marking.
    We take this as a rule and define excess-traffic-marked as a more
    severe PCN-mark than threshold-marked.
"

NEW TEXT:This specification defines excess-traffic-marked as a more 
severe PCN-mark than threshold-marked. Choosing a severity ranking 
avoids the need for a fourth codepoint to indicate that a packet is 
marked by both markers. However a fourth codepoint is required to 
indicate packets that are not PCN-capable (the not-PCN codepoint).

This severity ordering was chosen to be compatible with other 
existing documents:

  * In all current PCN edge behaviors that use two marking schemes
    [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
    is configured with a larger reference rate than threshold-marking.

  * In the specification that defines propagation of the ECN field 
through tunnel endpoints [RFC6040], CE is defined as more severe than 
ECT(1) and ECT(1) is defined as the same or greater severity than ECT(0).
>    ECN re-marking when the ECN field has PCN semantics.

RFC3168 (ECN marking) deliberately leaves the precise definition of 
the AQM algorithm open. Therefore there's no reason why an ECN AQM 
algorithm couldn't be similar to a PCN algorithm. Therefore, we 
shouldn't say that ECN AQM cannot be used as the algo for PCN-enabled 
packets, because an ECN algo might already be identical to a PCN algo.

Also, one of the reasons for trying to keep PCN encoding similar to 
ECN was so that ECN routers could be used reasonably safely in a PCN 
domain (e.g. if they couldn't do PCN, or if they were accidentally 
deployed without configuring them to recognise the Diffserv codepoint 
that triggered PCN treatment).

>Second, before

S.4.2 of the baseline encoding [RFC5696] already says:

"  A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
    packets it forwards out of the PCN-domain.  The only exception to
    this is if the PCN-egress-node is certain that revealing other
    codepoints outside the PCN-domain won't contravene the guidance given
    in [<http://tools.ietf.org/html/rfc4774>RFC4774].  For instance, 
if the PCN-ingress-node has explicitly
    informed the PCN-egress-node that this flow is ECN-capable, then it
    might be safe to expose other codepoints.
"

>somewhere that CE packets need to be dropped when the 
>PCN-egress-node cannot restore the CE codepoint? This is important 
>and should be added either to the encoding drafts or to the edge 
>behavior drafts. If this is added to the encoding drafts, we need an 
>update of RFC5696 unless the information is already there.

See Appx B of the Baseline Encoding [RFC5696], which gives four 
potential ways for the egress to avoid zeroing an ECN field that was 
originally CE at the ingress.

>Why have you chosen the name "compatibility mode" in RFC6040?

It is a mode of the tunnel ingress to allow it to be compatible with 
a tunnel egress compliant with earlier tunnelling specs. I suppose 
strictly it should have been backward-compatibility mode, but it was shorter.

Cheers

Bob

>     Michael

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Menth <[email-masked]>
Date: Mon, 21 Mar 2011 23:44:49 +0100

Hi Bob,

Am 21.03.2011 22:39, schrieb Bob Briscoe:
>> survives only if the inner packet header is not CE. Hence, CE must be 
>> a more severe
> Therefore, a fourth PCN
> severe PCN-mark than threshold-marked. Choosing a severity ranking avoids
> the need for a fourth codepoint to indicate that a packet is marked by
> both markers. However a fourth codepoint is required to indicate packets
> that are not PCN-capable (the not-PCN codepoint).
>
> This severity ordering was chosen to be compatible with other existing
> documents:
>

This is probably better than before, but does not say why the ECT(1)=ETM 
and CE=ThM wouldn't work. If you had mentioned that argument to me many 
months ago, I had understood much faster that the severity order is not 
just an arbitrary constraint but a necessity. Therefore, I find it 
useful explaining this. We could have saved lots of discussion and it is 
unfortunate if that reasoning gets lost. But if you are certain that his 
is not appropriate/useful for the draft, I accept.

> that triggered PCN treatment).

This is just a citation from the encoding comparison draft. If you find 
this is wrong, you need to update that draft.

>    A PCN-egress-node SHOULD set the not-PCN (00) codepoint
> on all
>     in
> [RFC4774  <http://tools.ietf.org/html/rfc4774>].  For
> instance, if the PCN-ingress-node has explicitly
>> cannot restore the CE codepoint? This is important and should be 
>> added either to the encoding drafts or to the edge behavior drafts. 
>> If this is added to the encoding drafts, we need an update of RFC5696 
>> unless the information is already there.
>

Good that we have that there! Something along these lines should also be 
mentioned in the 3-in-1 encoding draft.

> It is a mode of the tunnel ingress to allow it to be compatible with a 
> tunnel egress compliant with earlier tunnelling specs. I suppose 

Do you mean that the compatibility mode is backward-compatible to the 
previous limited functionality mode?

Best wishes,

     Michael

>> <http://www-kn.informatik.uni-tuebingen.de/>
>