Subject: Re: [PCN] ECN handling with 3-in-1

From: Michael Menth <[email-masked]>
Date: Fri, 01 Apr 2011 10:36:32 +0200

Hi all,

to quickly see that the case analysis is complete, I suggest a slight 
rewording:

Handling of ECN traffic
* ECN traffic not being subject to PCN control and not sharing a 
PCN-compatible DSCP
     - no action needed
* ECN traffic not being subject to PCN control and sharing a 
PCN-compatible DSCP
     - ingress tunnels that traffic with an non-PCN-compatible DSCP in 
the outer header (any tunnel may be used)
     - alternative: ingress maps the DSCP to a local DSCP and egress 
re-maps it to the original PCN-compatible DSCP
     - alternative: ingress tunnels that traffic with not-PCN in the 
outer header (any tunnel may be used); note that this turns of ECN for 
this traffic within the PCN domain.
* ECN traffic being subject to PCN control
     - ingress drops CE-marked packets and egress zeros ECN field of PCN 
packets which disables end-to-end ECN
     - alternative: ingress tunnels that traffic with a PCN-compatible 
DSCP in the outer header and the egress zeros ECN-field before 
decapsulation (any tunnel may be used)
* ECN traffic being subject to PCN control, and the receiver has 
indicated to receive PCN marks
     - ingress tunnels that traffic with a PCN-compatible DSCP but the 
egress SHOULD NOT zero the ECN field before decapsulation according to 
RFC6040 normal mode; note that this may turn ECT(0) into ECT(1) so that 
the nonce is modified.

Another two questions
* Traffic may arrive with a non-PCN-compatible DSCP and is subject to 
PCN control. Do we care about the original DSCP? This seems to be a 
similar issue.
* How is the ECN-field of traffic with a PCN-compatible DSCP interpreted 
outside a PCN domain? I guess with ECN semantics? Have we stated that 
somewhere. Do we need to state it?

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: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 01 Apr 2011 10:01:25 +0000

Hi Michael

If we need to define the actions, then these actions should be in line
with Section 3.6 of RFC5559:
-----------------
3.6.  Backwards Compatibility

   PCN specifies semantics for the ECN field that differ from the
   default semantics of [RFC3168].  A particular PCN encoding scheme
   needs to describe how it meets the guidelines of BCP 124 [RFC4774]
   for specifying alternative semantics for the ECN field.  In summary,
   the approach is to:

   o  use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses
      the alternative ECN semantics;

   o  define these semantics for use within a controlled region, the
      PCN-domain;

   o  take appropriate action if ECN-capable, non-PCN-traffic arrives at
      a PCN-ingress-node with the DSCP used by PCN.

   For the baseline encoding [Moncaster09-1], the "appropriate action"
   is to block ECN-capable traffic that uses the same DSCP as PCN from
   entering the PCN-domain directly.  "Blocking" means it is dropped or
   downgraded to a lower-priority behaviour aggregate, or alternatively
   such traffic may be tunnelled through the PCN-domain.  The reason
   that "appropriate action" is needed is that the PCN-egress-node
   clears the ECN field to 00.

   Extended encoding schemes may need to take different "appropriate
   action".
----------------

Can you please emphasize how the proposed actions satsifiy the above
requirements taken from Section 3.6 of RFC5559?

Best regards,
Georgios

On 4/1/2011, "Michael Menth" <[email-masked]> wrote:

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

---

From: Michael Menth <[email-masked]>
Date: Fri, 01 Apr 2011 13:38:34 +0200

Hi Georgios,

> with Section 3.6 of RFC5559:
The proposed actions either restore the original ECN-field at the PCN 
egress node or they avoid that packets which were CE-marked before 
entering the PCN-domain do not leave the PCN-domain without a CE-mark. 
In the most extreme cases, CE-marked packets are dropped when entering a 
PCN domain.

Michael

> Best regards,
> Georgios
>
> On 4/1/2011, "Michael Menth"<[email-masked]>  wrote:
>
>> Hi all,
>>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Apr 2011 13:22:11 +0100

Michael,

At 09:36 01/04/2011, Michael Menth wrote:
>Hi all,
>
>to quickly see that the case analysis is complete, I suggest a 
>slight rewording:
>
>Handling of ECN traffic
>     - ingress tunnels that traffic with an non-PCN-compatible DSCP 
> in the outer header (any tunnel may be used)
> outer header (any tunnel may be used); note that this turns of ECN 
> for this traffic within the PCN domain.

We ought to recommend one:
#2 does nothing wrong, whereas the others do, to a certain extent.
THe only reason for using #3 would be if you are short of DSCPs (e.g. 
MPLS or Ethernet).
#1 changes the PHB, whereas #2 doesn't and is otherwise the same. So 
#1 can be chucked.

>     - ingress drops CE-marked packets and egress zeros ECN field of 
> PCN packets which disables end-to-end ECN

Not recommended

>     - alternative: ingress tunnels that traffic with a 
> PCN-compatible DSCP in the outer header and the egress zeros 
> ECN-field before decapsulation (any tunnel may be used)

recommended

>     - ingress tunnels that traffic with a PCN-compatible DSCP but 
> the egress SHOULD NOT zero the ECN field before decapsulation 
> according to RFC6040 normal mode; note that this may turn ECT(0) 
> into ECT(1) so that the nonce is modified.

Good point.
This needs to be clearly flagged as an experimental only scheme.

>Another two questions
>* Traffic may arrive with a non-PCN-compatible DSCP and is subject 
>to PCN control. Do we care about the original DSCP? This seems to be 
>a similar issue.

Similar to what?

>* How is the ECN-field of traffic with a PCN-compatible DSCP 
>interpreted outside a PCN domain? I guess with ECN semantics? Have 
>we stated that somewhere. Do we need to state it?

Dunno whether we've said this somewhere. Will need to check.

Bob

>     Michael

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 1 Apr 2011 14:58:03 +0100

I'm not sure if I captured all the changes we intend to do on this draft:

1) add Michael's text on e2e ECN (once it has become stable)

2) add a brief paragraph explaining that this effectively updates RFC5696
and that therefore anyone running experiments with that are on their own
(which they kind of are anyway, if they are doing an experiment!).

3) clarify how to do single marking with this encoding.

I now recall the real reason why I wanted to preserve baseline which is that
this encoding has the RFC6040 dependency.

Is there any mileage in exploring a bis for RFC5696? As I see it we are
always going to have a slightly messy situation. For instance I am not sure
if you are allowed the circular dependency of 3-in-1 encoding being
dependent on RFC5696 but also updating RFC5696. 

Of course we could always revive the option we discussed, where we obsolete
RFC5696 and incorporate a baseline behaviour within this draft (which could
then be called PCN encodings using a single DSCP)... 

Thoughts anyone?

Toby

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 01 April 2011 13:22
> To: Michael Menth
> Cc: Toby Moncaster; [email-masked]
> Subject: Re: [PCN] ECN handling with 3-in-1
> 
> Michael,
>

---

From: Michael Menth <[email-masked]>
Date: Sat, 02 Apr 2011 11:17:16 +0200

Hi Bob,

> #1 changes the PHB, whereas #2 doesn't and is otherwise the same. So 
Both #1 and #2 change the DSCP for transport within the PCN domain and 
restore the original DSCP at the egress; I assume that this is a DSCP 
outside the PHB of the PCN-compatible DSCP.
#3: the outer header has: PCN-compatible DSCP & not-ECT, so that the 
traffic is carried in the same PHB as admisison controlled traffic. Is 
that what we want to recommend? This makes AC less useful as other 
traffic for the same PHB can enter the network without AC.

>> decapsulation (any tunnel may be used)
What do you mean by not recommended?
1) Valid, but non-preferred option?
2) Should not be mentioned in the document?
My view is that we should offer a way to work without tunnels if possible.

>> egress SHOULD NOT zero the ECN field before decapsulation according 
>> to RFC6040 normal mode; note that this may turn ECT(0) into ECT(1) so 
>> that the nonce is modified.
>
> Good point.
We have the same issue for RFC6040 in general and probably for your 
current guidelines draft.

>> PCN control. Do we care about the original DSCP? This seems to be a 

Example: traffic that is subject to PCN control arrives at the ingress 
with a non-PCN-compatible DSCP. What should be done?
1) Ingress overwrites original DSCP with PCN-compatible DSCP -> original 
DSCP cannot be restored at the egress
2) Traffic is tunnelled with PCN-compatible DSCP across the PCN domain 
-> tunneling overhead

Other example: traffic that is not subject to PCN control arrives at the 
ingress with a PCN-compatible DSCP. What should be done?
1) do nothing -> the traffic is carried in the same PHB as admission 
controlled traffic; this makes admission control less useful
2) tunnel the traffic in a local DSCP and restore the original DSCP -> 
care must be taken that the local DSCP is carried with a PHB that is 
good enough

Do we need to address these issues? Maybe it's good to point out these 
options? Do we need to give a recommendation.

Regards,

     Michael

>> interpreted outside a PCN domain? I guess with ECN semantics? Have we 
>> stated that somewhere. Do we need to state it?
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 14 Apr 2011 11:53:42 +0100

I am trying to bash the ECN compatibility text into a usable appendix for
the document. This is what I have so far:

"Appendix A.  Co-existence of ECN and PCN (informative)

   The PCN encoding described in this document re-uses the bits of the
   ECN field in the IP header.  Consequently, this disables ECN within
   the PCN domain.  Appendix B of [RFC5696] included advice on handling
   ECN traffic within a PCN-domain.  This appendix clarifies that
   advice.

   ECN traffic not subjected to PCN control and not sharing a PCN-
   compatible DSCP: This requires no action.

   ECN traffic not subjected to PCN control but sharing a PCN-compatible
   DSCP: There are two options.

      *  The ingress maps the DSCP to a local DSCP and the egress re-
         maps it to the original PCN-compatible DSCP.

      *  The ingress tunnels the traffic, setting not-PCN in the outer
         header; note that this turns off ECN for this traffic within
         the PCN domain.

      The first option is recommended unless you are short of local
      DSCPs.

   ECN traffic being subjected to PCN control:  There are two options.

      *  The ingress places this traffic in a tunnel with a PCN-
         compatible DSCP in the outer header.  The egress zeroes the
         ECN-field before decapsulation.

      *  ingress drops CE-marked packets and egress zeros ECN field of
         PCN packets which disables end-to-end ECN.

      The second option is not recommended.

   ECN traffic being subjected to PCN control, receiver indicates desire
   to see PCN marks: 

      Schemes have been suggested where PCN marks may be leaked out of
      the PCN-domain and used by the end hosts to modify realtime data
      rates.  Currently all such schemes are experimental and the
      following is for guidance only.

      The ingress needs to tunnel the traffic using [RFC6040].  The PCN-
      egress should not zero the ECN field, and the tunnel egress should
      use [RFC6040] normal mode (preserving any PCN-marking).  Note that
      this may turn ECT(0) into ECT(1) and so is not compatible with the
      experimental ECN nonce [RFC3540].

   In the list above any form of IP-in-IP tunnel can be used unless
   specified otherwise.  We assume a logical separation of tunneling
   and PCN actions in both PCN-ingress and PCN-egress nodes.  That is,
   any tunneling action happens wholly outside the PCN-domain as
   illustrated in the following figure:

                ,  .  .  .  .  PCN-domain  .  .  .  .  .  .  .
               .   ,--------.                   ,--------.    .
              .   _|  PCN-   |___________________|  PCN-  |_   .
              .  / | ingress |                   | egress | \  .
               .|  '---------'                   '--------'  |.
                | .  .  .  .  .  .  .  .  .  .  .  .  .  .  .|
           ,--------.                                     ,--------.
     _____| Tunnel  |                                     | Tunnel |____
          | Ingress | - - ECN preserved inside tunnel - - | Egress |
          '---------'                                     '--------'

             Figure 4: Separation of tunneling and PCN actions
"

I hope this captures all the key elements from the discussion.

I am still unsure exactly how we are proceeding with regards to updating
RFC5696. Can this document both update RFC5696 AND be dependent on it as
well? Currently I am thinking of adding the following as a standalone
section:

"Section N. Effect on baseline encoding

The baseline encoding [rfc5696] specified that the 01 codepoint was for use
in experimental schemes. It also gave guidelines for such experiments. This
document updates the 01 codepoint and fixes its meaning. Consequently this
document updates [rfc5696]. People wishing to use the 01 codepoint for
experimental schemes as described in [rfc5696] must accept the risk that
PCN-nodes compatible with this encoding scheme may not be compatible with
their experiment."

Two inline responses to Michael at the end

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Toby Moncaster
> Sent: 01 April 2011 14:58
> To: 'Bob Briscoe'; 'Michael Menth'
> Cc: [email-masked]

What Michael means is, if an operator chooses to change the DSCP of an
arriving packet in order to enable PCN for that packet, should that change
be reversed on leaving the PCN domain? This is starting to get rather
obscure. Appendix A.1 of RFC5696 discusses the choice of suitable DSCPs for
PCN and makes it clear that operators should choose to use an existing DSCP
providing suitable scheduling and priority. However, if an operator chooses
to define a local DSCP instead then they are free to do so. If I recall
right, DSCPs are not guaranteed to survive between domains anyway...

> > Dunno whether we've said this somewhere. Will need to check.

Is this at all relevant to PCN? I would argue we don't need to state this
anywhere at all since PCN semantics only apply inside a PCN-domain. IN
appendix A.1 of RFC5696 we make it clear that PCN is a marking behaviour for
use within the PCN-domain and discuss DSCP-related issues

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 15 Apr 2011 04:14:06 +0100

Toby,

>    ECN field in the IP header.  Consequently, this disables ECN within

s/Consequently,/Without additional measures,/

>Appendix B of [RFC5696] included advice on handling

s/clarifies/updates/

[I assume you will have some sort of lead in sentence to the list here]

>    DSCP:

s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on 
arrival at the PCN ingress/

>There are two options.

Good.

s/you are/the operator is/

>    ECN traffic being subjected to PCN control:

s/being subjected to/to be subjected to PCN control rather than ECN 
marking across the PCN domain/

>There are two options.

s/the ECN-field/the outer ECN-field/

>       The second option is not recommended.

No need to even mention it then, unless there's a compromise scenario 
where the 1st option wouldn't be suitable.

BTW, I don't see why the egress has to zero ECN, or indeed why this 
disables e2e ECN, unless it means it zero's the inner (and if so why?).

>       rates.

s/used by the end hosts to modify realtime data rates./
  /used by adaptive codecs in the end hosts to modify realtime data rates./

>Currently all such schemes are experimental and the
>       egress should not zero the ECN field,

Don't agree. ECN should never leak into PCN, but PCN might be OK to 
leak to ECN receiver.

Reasoning: admission of a flow should only depend on PCN marking 
within the PCN region. It shouldn't depend on ECN marking from queues 
outside the PCN region, which will not have been configured to give 
good signals at the right load levels.

The reverse argument seems less likely to apply to leaking PCN to 
receiver, because any decent level of PCN will usefully trigger a 
lower rate, thus potentially avoiding the need to block admissions.

>and the tunnel egress should
>       use [RFC6040] normal mode (preserving any PCN-marking).

There are no modes for an RFC6040 egress. Modes are only for the ingress.

The important point is not what the tunnel egress does (assuming the 
arrangement in the Fig below), but that the PCN egress doesn't zero 
the outer ECN field.

>Note that

s/this/PCN marking on interior nodes/

>                 ,  .  .  .  .  PCN-domain  .  .  .  .  .  .  .

nice ASCII art.

>PCN-nodes compatible with this encoding scheme may not be compatible with

It would be dangerous for me to respond to this now - I'm too tired 
to think straight. But my gut feeling is that the wording should lean 
more towards "updates", and less towards appearing to encourage more 
experimentation, which would run counter to interoperability - the 
raison d'etre of a standards body.

>Two inline responses to Michael at the end

One from me too...

>use within the PCN-domain and discuss DSCP-related issues

Given we are talking about e2e ECN support across a PCN domain, it 
would do no harm to reinforce the idea that a DSCP cannot even be 
considered PCN-compatible when it is outside a PCN domain - it has 
its usual scheulding PHB, but its congestion marking behaviour is the 
ECN default, not PCN.

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 15 Apr 2011 09:31:42 +0100

> Sent: 15 April 2011 04:14
> To: Toby Moncaster
> Cc: 'Toby Moncaster'; 'Michael Menth'; [email-masked]
> Subject: RE: [PCN] ECN handling with 3-in-1
> 
> Toby,
> 

Yes, but inspiration was proving elusive... 

> disables e2e ECN, unless it means it zero's the inner (and if so why?).

Surely the PCN-egress has to zero the ECN field before the packet is
decapsulated? Otherwise the decapsulator will transfer the PCN marking from
the PCN-domain onto the ECN packet...

> Don't agree. ECN should never leak into PCN, but PCN might be OK to

I'm not allowing ECN to leak into PCN. I am (in limited circumstances)
allowing the PCN-domain to over-write the ECN information and hence leak PCN
information to the receiver.

> good signals at the right load levels.

Oh, I think I see your point. RFC6040 tunnels will set the ECN of the outer
header to whatever is in the inner header. BUT you are forgetting that the
default behaviour of the PCN-ingress is to clear whatever is in the outer
header and set it to 10 (if the traffic is PCN) or 00 (if the traffic is
not-PCN)

> There are no modes for an RFC6040 egress. Modes are only for the

OK, noted. I did know that really, I was being careless.

> arrangement in the Fig below), but that the PCN egress doesn't zero

Indeed...

> >              Figure 4: Separation of tunneling and PCN actions

Thanks :)

> raison d'etre of a standards body.

OK, I can probably highlight that we are not recommending people start
experiments, but if they are already using the EXP codepoint for anything
else they need to be aware of this clash...

> > > and that therefore anyone running experiments with that are on
> their
> > > own
> > > I now recall the real reason why I wanted to preserve baseline
> which is
> > > that
> > > always going to have a slightly messy situation. For instance I am
> not
> > > sure
> > > RFC5696 and incorporate a baseline behaviour within this draft
> (which
> > > could

Would adding the following (in a suitable place) suffice?:

"PCN is in effect a congestion marking behaviour for use with realtime
traffic in a controlled domain. As such, within the PCN-domain, PCN marking
replaces ECN marking for any PCN-enabled DSCPs. Outside the PCN-domain, ECN
remains the default behaviour for all DSCPs."

Toby

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 12:01:57 +0200

Toby, Bob,

Am 15.04.2011 05:14, schrieb Bob Briscoe:
> s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on arrival 
> at the PCN ingress/
>
>> There are two options.
>>

I think we should leave the second option for networks in which 
tunneling does not work for which reasons ever.

> disables e2e ECN, unless it means it zero's the inner (and if so why?).
???

> It would be dangerous for me to respond to this now - I'm too tired to 
> think straight. But my gut feeling is that the wording should lean 

I still don't understand why it is not possible to have alternative 
standards as long as only one of them can be applied in a single or 
federated PCN domain.

>> right, DSCPs are not guaranteed to survive between domains anyway...

Mentioning that would be helpful just to point the reader to that issue.

> considered PCN-compatible when it is outside a PCN domain - it has its 
> usual scheulding PHB, but its congestion marking behaviour is the ECN 
> default, not PCN.

I just felt that this should be stated explicitly.

Anything else is fine.

Best wishes,

     Michael

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 12:04:24 +0200

Toby, Bob,

> header and set it to 10 (if the traffic is PCN) or 00 (if the traffic is

Mentioning that would be helpful. Also we need to remember that but 
often forget about it and then we wonder about the text ...

Regards,

     Michael

>>>>> Bob Briscoe,                                BT Innovate&  Design
>> Bob Briscoe,                                BT Innovate&  Design

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 13:19:41 +0200

Toby, Bob,

see inline

>        The first option is recommended unless you are short of local

What's wrong with this option?
     - ingress tunnels that traffic with an non-PCN-compatible DSCP in 
the outer header (any tunnel may be used); this does not turn off ECN 
within the PCN domain.

Regards,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 15 Apr 2011 12:43:50 +0100

> From: Michael Menth [mailto:[email-masked]]
> Sent: 15 April 2011 12:20
> To: Toby Moncaster
> Cc: 'Bob Briscoe'; [email-masked]

The problem is that it might change the PHB scheduling for those packets. We
want to avoid that if at all possible. Obviously an operator could choose to
use that approach, but we don't want to recommend things that have actual
negative impact.

Toby

> >> I now recall the real reason why I wanted to preserve baseline which
> is
> >> that

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 15 Apr 2011 15:50:44 +0100

Toby, Michael,

1/ We need to have a clearer think about the implications of putting 
"Updates 5696" in the header block. We ought to start another thread for that.

2/ e2e ECN appendix
Now that I'm awake, I've realised the wording of the headings for the 
four options we are discussing needs to be completely reframed.

End nodes don't ask for PCN control, they ask for admission control. 
An operator chooses what mechanism to use for admission control over 
their segment of the path, and PCN is just one possible mechanism 
they might choose.

At the outset, we need to list the two main ways that end-nodes tell 
the network that they need admission control, which in turn makes the 
PCN-ingress remark their traffic with a PCN-compatible DSCP:

A) flow signalling associates a filterspec with a need for admission 
control (e.g. thru RSVP or some equivalent message down from a SIP 
server to the ingress), and the PCN ingress remarks traffic matching 
that filterspec to a PCN-compatible DSCP, as its chosen admission 
control mechanism.

B) Traffic arrives with a DSCP that implies it requires admission 
control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, 
Broadcast TV when used for video on demand, and Multimedia 
Conferencing [RFC4594, RFC5865].

We need to define two phrases, such as:
* "Traffic that requires admission control" as traffic that uses 
either method A or B.
* "Traffic that does not require admission control" as traffic that 
uses neither of methods A or B.

THen inline below I suggest corrected text for each of the four headings.

3/ e2e ECN appendix
Otherwise, I think we've converged on the text within each heading. I 
have inserted comments inline to confirm the necessary wordsmithing...

>>Yes, but inspiration was proving elusive...

"There are a four possible cases for how e2e ECN traffic may wish to 
be treated while crossing a PCN domain:"

>>>>     compatible DSCP: This requires no action.

There is no such thing as a PCN-compatible DSCP for traffic arriving 
at a PCN ingress (a PCN-compatible DSCP is only defined within a PCN region).

We should head this item
"ECN capable traffic that does not require admission control and does 
not carry a DSCP that the PCN-ingress is using for PCN-capable traffic."

>>>arrival at the PCN ingress/

On second thoughts, we should head this item
"ECN capable traffic that does not require admission control but 
carries a DSCP that the PCN-ingress is using for PCN-capable traffic."

HOWEVER, I don't think this case is possible. If traffic arrives with 
a DSCP that would be used for PCN, it is signalling that it requires 
admission control [RFC5865].

>>>>           maps it to the original PCN-compatible DSCP.

s/local DSCP/local DSCP with the same scheduling PHB as the original DSCP/

>>>marking across the PCN domain/

We should head this item
"Traffic that requires admission control."

>>>>           PCN packets which disables end-to-end ECN.

s/ingress/PCN ingress/
s/egress/PCN egress/
delete/which disables end-to-end ECN/

>>>>        The second option is not recommended.

a/unless tunnelling is not possible for some reason./

>>the PCN-domain onto the ECN packet...

You're right - the PCN egress needs to zero the outer ECN.

But this doesn't disable e2e ECN, because it's still enabled in the 
inner, which any tunnel egress forwards unchanged, if the outer is Not-ECN.

>>>>     ECN traffic being subjected to PCN control, receiver indicates

We should head this item
"Traffic that requires admission control, where the e2e transport 
somehow indicates it wants to see PCN marks."

>>>>        The ingress needs to tunnel the traffic using [RFC6040].

insert/The PCN-ingress will by default set the outer ECN field to 
Not-marked and then/

Hope this all helps.

Bob

>>>>The
>>>PCN-

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 17:12:55 +0200

Hi Toby,

> use that approach, but we don't want to recommend things that have actual

That is right. And for exactly the same reason I think we should also 
mention that care must be taken when non-PCN-DSCP are changed to 
PCN-DSCP.  We do not need to limit the choices, but I think we should 
enumerate what's possible and where the caveats are.

Michael

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 17:20:52 +0200

Hi Bob, Toby,

> admission control [RFC5865].

Hey, this is only an assumption. So far we have avoided to say 
PCN=Voice-Admit. And as long as we don't say that, we must treat this case.

Regards,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 16 Apr 2011 09:54:44 +0100

Bob, Michael,

> Sent: 15 April 2011 15:51
> To: Michael Menth

Yes. Will try and compose one later today or tomorrow (as it's rather nice
weather today).

> Conferencing [RFC4594, RFC5865].

You need to re-read the appendix of RFC5696 where we discuss DSCP-related
issues. 

I am very unkeen to add so much extra text to what should be a simple
encoding document. This will end up making the appendix nearly as long as
the main document. I also have concerns that this sort of thing is really
architectural. This document isn't about telling operators which of their
traffic they should be doing admission control on. 

I would rather we just put a simple paragraph saying what you have in your
intro to this point: 

" End nodes don't ask for PCN control, they ask for admission control.
 An operator chooses what mechanism to use for admission control over
 their segment of the path, and PCN is just one possible mechanism
 they might choose."

> uses neither of methods A or B.

OK, happy to have those definitions, but we are going to find ourselves
tying knots as we try and talk about traffic that doesn't need admission
control but which shares the same DSCP...

> >>>>I am trying to bash the ECN compatibility text into a usable
> appendix
> >>>for
> >>>>     The PCN encoding described in this document re-uses the bits
> of
> >>>the

OK

> not carry a DSCP that the PCN-ingress is using for PCN-capable

OK, happy to have something like that

> admission control [RFC5865].

BUT some of that traffic may in fact be automatically admitted (because of
policy), hence it wouldn't use PCN...

My own view is this whole case needn't be mentioned because the traffic is
neither ECN nor PCN. If we were to list all negative cases we would get an
even longer appendix!

> s/local DSCP/local DSCP with the same scheduling PHB as the original

Fair point. I meant to add something like that.

> >>>>        *  ingress drops CE-marked packets and egress zeros ECN
> field
> >>>of

It makes the e2e ECN less E2E, but then ECN is pretty non-existent anyway
currently.

> somehow indicates it wants to see PCN marks."

s/"somehow indicates"/"signals that"

> 
> 
> 
> >>>>        Schemes have been suggested where PCN marks may be leaked
> out
> >>>of
> >>>    /used by adaptive codecs in the end hosts to modify realtime
> data
> >>>rates./
> >>>

I'll try and unravel all the changes and send a revised version by Monday...
It won't necessarily include all the suggestions (see the inline comment at
the top), and there is a chance I may miss a couple!

Toby

> >>>>        this may turn ECT(0) into ECT(1) and so is not compatible
> with
> >>>the
> >>>>     and PCN actions in both PCN-ingress and PCN-egress nodes.
> That
> >>>is,
> >>>>             ,--------.                                     ,------
> --.
> >>>>       _____| Tunnel  |                                     |
> Tunnel
> >>>|____
> >>>>            '---------'                                     '------
> --'
> >>>>RFC5696. Can this document both update RFC5696 AND be dependent on
> it
> >>>as
> >>>>in experimental schemes. It also gave guidelines for such
> experiments.
> >>>This
> >>>>document updates the 01 codepoint and fixes its meaning.
> Consequently
> >>>this
> >>>>PCN-nodes compatible with this encoding scheme may not be
> compatible
> >>>with
> >>>>their experiment."
> >>>>>Is there any mileage in exploring a bis for RFC5696? As I see it
> we
> >>>are
> >>>>>>>      - alternative: ingress tunnels that traffic with not-PCN
> in
> >>>the
> >>>>PCN and makes it clear that operators should choose to use an
> existing
> >>>DSCP
> >>>>Is this at all relevant to PCN? I would argue we don't need to
> state
> >>>this

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 16 Apr 2011 11:18:34 +0100

Michael,

At 16:20 15/04/2011, Michael Menth wrote:
>>HOWEVER, I don't think this case is possible. If traffic arrives 
>>with a DSCP that would be used for PCN, it is signalling that it 
>>requires admission control [RFC5865].
>

[Firstly a picky point: RFC5865 defines four DSCPs as meaning that 
admission control is required: not just VOICE-ADMIT, but also CS4, 
CS3 & AF4, and it doesn't preclude the list being extended in future. 
Let's call them *-ADMIT, even though they aren't named like that]

True, we have only made an non-normative recommendation that PCN 
should use *-ADMIT.

But then we should explain that this is a corner-case that can be 
avoided by following our recommendation that advises on which DSCPs 
to use for PCN. It would only happen if:
a) The PCN region chooses one of the 252 DSCPs other than the four 
*-ADMIT DSCPs recommended for use as a PCN-compatible DSCP.
b) some arriving traffic other than that wanting admission control 
just happens to use the same DSCP that the PCN region chose.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 16 Apr 2011 12:05:07 +0100

Toby,

>You need to re-read the appendix of RFC5696 where we discuss DSCP-related

I did before writing that email.

>  their segment of the path, and PCN is just one possible mechanism

We need to provide some explanation for why we suddenly started 
talking about these four cases. So we do need to say what we mean by 
end-nodes asking for admission control. It would be nice to cite 
something that explains, but we don't have anything, because RFC5865 
on DSCPs for admission contrl went through after all the PCN RFCs so far.

So I think we have to treat this appendix as the latest definitive 
word on the two mains ways that end points might use to signal that 
they want admission control, even tho it's not really relevant to 
this doc. The only alternative would be to update the PCN 
architecture RFC, and I don't want to go there.

>control but which shares the same DSCP...

[snip]

>neither ECN nor PCN. If we were to list all negative cases we would get an

Well, the traffic *is* ECN and it is confusable with PCN traffic. As 
I just said in my mail to Michael, it would only be confusible with 
PCN traffic if the PCN operator decided to use weird DSCPs for PCN.

How about not listing this case as if it is normal, but instead 
mention it as a 'footnote' to this appendix, as an abnormal case to 
be avoided if possible, perhaps:

"It is strongly RECOMMENDED that the advice in A.1 of the PCN 
baseline encoding [RFC5696] is followed when choosing which DSCP 
indicates PCN-compatible traffic. Otherwise nodes within the PCN 
region will mistake traffic using e2e ECN for PCN-traffic if it also 
happens to use the chosen DSCP. To avoid this confusion, the PCN 
ingress would have to remark this traffic to another DSCP, causing 
further complication and confusion downstream."

>s/"somehow indicates"/"signals that"

If you want.
I was trying to avoid being prescriptive about how it might be done.

>the top), and there is a chance I may miss a couple!

Yes, when I prepared the email you just replied to, I tried to pull 
together everything that had been said, so I hope that posting will 
be useful for you.

Cheers

Bob

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 17 Apr 2011 10:40:56 +0000

Hi Toby, Hi Bob

In my opinion, in addition to the requirements/recommendations given in
the Appendix A and Appendix B in RFC5696 regarding "Choice of Suitable
DSCPs", "Rationale for Using ECT(0) for Not-Marked" and
"Co-Existence of PCN and ECN", I think that "3-in-1" draft should
also follow the recommendations given in Section 3.6 of RFC5559:

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

Best regards,
Georgios