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

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Apr 2011 10:12:05 +0100

Michael,

At 23:44 21/03/2011, Michael Menth wrote:
>Hi Bob,
>
>Am 21.03.2011 22:39, schrieb Bob Briscoe:
>>Michael,
>>
>>At 16:50 21/03/2011, Michael Menth wrote:
>>>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.
>>
>>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).
>
>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.

OK. Who has the editing token?

>>>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.
>>
>>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).
>
>This is just a citation from the encoding comparison draft. If you 
>find this is wrong, you need to update that draft.

Whoever has the editing token for encoding comparison, please ack 
that this is noted.

>>>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.
>>
>>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 [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.
>>
>>"
>>>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.
>>
>>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.
>
>Good that we have that there! Something along these lines should 
>also be mentioned in the 3-in-1 encoding draft.

I've suggested that we use the classification you sent while 
reviewing the 3-in-1 slides (off list) of all the possible 
combinations of ECN, PCN etc and give precise text on what we 
recommend in each case for e2e ECN preservation.

>>>3)
>>>
>>>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.
>
>Do you mean that the compatibility mode is backward-compatible to 
>the previous limited functionality mode?

Quoting RFC6040, S4.3:
"
    To comply with this specification, a tunnel ingress MUST at least
    implement normal mode.  Unless it will never be used with legacy
    tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the limited
    functionality mode of RFC 3168), an ingress MUST also implement
    compatibility mode for backward compatibility with tunnel egresses
    that do not propagate explicit congestion notifications [RFC4774].
"

IOW, it's for backward-compatibility with all those previous RFCs in 
the parenthesis, not just limited functionality mode of 3168.

Cheers

Bob

>Best wishes,
>
>     Michael
>
>
>>
>>Cheers
>>
>>
>>
>>Bob
>>
>>
>>
>>>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
>>
>>________________________________________________________________
>>Bob Briscoe,                                BT Innovate & Design
>
>
>--
>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]>mailto:[email-masked]
>http://www-kn.informatik.uni-tuebingen.de

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 1 Apr 2011 11:41:25 +0100

OK, I think I unpicked which bits were from Bob's latest reply! As this
seems to be determined to be an HTML email it is getting into a bit of a
mess.

Inline marked {TM}

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob
Briscoe
Sent: 01 April 2011 10:12
To: Michael Menth
Cc: [email-masked]
Subject: Re: [PCN] Some more issues regarding 3-in-1 encoding

Michael,

Hi Bob,

Michael,

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:

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.

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.

" 

severe PCN-mark than threshold-marked. Choosing a severity ranking
avoids

 * 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).

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.

{TM} I think I had it last...

2)

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).

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

Whoever has the editing token for encoding comparison, please ack that this
is noted.

{TM} Again, that was me, although Georgios did the actual posting. I would
rather defer this to Georgios though

Second, before

" 

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
[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.

"

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.

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.

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

I've suggested that we use the classification you sent while reviewing the
3-in-1 slides (off list) of all the possible combinations of ECN, PCN etc
and give precise text on what we recommend in each case for e2e ECN
preservation.

{TM} which is I guess what is in Michael's parallel email thread.

3)

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.

{TM} Incidentally, I meant to say that I think compatibility mode is the
correct term and reasonably self-explanatory - it is the mode that is
compatible with all forms of tunnelling (not backward compatible, actually
compatible).

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

Quoting RFC6040, S4.3:
"

   To comply with this specification, a tunnel ingress
MUST at least
   implement normal mode.  Unless it will never be used
with legacy
   tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the
limited
   functionality mode of RFC 3168), an ingress MUST also
implement
   compatibility mode for backward compatibility with tunnel
egresses
   that do not propagate explicit congestion notifications
[RFC4774].

"

IOW, it's for backward-compatibility with all those previous RFCs in the
parenthesis, not just limited functionality mode of 3168.

Cheers

Bob

Best wishes,

    Michael

Cheers

Bob

Best wishes,

    Michael

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

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