Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Mar 2011 11:35:10 -0400

To respond to the comments below, I propose that the text in 5.2.1 be 
modified as follows:

"Packets at the ingress to the domain are classified as either PCN
or non-PCN. Non-PCN packets MAY share the network with PCN packets
within the domain. Because the encoding specified in [RFC5696] and
used in this document requires the use of the ECN fields,
PCN-ingress-nodes MUST prevent ECN-capable traffic that uses the same
DSCP as PCN from entering the PCN-domain directly.  The PCN-ingress-node
can accomplish this in three ways. The choice between these depends on 
local policy.

o   "ECN-capable traffic MAY be dropped. This policy is NOT
      RECOMMENDED, since it prevents the proper operation of
      end-to-end ECN as a means of controlling congestion.
				
o   "ECN-capable traffic MAY be assigned a different DSCP
      from PCN traffic. This could mean that it is relegated
      to a lower-priority behaviour aggregate.
				
o   "ECN-capable traffic MAY be tunneled across the PCN-domain.
      If this is done, the PCN-ingress-node MUST mark packets as
      either not-PCN or PCN-not-marked only after the encapsulation
      of the packet, including any initial setting of the ECN field,
      has been completed."

First question is whether the text makes sense. Second question is 
whether any security issue remains, given that we do not recommend 
dropping of packets marked ECN-capable or CE.

On 21/12/2010 3:19 PM, David Harrington wrote:
...
>
> 4) in 5.2.1, "MUST block ... Alternatively ..." - it cannot be both
> MUST and alternatively. How about "MUST be prevented from entering the
> domain, such as by blocking or tunneling, ..." and then discuss those
> approaches.
>
...
> is this "will not" really a MUST NOT? or SHOULD NOT?
>
> 11) in 6, does ECN ever play into security considerations? does
> reusing ecn bits then have a potential impact on security?
> - What about tunneling ECN-enabled traffic? Preventing entry into the
> domain is a CL-edge requirement, right? Therefore, this document does
> introduce new considerations for security, such as those mentioned in
> RFC6040.
> - what about blocking ecn-enabled traffic? ditto.
>
> from RFC6040:
>     Ensuring congestion
>     markings are not lost is itself an aspect of security, because if
> we
>     allowed congestion notification to be lost, any attempt to enforce
> a
>     response to congestion would be much harder.
>
> so I think this section needs a little more work.
>
...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Mar 2011 11:52:15 -0400

This note discusses the comment below. My main concern is that I simply 
don't know what a border router does with the packets of a flow before 
the flow is admitted, and the stated assumption represented my best 
guess. That obviously needs review by someone knowledgable.

As a side note, I don't think normative text belongs under the heading 
"Assumptions, so if we did as you suggested, the text would have to go 
somewhere else.

>
> 10) in 5.5,
> 	Assumed that a specific portion of link capacity has been
> reserved
>
> 	Assumed that the Decision Point receives requests
>         for admission of PCN-flows before the packets in the PCN-flows
>
>         arrive.  This is not a critical assumption, but in its absence,
>
>         packets will be dropped by the PCN-ingress-node until it
> obtains the
>         admission decision from the Decision Point.
>
> how about Assumptions:
> 1) a specific portion of link capacity has been reserved for
> PCN-traffic.
> 2) the Decision Point receives requests
>         for admission of PCN-flows before the packets in the PCN-flows
>
>         arrive, and
>         packets will not be dropped by the PCN-ingress-node until it
> obtains the
>         admission decision from the Decision Point.
>

---

From: Michael Menth <[email-masked]>
Date: Tue, 22 Mar 2011 22:37:41 +0100

Hi Tom,

>      end-to-end ECN as a means of controlling congestion.
This is not necessary. Just CE-marked packets MAY be dropped. This is 
exactly the issue I'd like to have more explicitly in the encoding drafts.

>      to a lower-priority behaviour aggregate.
I do not understand what this means. Does it mean that this traffic 
cannot be PCN traffic? This should be more explicit. I would not say 
that this is not recommended. It's just an option.

>      either not-PCN or PCN-not-marked 
Why not-PCN? That does not make sense to me.

> only after the encapsulation
And before decapsulation the ECN field must be zeroed to avoid that 
outer header information propagates into the inner header. I think Bob 
should look at this.

Best wishes,

     Michael

>
> First question is whether the text makes sense. 

> Second question is whether any security issue remains, given that we 
> do not recommend dropping of packets marked ECN-capable or CE.
>
> _______________________________________________
> 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: Tom Taylor <[email-masked]>
Date: Tue, 22 Mar 2011 20:32:38 -0400

I should wait for others to join the conversation, but I'll comment on 
your comments.

> exactly the issue I'd like to have more explicitly in the encoding drafts.
[PTT] Thinking about it, that seems to make sense.
> that this is not recommended. It's just an option.
[PTT] The last part first: that's all this says, that it is an option. 
And you understand what I mean to say with the first part -- that 
incoming ECN-capable (ECT(0), ECT(1), or CE) cannot be admitted directly 
as PCN traffic there will be no way to retrieve the original ECN 
markings when the traffic leaves the domain.
> Why not-PCN? That does not make sense to me.

[PTT] Not-PCN if it doesn't match the filter rules identifying PCN 
traffic. You can have non-PCN and PCN traffic sharing the same link.
> outer header information propagates into the inner header. I think Bob

[PTT] Agreed we need Bob's blessing, but I think you are right: PCN 
operates between the point at which encapsulation is complete and the 
point just before decapsulation is performed.

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 07:56:05 +0100

Hi Tom,

I meant that we should not classify the point with dropping CE-marked 
packets as "not recommended" (first bullet, not second one). It's just 
an option and even a very simple option.

Best wishes,

      Michael

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 08:50:04 +0100

Hi Tom,

thanks for creating threads per issue.

I don't think that there's a point in creating a "busy indication" once
the first packets carrying payload have been transmitted. I also don't think we
could add a "busy sign" after the customer had a "ringing".

So only a limited signaling exchange may go ahead prior to admission. Without
signaling "admitted" from the decision point, neither a state like "ringing"
nor PCN payload of not admitted flows can be allowed.

MUST NOT for signaling messages indicating something like a "ringing" state
and payload then.

Regards,

Ruediger

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 10:05:47 +0000

I don't think we need to say much about this. Surely they're not PCN-packets, the doc doesn't say anything about all the other sorts of non PCN-packets!

Is rfc5559 enough?

>From rfc5559

<<
4.2. PCN-Ingress-Node Functions

   Each ingress link of the PCN-domain is configured with the following
   functionality:

   o  Packet classification - determine whether an incoming packet is
      part of a previously admitted flow by using a filter spec (eg,
      DSCP, source and destination addresses, port numbers, and
      protocol).

   o  Police - police, by dropping any packets received with a DSCP
      indicating PCN transport that do not belong to an admitted flow.
      (A prospective PCN-flow that is rejected could be blocked or
      admitted into a lower-priority behaviour aggregate.)

[from Terminology] The PCN-BA is distinguished
      by a combination of the Diffserv codepoint (DSCP) and ECN fields.

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 10:28:15 +0000

<< Non-PCN packets MAY share the network with PCN packets
within the domain.>>
the assumption has been that there will be non pcn-packets/

S4.2 rfc5559 says:
<<  o  Police - police, by dropping any packets received with a DSCP
      indicating PCN transport that do not belong to an admitted flow.>>
[really should say "DSCP & ECN field", since in the encoding docs we have non PCN-traffic that uses the same DSCP as PCN but sets ECN=00.)

But clearly non PCN-traffic that uses the same DSCP as PCN and sets ECT or CE cannot be admitted in this form.
Dropping such traffic seems ok to me. Tunnelling is also ok (into a different DSCP); tunnelling is done before the pkt hits the PCN-ingress-node functionality of rfc5559. I guess you could downgrade as well.

In fact, I think rfc5559 already has enough:-

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

since we only have one extended encoding scheme, we just need to check the same "appropriate action" is ok. I think it is (but haven't pondered the issue for long)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: 22 March 2011 15:35
To: David Harrington
Cc: pcn
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

				

...
...

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Mar 2011 15:07:28 -0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 23 March 2011 10:28
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

Or even: "PCN has been designed to allow non-PCN packets to share the
PCN-domain"?

> [really should say "DSCP & ECN field", since in the encoding docs we
> have non PCN-traffic that uses the same DSCP as PCN but sets ECN=00.)

This should probably be reported as an RFC erratum

> Dropping such traffic seems ok to me. Tunnelling is also ok (into a
> different DSCP); tunnelling is done before the pkt hits the PCN-
> ingress-node functionality of rfc5559. I guess you could downgrade as
> well.

You can tunnel IP in IP, even if Bob's 6040 is not in force. The key thing
will be the order in which things happen. If an ECN packet arrives at a
PCN-ingress, it needs to first be treated "appropriately". This can be
moving to a different DSCP, downgrading, dropping, or placing into an
IP-in-IP tunnel. Any packets that remain in the PCN DSCP then need to have
their PCN codepoint cleared to 00. Finally they are admitted to the
PCN-domain. At the PCN-egress the egress node clears any codepoint to 00 as
the final action. If the packet was tunnelled it can then be decapsulated.
Under any decapsulation rules, a packet with an outer header of 00 and an
inner with another codepoint is forwarded with the inner codepoint intact (I
think).

> In fact, I think rfc5559 already has enough:-

I agree there is already enough there, but let's satisfy Dave's comments

> since we only have one extended encoding scheme, we just need to check
> the same "appropriate action" is ok. I think it is (but haven't
> pondered the issue for long)

AFAICT the extended scheme should also give the same "appropriate action"
since it requires compatibility with RFC5696 (it is an extension, not a
stand-alone encoding).

Toby

>       of the packet, including any initial setting of the ECN field,

Need to clarify "IP-in-IP tunnel". Also should point to RFC6040 as the
preferred mode of tunnelling. (see comment above on order in which things
happen).

> dropping of packets marked ECN-capable or CE.

Perhaps would be worth highlighting the security concerns of dropping ECT or
CE packets. That would change your first bullet to something like:
 o   "ECN-capable traffic MAY be dropped. This policy is NOT
       RECOMMENDED, since it prevents the proper operation of
       end-to-end ECN as a means of controlling congestion. This 
       is a possible security risk and so should only be done in 
       exceptional circumstances."

Toby

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 17:16:27 +0100

Hi Toby and all,

Am 23.03.2011 16:07, schrieb Toby Moncaster:
>> [really should say "DSCP&  ECN field", since in the encoding docs we
> moving to a different DSCP,
What do you mean by that?

> downgrading,
What do you mean by that?

> dropping,
Just CE-packets or also ECT(x)?

> or placing into an
> PCN-domain.
What does admitted mean in this context? Certainly different from 
"admission control" ...

> At the PCN-egress the egress node clears any codepoint to 00 as
How do we differentiate between compatibility mode and normal mode 
tunnels ending at an egress node? The egress needs to know that to know 
whether it must first zero the ECN field or decapsulate the packet.

What we discuss here is actually what we said should be covered in the 
encoding drafts. But I don't mind having it twice. But it's important to 
have it in at least one place clear enough, that's why I spelled it out 
in my suggestion for the encoding draft.

> I agree there is already enough there, but let's satisfy Dave's comments

The fact that authors of PCN standards need to check again and again how
1) tunnels within PCN domains and
2) tunnels for ECN field preservation work
should tell us that Dave addresses a real need.
1) requires normal mode tunnels [RFC6040] with 3-in-1 encoding
2) works with existing limited functionality mode tunnels [?] or 
compatibility mode tunnels [RFC6040] between ingress and egress nodes

Best wishes,

     Michael

>> Tom Taylor

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 17:21:46 +0000

Does S3.6 from rfc5559 clarify most of your questions?
I agree with you that it would be worth then spelling out what "tunnelled through the PCN-domain" involves. Your earlier proposal seemed ok to me, but bob should confirm.

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 23 March 2011 16:16
To: Toby Moncaster
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Toby and all,

Best wishes,

     Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 18:35:28 +0100

Hi Phil,

> I agree with you that it would be worth then spelling out what "tunnelled through the PCN-domain" involves. Your earlier proposal seemed ok to me, but bob should confirm.
I looked at S3.6 of rfc5559. The guidelines given there look to me more 
like a to-do-list rather than a solution. Also the text

    For the baseline encoding [Moncaster09-1  <http://tools.ietf.org/html/rfc5559#ref-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
MM: Dropping ECT(0) or ECT(1) packets is certainly not needed

    or downgraded to a lower-priority behaviour aggregate,
MM: I do not understand how this helps in this context

    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.
MM: also spelling out that would help, especially as we deal with two different types of tunnels in PCN domains.

Therefore, I do not think that a pointer to S3.6 in RFC5559 is enough.

Regards,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Mar 2011 17:38:15 -0000

Just a couple of answers inline

> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >> But clearly non PCN-traffic that uses the same DSCP as PCN and sets
> ECT
> >> or CE cannot be admitted in this form.

They are allowed to become a non-PCN packet within the PCN-domain...

> whether it must first zero the ECN field or decapsulate the packet.

I think it should ALWAYS zero the ECN field first. The only exception we
allowed for in RFC5696 was if there had been an explicit negotiation to
allow PCN marks to be "leaked" to the receiver...

> compatibility mode tunnels [RFC6040] between ingress and egress nodes

1) Tunnels wholly within a PCN domain need to do the appropriate mode for
the encoding they are using - 6040 normal mode should be the default
expected behaviour

Check with Bob about 2). If I am right then /any/ tunnel mode should work,
so long as the packet is encapsulated and decapsulated outside the logical
PCN-domain. 

Toby

> >>     o  take appropriate action if ECN-capable, non-PCN-traffic
> arrives
> >> at

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 17:50:48 +0000

From: Michael Menth [mailto:[email-masked]]
Sent: 23 March 2011 17:35
To: Eardley,PL,Philip,DES8 R
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Phil,

Am 23.03.2011 18:21, schrieb [email-masked]:<mailto:[email-masked]:>

I agree with you that it would be worth then spelling out what "tunnelled through the PCN-domain" involves. Your earlier proposal seemed ok to me, but bob should confirm.
I looked at S3.6 of rfc5559. The guidelines given there look to me more like a to-do-list rather than a solution. Also the text

   For the baseline encoding [Moncaster09-1<http://tools.ietf.org/html/rfc5559#ref-Moncaster09-1>], the "appropriate action"

[phil] with baseline encoding, i guess letting in ECT is ok. With 3-in-1 it would seem a bad idea to let in ECT pkts.

[phil] it means " put it in a DSCP that isn't PCN" (it's assumed in the architecture that PCN is high priority dscp)

   or alternatively

[phil] sure.

Regards,

    Michael

-----Original Message-----

To: Toby Moncaster

Cc: Eardley,PL,Philip,DES8 R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Toby and all,

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

[email-masked]<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

within the domain.>>

PCN-domain"?

S4.2 rfc5559 says:

       indicating PCN transport that do not belong to an admitted

flow.>>

But clearly non PCN-traffic that uses the same DSCP as PCN and sets ECT

well.

downgrading,

dropping,

or placing into an

PCN-domain.

"admission control" ...

think).

Best wishes,

     Michael

    the approach is to:

    o  use a DSCP to allow PCN-nodes to distinguish PCN-traffic that

uses

       PCN-domain;

    o  take appropriate action if ECN-capable, non-PCN-traffic arrives

at

    action".>>

stand-alone encoding).

Toby

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

Tom Taylor

To: David Harrington

Cc: pcn

modified as follows:

DSCP as PCN from entering the PCN-domain directly.  The PCN-ingress-

node

local policy.

       has been completed."

happen).

Toby

...

MUST and alternatively. How about "MUST be prevented from entering

the

approaches.

...

RFC6040.

from RFC6040:

     Ensuring congestion

we

     allowed congestion notification to be lost, any attempt to

enforce

a

...

PCN mailing list

[email-masked]<mailto:[email-masked]>

PCN mailing list

[email-masked]<mailto:[email-masked]>

PCN mailing list

[email-masked]<mailto:[email-masked]>

--

University of Tuebingen

Faculty of Science

fax: (+49)-7071/29-5220

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Mar 2011 17:56:55 -0000

One thought that adds a twist: What if the e2e transport decides to run ECN
on realtime traffic destined to be given PCN treatment? I would argue this
would be a silly use of ECN, but it is a corner case.

Anyway, the clearest description I can give (that might even catch all
corner cases) is:

ECN markings can only be preserved on traffic crossing the PCN-domain if
that traffic is placed in an IP-in-IP tunnel that straddles the width of the
PCN-domain. At the PCN-ingress, an arriving packet carrying an ECN codepoint
(01, 10, 11) should be encapsulated according to the compatibility mode
given in [RFC6040]. The packet can then be dealt with like any other packet
arriving at the PCN-ingress. At the PCN-egress all PCN marks should be
cleared before the packet leaves the PCN domain [rfc5696]. The packet can
then be decapsulated according to the rules given in [rfc6040].

NB I state compatibility mode as this pre-emptively clears the ECN state to
00. If the packet is not-PCN then this will be done by the PCN-ingress
anyway. If the packet is both ECN and PCN, then the PCN-ingress will set a
codepoint as appropriate (according to the chosen PCN encoding). In fact you
could use RFC6040 normal mode, and then clear the field.

The key point is that the tunnelling happens outside the PCN domain, so once
the packet is inside its tunnel, it can be treated as if the tunnelling
never happened...

Does any of that make any sense?

Toby 

> From: [email-masked] [mailto:[email-masked]]
> Sent: 23 March 2011 17:22
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [PCN] cl-edge: text for processing of ECN (section 5.2.1)
> 
> I agree with you that it would be worth then spelling out what
> "tunnelled through the PCN-domain" involves. Your earlier proposal
> seemed ok to me, but bob should confirm.
>

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 18:05:25 +0000

[phil] yes (non-PCN packet... sharing the PCN DSCP)

[phil] this seems right to me. 
If one thinks in terms of functionality (as in rfc5559), then all the edge behaviour draft needs to make clear is that the tunnel functions sits before the PCN-ingress-node function (and after the PCN-egress-node function). Tunnels wholly within the PCn domain have nothing to do with edge behaviour.
	
I think quite a bit of the confusion in recent documents arises because we don't just say "read this section in this doc". We carefully worked out what to say when a lot of people had a lot of time. If we try and create text that semi-repeats, and now people have less time, then we say things less accurately.
Of course, where things have changed or we got something wrong earlier, then we need to pick that up.

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 20:52:10 +0100

Hi Toby, all,

> allow PCN marks to be "leaked" to the receiver...
If we have an inner tunnel ending at a PCN egress node, we need the 
following actions:
1) egress node receives and measures differently marked PCN rates
2) egress node decapsulates traffic
3) egress node zeros ECN field

The following orders would work: 1, 2, 3; 2,1,3; 1, 3, 2; but 2, 3, 1; 
3, 1, 2; 3, 2, 1 would not work. If step 1) is technically always 
performed before 2) and 3), then the egress node does not need to 
differentiate tunnels within and tunnels across PCN domains.

> so long as the packet is encapsulated and decapsulated outside the logical
Ah, yes! By zeroing the ECN field, the behavior of the different modes 
collapses. It's really tricky. Bob already told me about that some weeks 
ago, but I failed to remember. Would be good to document that, too, with 
reasoning.

Best wishes,

     Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 20:58:31 +0100

Hi Phil,

Am 23.03.2011 18:50, schrieb [email-masked]:
>
> *From:*Michael Menth [mailto:[email-masked]]
> *Sent:* 23 March 2011 17:35
> *To:* Eardley,PL,Philip,DES8 R
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)
>
> Hi Phil,
>
> <mailto:[email-masked]:>
>
> I looked at S3.6 of rfc5559. The guidelines given there look to me 
> more like a to-do-list rather than a solution. Also the text
>
Why that? I do not see a difference.

> [phil] it means " put it in a DSCP that isn't PCN" (it's assumed in the architecture that PCN is high priority dscp)
Ok, that means that such traffic cannot be supported by PCN. This should 
be clearly expressed when enumerating this option again because I (as a 
reader) expected an option that handles ECN traffic as PCN traffic 
within a PCN domain.

Best wishes,

     Michael

> Cc: Eardley,PL,Philip,DES8 R;[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>         From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of
>
>         [email-masked]  <mailto:[email-masked]>
>
>         To:[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>         Cc:[email-masked]  <mailto:[email-masked]>
>
>         From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of
>
>         Tom Taylor
>
>         [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Mar 2011 20:40:15 -0000

Inline (heavily snipped)

> Sent: 23 March 2011 19:52
> To: Toby Moncaster
<SNIP>

> differentiate tunnels within and tunnels across PCN domains.

1,2,3 or 2,1,3 work in the PCN sense, but not for tunnelling ECN. For ECN to
work you have to do 1,3,2. But you are right, the only thing actually
relevant to PCN is step 1.

<SNIP>

> ago, but I failed to remember. Would be good to document that, too,

As I think I said before I don't like including too much detail from one RFC
in another one. If people don't understand this, that is a problem relating
to RFC6040, not to PCN. If you feel we really need more text about this then
something like my other email should suffice

Toby

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 21:41:03 +0100

Hi Toby,

Am 23.03.2011 18:56, schrieb Toby Moncaster:
> on realtime traffic destined to be given PCN treatment?
You mean "use the same DSCP as for PCN"? "PCN treatment" implied 
admission control to me at first reading.

>   I would argue this
I think so. The ingress node should tunnel any ECN packet with an 
original PCN-DSCP or which is subject to PCN-based AC towards the egress 
node. The PCN-ingress-node should set a not-PCN as outer header 
codepoint if the traffic is not subject to PCN-based AC and to NM if the 
traffic is subject to PCN-based AC.

Is that what you mean? Apart from that, we are always talking about 
restoring the ECN field? Why don't we restore the DSCP? Because it has 
only local significance anyway? If we use a tunnel, then we could also 
preserve the orignal DSCP, right? Should we recommend uniform or pipe 
tunnels RFC2983?
http://tools.ietf.org/html/draft-ietf-pcn-encoding-comparison-04#section-3.2.2
It's related to that discussion.

Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Mar 2011 20:44:43 -0000

From: Michael Menth [mailto:[email-masked]] 
Sent: 23 March 2011 19:59
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Phil,

 

Cc: [email-masked]; [email-masked]; [email-masked];

Hi Phil,

Does S3.6 from rfc5559 clarify most of your questions?
I agree with you that it would be worth then spelling out what "tunnelled
through the PCN-domain" involves. Your earlier proposal seemed ok to me, but
bob should confirm.

I looked at S3.6 of rfc5559. The guidelines given there look to me more like
a to-do-list rather than a solution. Also the text 

   For the baseline encoding [Moncaster09-1
<http://tools.ietf.org/html/rfc5559#ref-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 
MM: Dropping ECT(0) or ECT(1) packets is certainly not needed
 
[phil] with baseline encoding, i guess letting in ECT is ok. With 3-in-1 it
would seem a bad idea to let in ECT pkts. 

{TM} I think what Phil means is that if you let ECT into a baseline RFC5696
PCN-domain then they just act as PCN packets, but if you let them into a
3-in-1 PCN-domain, a fraction of them may act as if they are already marked.

 
[phil] it means " put it in a DSCP that isn't PCN" (it's assumed in the
architecture that PCN is high priority dscp)

Ok, that means that such traffic cannot be supported by PCN. This should be
clearly expressed when enumerating this option again because I (as a reader)
expected an option that handles ECN traffic as PCN traffic within a PCN
domain.

{TM} I would find it a little strange to use ECN  e2e for real-time traffic.
At least, in the sense it is defined in RFC3168. So this must at best be a
corner case

Best wishes,

    Michael

   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.
MM: also spelling out that would help, especially as we deal with two
different types of tunnels in PCN domains.
 
[phil] sure.

Regards,

    Michael

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 23 March 2011 16:16
To: Toby Moncaster
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked];
[email-masked]
 
Hi Toby and all,

-----Original Message-----

S4.2 rfc5559 says:

downgrading,

dropping,

or placing into an

 
Best wishes,
 
     Michael

 

 

 
Toby

-----Original Message-----

 

Toby

the

...

 
from RFC6040:
     Ensuring congestion

enforce

a

...

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 21:48:55 +0100

Hi Toby,

> something like my other email should suffice

I don't see that we include too much detail from other RFCs. I just 
think that it is important to say which RFCs can help to solve problems 
in the PCN context and how they should be correctly applied to reach 
that goal. That is  not copying or redefinition.

Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 21:53:12 +0100

Hi Toby,

Am 23.03.2011 21:44, schrieb Toby Moncaster:
> *Sent:* 23 March 2011 19:59
> *To:* [email-masked]
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> {TM} I think what Phil means is that if you let ECT into a baseline 
> RFC5696 PCN-domain then they just act as PCN packets, but if you let 
> them into a 3-in-1 PCN-domain, a fraction of them may act as if they 
> are already marked.
>

The ECN field of PCN packets is set to NM by the PCN-ingress-node when 
entering the PCN domain. That's why I do not understand this reasoning.

Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 24 Mar 2011 10:44:26 -0000

Michael,

> Sent: 23 March 2011 20:49
> To: Toby Moncaster
> >>> Check with Bob about 2). If I am right then /any/ tunnel mode
> should
> >> work,

I am not against including some detail from other RFCs, but this can mainly
be done using references, with an occasional quote. Phil made a good point
that we should seek to reference more precisely (section 1.2 of RFC9876 for
instance). My great aim is to avoid setting up an unexpected dependency
between an RFC from TSVWG, say and a PCN RFC -- if in future the TSVWG RFC
is updated, it may not occur to people to check co-dependencies, leading to
possible problems.

Toby

---

From: <[email-masked]>
Date: Thu, 24 Mar 2011 11:24:37 +0000

{TM} I think what Phil means is that if you let ECT into a baseline RFC5696 PCN-domain then they just act as PCN packets, but if you let them into a 3-in-1 PCN-domain, a fraction of them may act as if they are already marked.

The ECN field of PCN packets is set to NM by the PCN-ingress-node when entering the PCN domain. That's why I do not understand this reasoning.

[phil] toby, you got my reasoning.
Michael, they are not PCN packets; they are ECN packets that happen to share the PCN DSCP. The PCN documents do not tell you to set NM on non-PCN-pkts.
If i remember the discussion from ~5 years ago, there were people who had in mind to use ECN signalling for new purposes (not in RFCs), so they didn't want ECT to be set to 00 by a PCN-ingress-node. This was input from magnus westerlund (AD at the time).
Although with baseline it seems that letting in ECT is ok, in fact it is not (despite what i said above - brain not fully engaged at the time). The reason is that the PCN-egress-node colouring function sets the ECN field to 00. Therefore letting in ECN pkts with ECT would result in them exiting the PCN-domain as 00. This potentially confuses ECN endpoints which have set ECT for some reason or other.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 24 Mar 2011 14:58:13 +0100

Hi Phil, Hi all
 
Regarding the use of ECN signaling for other purposes, I think that you
refer to:
 
http://www.watersprings.org/pub/id/draft-westerlund-avt-ecn-for-rtp-02.txt
 
>From what I remember, section 3.6. Backwards Compatibility of RFC5559, was
derived after the discussions that we have had in the context of the above
mentioned draft.
 
Therefore, I think that we sould refer and use as much as possible section
3.6 of RFC5559 for this challenge.
 
What we however, have to discuss is if and how RFC6040, would change the
"appropriate action" mentioned in Section 3.6.
If yes, then we will have to mention these new actions in the new PCN edge
behaviour documents, if possible!
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: donderdag 24 maart 2011 12:25
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Am 23.03.2011 18:21, schrieb  <mailto:[email-masked]:>
[email-masked]: 

 

Michael, they are not PCN packets; they are ECN packets that happen to share
the PCN DSCP. The PCN documents do not tell you to set NM on non-PCN-pkts.

If i remember the discussion from ~5 years ago, there were people who had in
mind to use ECN signalling for new purposes (not in RFCs), so they didn't
want ECT to be set to 00 by a PCN-ingress-node. This was input from magnus
westerlund (AD at the time). 

Although with baseline it seems that letting in ECT is ok, in fact it is not
(despite what i said above - brain not fully engaged at the time). The
reason is that the PCN-egress-node colouring function sets the ECN field to
00. Therefore letting in ECN pkts with ECT would result in them exiting the
PCN-domain as 00. This potentially confuses ECN endpoints which have set ECT
for some reason or other.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 24 Mar 2011 12:34:27 -0400

I'm glad you brought this up -- I kept thinking I should mention it. I 
knew about it as a former co-Chair of AVT. The current version is
draft-ietf-avtcore-ecn-for-rtp-01.txt.

My own opinion is that RFC 6040 does not change the "appropriate 
action", since PCN actions happen "inside" the environment created by 
RFC 6040.

On 24/03/2011 9:58 AM, Georgios Karagiannis wrote:
>  From what I remember, section 3.6. Backwards Compatibility of RFC5559,
> was derived after the discussions that we have had in the context of the
> above mentioned draft.
> Therefore, I think that we sould refer and use as much as possible
> section 3.6 of RFC5559 for this challenge.
> If yes, then we will have to mention these new actions in the new PCN
> edge behaviour documents, if possible!
> Best regards,
> Georgios
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of [email-masked]
>     *Sent:* donderdag 24 maart 2011 12:25
>     *To:* [email-masked]; [email-masked]
>     *Cc:* [email-masked]
>     The ECN field of PCN packets is set to NM by the PCN-ingress-node
>     when entering the PCN domain. That's why I do not understand this
>     reasoning.
>
>     Michael, they are not PCN packets; they are ECN packets that happen
>     to share the PCN DSCP. The PCN documents do not tell you to set NM
>     on non-PCN-pkts.
>
>     If i remember the discussion from ~5 years ago, there were people
>     who had in mind to use ECN signalling for new purposes (not in
>     RFCs), so they didn’t want ECT to be set to 00 by a
>     PCN-ingress-node. This was input from magnus westerlund (AD at the
>     time).
>
>     Although with baseline it seems that letting in ECT is ok, in fact
>     it is not (despite what i said above – brain not fully engaged at
>     the time). The reason is that the PCN-egress-node colouring function
>     sets the ECN field to 00. Therefore letting in ECN pkts with ECT
>     would result in them exiting the PCN-domain as 00. This potentially
>     confuses ECN endpoints which have set ECT for some reason or other.
>
>
>