Betre= ff:	New Version Notification for draft-menth-pcn-marked-signaling-ac-00
Datum= :	Mon, 28 Feb 2011 09:20:11 -0800 (PST)
Von: =	IETF I-D Submission Tool <idsubmission@ietf.org><= /td>
An: <= /th>	menth@informatik.uni-tuebingen.de
CC: <= /th>	ruediger.geib@telekom.de

<= /o:p>

From: Michael Menth [mailto:menth@informa= tik.uni-tuebingen.de]
Sent: 23 March 2011 17:35
To: Ea= rdley,PL,Philip,DES8 R
Cc: toby@moncaster.com; tom111.taylor@bell= .net; ietfdbh@comcast.net; pcn@ietf.org
Subject: Re: [PCN] cl-edg= e: text for processing of ECN (section 5.2.1)

Hi Phil,=

Am 23.03.2011 18:21, schrieb philip.eardley@bt.com:

Does S3.6 from rfc5559 c=
larify most of your questions?

I agree with you that i=
t would be worth then spelling out what "tunnelled through the PCN-dom=
ain" involves. Your earlier proposal seemed ok to me, but bob should c=
onfirm.

I looked at S3.6 of rfc5559. T= he guidelines given there look to me more like a to-do-list rather than a s= olution. Also the text

   For the baseli=
ne encoding [Moncaster09-1], the "appropriate action"

   is to block ECN-capable traffic that uses the sam=
e DSCP as PCN from

   entering the PCN-domai=
n 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. 
 
   or downgraded to a lower-priority behaviour aggre=
gate, 
MM: I do not understand how this helps in this =
context
 
[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 alternati=
vely
   such traffic may be tunnelled throug=
h the PCN-domain.  The reason
   that &=
quot;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 diff=
erent types of tunnels in PCN domains.

&nb=
sp;

[phil] sure.

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

Regards,

Michael

-----Original Message=
-----

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]

Sent: 23 March 2011 16:16

To: Toby =
Moncaster

Cc: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org

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

 <=
/pre>Hi Toby and all,
 
Am 23.03.2011 16:07, schrieb Toby Moncaster:

-----Original Message-----From: pcn-bounces@ietf.org<=
/a> [mailto:pcn-bounces@ietf.org] On Behalf Of
philip.eardley@bt.com
Sent: 23 March 2011 10:28=
To: tom111.=
taylor@bell.net; ietfdbh@comcast=
.net
Cc: pcn@ietf.=
org
Subject: Re: [PCN] cl-edge: text for processin=
g of ECN (section 5.2.1)

&=
lt;<  Non-PCN packets MAY share the network with PCN packets
within the domain.>>
the assumpti=
on has been that there will be non pcn-packets/
Or even: "PCN has been designed to allow non-PCN packets to sha=
re the
PCN-domain"?
&nb=
sp;

S4.2 rfc5559 says:
<=
;<   o  Police - police, by dropping any packets received=
 with a DSCP
       indi=
cating 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=3D00.)

This should probably be reported as an RFC erratu=
m

But clearly non PCN-traffic that uses th=
e same DSCP as PCN and sets ECT

or CE cannot be admitt=
ed in this form.

Dropping such traffic seems ok to me.=
 Tunnelling is also ok (into a

different DSCP); tunnel=
ling is done before the pkt hits the PCN-

ingress-node=
 functionality of rfc5559. I guess you could downgrade as

<= pre>well.

You can tunnel IP in IP, even i=
f Bob's 6040 is not in force. The key thing

will be th=
e order in which things happen. If an ECN packet arrives at aPCN-ingress, it needs to first be treated "appropriately"=
. This can be
moving to a different DSCP,

What do you mean by that?

&=
nbsp;

downgrading,

What do you mean by th=
at?

dropping,

Just CE-packets or also ECT(x)?

or p=
lacing into an

IP-in-IP tunnel. Any packets that remai=
n in the PCN DSCP then need to have

their PCN codepoin=
t cleared to 00. Finally they are admitted to the

PCN-=
domain.

What does admitted mean in this c=
ontext? Certainly different from

"admission cont=
rol" ...

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 a= n

inner with another codepoint is forwarded with the i=
nner codepoint intact (I

think).

How do we differentiate between compatibility mode and normal =
mode

tunnels ending at an egress node? The egress nee=
ds to know that to know

whether it must first zero th=
e ECN field or decapsulate the packet.

What we discuss here is actually w=
hat we said should be covered in the

encoding drafts.=
 But I don't mind having it twice. But it's important to

<= pre>have it in at least one place clear enough, that's why I spelled it out=

in my suggestion for the encoding draft.<=
/pre> 
In fact, I think rfc5559 already has enough:-
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) tu=
nnels for ECN field preservation work
should tell us t=
hat Dave addresses a real need.
1) requires normal mod=
e tunnels [RFC6040] with 3-in-1 encoding
2) works with=
 existing limited functionality mode tunnels [?] or 
c=
ompatibility mode tunnels [RFC6040] between ingress and egress nodes
 
Best wishes,

     Michael 
 
 
<< =
 3.6. Backwards Compatibility
 <=
pre>

    PCN specifies semantics =
for the ECN field that differ from the

  &nb=
sp; default semantics of [RFC3168].  A particular PCN encoding scheme<=
o:p>

    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 allo=
w PCN-nodes to distinguish PCN-traffic that

uses<=
/o:p>

       the alternative ECN se=
mantics;

   =
; o  define these semantics for use within a controlled region, the

       PCN-domain;

    o  take a=
ppropriate action if ECN-capable, non-PCN-traffic arrives

<= pre>at

       a PCN-ingr=
ess-node with the DSCP used by PCN.

 <=
/pre>    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
  &nb=
sp; downgraded to a lower-priority behaviour aggregate, or alternatively
    such traffic may be tunnelled through=
 the PCN-domain.  The reason
    t=
hat "appropriate action" is needed is that the PCN-egress-node
    clears the ECN field to 00.
 
    Extended encodin=
g schemes may need to take different "appropriate
    action".>>

 <=
/o:p>

since we only have one extended encoding scheme, we just ne=
ed 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"

sinc=
e it requires compatibility with RFC5696 (it is an extension, not a

stand-alone encoding).

Toby

-----Original Message-----=

From: pcn-bou=
nces@ietf.org [mailto:pcn-bounc=
es@ietf.org] On Behalf Of

Tom TaylorSent: 22 March 2011 15:35
To: David Harrington=
Cc: pcn
Subject: Re: [PCN] cl-ed=
ge: text for processing of ECN (section 5.2.1)
&n=
bsp;
To respond to the comments below, I propose that the t=
ext in 5.2.1 be
modified as follows:<=
pre>

"Packets at the ingress to the domain =
are classified as either PCN

or non-PCN. Non-PCN packe=
ts MAY share the network with PCN packets

within the d=
omain. 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<=
o:p>

DSCP as PCN from entering the PCN-domain directly.&nbs=
p; The PCN-ingress-

node

can acco=
mplish this in three ways. The choice between these depends onlocal policy.
 
o&n=
bsp;  "ECN-capable traffic MAY be dropped. This policy is NOT
       RECOMMENDED, since i=
t prevents the proper operation of
   &=
nbsp;   end-to-end ECN as a means of controlling congestion.=
 
o   "ECN-capabl=
e traffic MAY be assigned a different DSCP
  =
;     from PCN traffic. This could mean that it is rele=
gated
       to a lower-=
priority behaviour aggregate.
 <=
pre>o   "ECN-capable traffic MAY be tunneled across the PCN-=
domain.

       If this i=
s done, the PCN-ingress-node MUST mark packets as

&nbs=
p;      either not-PCN or PCN-not-marked only afte=
r the encapsulation

     &nbs=
p; of the packet, including any initial setting of the ECN field,

       has been completed."<=
o:p>

Need to clarify "IP-in-IP tunnel&quo=
t;. Also should point to RFC6040 as the

preferred mode=
 of tunnelling. (see comment above on order in which thingshappen).
 
First question is whether t=
he text makes sense. Second question is
whether any se=
curity issue remains, given that we do not recommend
d=
ropping of packets marked ECN-capable or CE.<=
pre>Perhaps would be worth highlighting the security concerns of dropping E=
CT or

CE packets. That would change your first bullet =
to something like:

  o   "ECN-capa=
ble traffic MAY be dropped. This policy is NOT

 &=
nbsp;      RECOMMENDED, since it prevents the prop=
er operation of

      &n=
bsp; end-to-end ECN as a means of controlling congestion. This        is a possible security =
risk and so should only be done in
   &=
nbsp;    exceptional circumstances."

Toby<=
/pre> 
 
On 21/12/2010 3:19 PM, Da=
vid 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 tun=
neling, ..." and then discuss those

approaches.

...=

is th=
is "will not" really a MUST NOT? or SHOULD NOT?

<= pre>

11) in 6, does ECN ever play into security =
considerations? does

reusing ecn bits then have a pote=
ntial impact on security?

- What about tunneling ECN-e=
nabled traffic? Preventing entry into the

domain is a =
CL-edge requirement, right? Therefore, this document does

<= pre>introduce new considerations for security, such as those mentioned in

RFC6040.

- what about blocking ecn=
-enabled traffic? ditto.

f=
rom RFC6040:

     Ensuring congest=
ion

     markings are not lost is =
itself an aspect of security, because if

we=

     allowed congestion notification to be l=
ost, any attempt to

enforcea
     response to congestion would be muc=
h harder.
 
so I think this =
section needs a little more work.
 
...
_____________________________=
__________________
PCN mailing list
PCN@ietf.org

https://www.ietf.org/ma=
ilman/listinfo/pcn

_______________________________=
________________

PCN mailing list

PCN@ietf.org

https://www.ietf.org/mail=
man/listinfo/pcn

____________________=
___________________________

PCN mailing list

PCN@ietf.orghttps://www.ie=
tf.org/mailman/listinfo/pcn
&nbs=
p;


-- 
Prof. Dr. habil. Michael Menth
University=
 of Tuebingen
Faculty of Science
=
Department of Computer Science
Chair of Communication =
Networks
Sand 13, 72076 Tuebingen, Germany<=
/pre>phone: (+49)-7071/29-70505
fax: (+49)-7071/2=
9-5220
mailt=
o:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de<=
o:p>

= --_000_9510D26531EF184D9017DF24659BB87F327CF40C45EMV65UKRDdoma_-- From toby@moncaster.com Wed Mar 23 10:55:26 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C923A693F for ; Wed, 23 Mar 2011 10:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyUFBMfmfq-L for ; Wed, 23 Mar 2011 10:55:24 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 916583A693C for ; Wed, 23 Mar 2011 10:55:24 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LwE4w-1PwZE91ONK-017tFh; Wed, 23 Mar 2011 18:56:56 +0100 From: "Toby Moncaster" To: , References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 23 Mar 2011 17:56:55 -0000 Message-ID: <003d01cbe983$b2fc0700$18f41500$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvpdbFjGR4J1UIdSASHEjNfQtBQYgACIAqwAADrncA= Content-Language: en-gb X-Provags-ID: V02:K0:+gxVXdcxmwfutvQK+rXrFq8I7fStIdN6ykXb+ITZD7T veHbsPNlMb24BxyTB1GY1GYducu6m84ZXq6SQzcH1gGUI+z92o PaB006Wl//QaOTq36Gr4j9QGKcwUoIZ7dQJNUF3nF2wffvyPOj jaR+tgwV4XTIdOOLOvW85Tn1NJfQQR3HbIyLEHMv1AsQJbxVPd iRs0aW3mO0lyaE/ViXDoZaCY28KzG21DKrwdQme0JQ= Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 17:55:26 -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 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: 23 March 2011 17:22 > To: menth@informatik.uni-tuebingen.de; toby@moncaster.com > Cc: tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org > Subject: RE: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > 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:menth@informatik.uni-tuebingen.de] > Sent: 23 March 2011 16:16 > To: Toby Moncaster > Cc: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; > ietfdbh@comcast.net; pcn@ietf.org > Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Toby and all, > > Am 23.03.2011 16:07, schrieb Toby Moncaster: > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > >> philip.eardley@bt.com > >> Sent: 23 March 2011 10:28 > >> To: tom111.taylor@bell.net; ietfdbh@comcast.net > >> Cc: pcn@ietf.org > >> Subject: Re: [PCN] cl-edge: text for processing of ECN (section > 5.2.1) > >> > >> << Non-PCN packets MAY share the network with PCN packets > >> within the domain.>> > >> the assumption has been that there will be non pcn-packets/ > > Or even: "PCN has been designed to allow non-PCN packets to share the > > PCN-domain"? > > > > > >> 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.) > > This should probably be reported as an RFC erratum > > > >> 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. > > 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, > 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 > > 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. > 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 > > 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). > 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. > > >> In fact, I think rfc5559 already has enough:- > > 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 > > > > > >> << 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) > > 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 > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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) > >> > >> 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." > > 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). > > > >> 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. > > 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 > > > > > >> 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. > >>> > >> ... > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > 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:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Wed Mar 23 11:03:58 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2606A28C0E3 for ; Wed, 23 Mar 2011 11:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QodpbK5FmJHp for ; Wed, 23 Mar 2011 11:03:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 3763428C0D6 for ; Wed, 23 Mar 2011 11:03:56 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 23 Mar 2011 18:05:30 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.151]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 23 Mar 2011 18:05:26 +0000 From: To: , Date: Wed, 23 Mar 2011 18:05:25 +0000 Thread-Topic: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Thread-Index: Acvpda4B4l9WWvLcSVasSLSpxhClAQACp5SwAADHp8A= Message-ID: <9510D26531EF184D9017DF24659BB87F327CF40C55@EMV65-UKRD.domain1.systemhost.net> References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <002f01cbe981$17e074b0$47a15e10$@com> In-Reply-To: <002f01cbe981$17e074b0$47a15e10$@com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:03:58 -0000 >=20 > > 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. > What does admitted mean in this context? Certainly different from > "admission control" ... They are allowed to become a non-PCN packet within the PCN-domain... [phil] yes (non-PCN packet... sharing the PCN DSCP) 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.=20 [phil] this seems right to me.=20 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 befor= e the PCN-ingress-node function (and after the PCN-egress-node function). T= unnels wholly within the PCn domain have nothing to do with edge behaviour. =09 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 wha= t 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 a= ccurately. Of course, where things have changed or we got something wrong earlier, the= n we need to pick that up. From menth@informatik.uni-tuebingen.de Wed Mar 23 12:50:48 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2206A28C0F1 for ; Wed, 23 Mar 2011 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I61iXeTeB3e6 for ; Wed, 23 Mar 2011 12:50:45 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by core3.amsl.com (Postfix) with SMTP id 134653A6942 for ; Wed, 23 Mar 2011 12:50:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E1261527A; Wed, 23 Mar 2011 20:52:17 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEtVi8zEJIYA; Wed, 23 Mar 2011 20:52:12 +0100 (MET) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1264E5256; Wed, 23 Mar 2011 20:52:11 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2E8AD176683F; Wed, 23 Mar 2011 20:52:11 +0100 (CET) Message-ID: <4D8A4F6A.2070505@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 20:52:10 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Toby Moncaster References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <002f01cbe981$17e074b0$47a15e10$@com> In-Reply-To: <002f01cbe981$17e074b0$47a15e10$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 19:50:48 -0000 Hi Toby, all, Am 23.03.2011 18:38, schrieb Toby Moncaster: > Just a couple of answers inline > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] >> Sent: 23 March 2011 16:16 >> To: Toby Moncaster >> Cc: philip.eardley@bt.com; tom111.taylor@bell.net; ietfdbh@comcast.net; >> pcn@ietf.org >> Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) >> >> Hi Toby and all, >> >> Am 23.03.2011 16:07, schrieb Toby Moncaster: >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >> Of >>>> philip.eardley@bt.com >>>> Sent: 23 March 2011 10:28 >>>> To: tom111.taylor@bell.net; ietfdbh@comcast.net >>>> Cc: pcn@ietf.org >>>> Subject: Re: [PCN] cl-edge: text for processing of ECN (section >> 5.2.1) >>>> << Non-PCN packets MAY share the network with PCN packets >>>> within the domain.>> >>>> the assumption has been that there will be non pcn-packets/ >>> Or even: "PCN has been designed to allow non-PCN packets to share the >>> PCN-domain"? >>> >>> >>>> 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.) >>> This should probably be reported as an RFC erratum >>> >>>> 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. >>> 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, >> 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 >>> 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. >> What does admitted mean in this context? Certainly different from >> "admission control" ... > They are allowed to become a non-PCN packet within 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). >> 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. > 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... 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. >> >> 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. >> >>>> In fact, I think rfc5559 already has enough:- >>> 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 > 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. 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 > Toby > > >> Best wishes, >> >> Michael >> >> >>>> << 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) >>> 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 >>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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) >>>> 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." >>> 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). >>> >>>> 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. >>> 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 >>> >>> >>>> 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. >>>>> >>>> ... >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> 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:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Wed Mar 23 12:57:18 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B993A6846 for ; Wed, 23 Mar 2011 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqH8KhE4g7qN for ; Wed, 23 Mar 2011 12:57:08 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 5F8B128C0F1 for ; Wed, 23 Mar 2011 12:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D368452CA; Wed, 23 Mar 2011 20:58:37 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvvPEs5YueCF; Wed, 23 Mar 2011 20:58:32 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id AB7245280; Wed, 23 Mar 2011 20:58:32 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id A02AEF0DEFE; Wed, 23 Mar 2011 20:58:31 +0100 (CET) Message-ID: <4D8A50E7.6010304@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 20:58:31 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: philip.eardley@bt.com References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> <4D8A2F60.3090009@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------070804010104090109090305" Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 19:57:18 -0000 This is a multi-part message in MIME format. --------------070804010104090109090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Phil, Am 23.03.2011 18:50, schrieb philip.eardley@bt.com: > > *From:*Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > *Sent:* 23 March 2011 17:35 > *To:* Eardley,PL,Philip,DES8 R > *Cc:* toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; > pcn@ietf.org > *Subject:* Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Phil, > > Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: > > > 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 ], 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. Why that? I do not see a difference. > > or downgraded to a lower-priority behaviour aggregate, > MM: I do not understand how this helps in this context > > [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 > > 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. > > > Therefore, I do not think that a pointer to S3.6 in RFC5559 is enough. > > Regards, > > Michael > > > > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 23 March 2011 16:16 > To: Toby Moncaster > Cc: Eardley,PL,Philip,DES8 R;tom111.taylor@bell.net ;ietfdbh@comcast.net ;pcn@ietf.org > Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Toby and all, > > Am 23.03.2011 16:07, schrieb Toby Moncaster: > > -----Original Message----- > > From:pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > philip.eardley@bt.com > > Sent: 23 March 2011 10:28 > > To:tom111.taylor@bell.net ;ietfdbh@comcast.net > > Cc:pcn@ietf.org > > Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > > > << Non-PCN packets MAY share the network with PCN packets > > within the domain.>> > > the assumption has been that there will be non pcn-packets/ > > Or even: "PCN has been designed to allow non-PCN packets to share the > > PCN-domain"? > > > > > > 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.) > > This should probably be reported as an RFC erratum > > > > 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. > > 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, > > 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 > > 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. > > 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 > > 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). > > 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. > > > In fact, I think rfc5559 already has enough:- > > 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 > > > > > > << 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) > > 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 > > > > -----Original Message----- > > From:pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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) > > > > 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." > > 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). > > > > 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. > > 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 > > > > > > 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. > > > > ... > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > 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:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --------------070804010104090109090305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Phil,

Am 23.03.2011 18:50, schrieb philip.eardley@bt.com:

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]
Sent: 23 March 2011 17:35
To: Eardley,PL,Philip,DES8 R
Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Phil,

Am 23.03.2011 18:21, schrieb philip.eardley@bt.com:
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], 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. 

Why that? I do not see a difference.

   or downgraded to a lower-priority behaviour aggregate,

MM: I do not understand how this helps in this context

[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

   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.

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

Regards,

Michael

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

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]

Sent: 23 March 2011 16:16

To: Toby Moncaster

Cc: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org

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

Hi Toby and all,

Am 23.03.2011 16:07, schrieb Toby Moncaster:

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

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of

philip.eardley@bt.com

Sent: 23 March 2011 10:28

To: tom111.taylor@bell.net; ietfdbh@comcast.net

Cc: pcn@ietf.org

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

<<  Non-PCN packets MAY share the network with PCN packets

within the domain.>>

the assumption has been that there will be non pcn-packets/

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

PCN-domain"?

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

This should probably be reported as an RFC erratum

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.

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,

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

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.

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

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

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.

In fact, I think rfc5559 already has enough:-

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

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

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

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

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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)

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

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

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.

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

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

     response to congestion would be much harder.

so I think this section needs a little more work.

...

_______________________________________________

PCN mailing list

PCN@ietf.org

https://www.ietf.org/mailman/listinfo/pcn

_______________________________________________

PCN mailing list

PCN@ietf.org

https://www.ietf.org/mailman/listinfo/pcn

_______________________________________________

PCN mailing list

PCN@ietf.org

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:menth@uni-tuebingen.de

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

-- 
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:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de

--------------070804010104090109090305-- From toby@moncaster.com Wed Mar 23 13:38:50 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDD928C0E5 for ; Wed, 23 Mar 2011 13:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWWuW5AeeJlu for ; Wed, 23 Mar 2011 13:38:48 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id A6ACC3A68D2 for ; Wed, 23 Mar 2011 13:38:47 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MHKKd-1QFR8V0aAt-00EGSu; Wed, 23 Mar 2011 21:40:16 +0100 From: "Toby Moncaster" To: "'Michael Menth'" References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <002f01cbe981$17e074b0$47a15e10$@com> <4D8A4F6A.2070505@informatik.uni-tuebingen.de> In-Reply-To: <4D8A4F6A.2070505@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 20:40:15 -0000 Message-ID: <004401cbe99a$842231e0$8c6695a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvpk9CjOnFBoa9KRw2M7J2Ex+v7+wABfYxQ Content-Language: en-gb X-Provags-ID: V02:K0:1f1l39bSSBF1u9CRO7IQdg0Hjo6LRUMPkXXVsdtRz8o gK9d3KqU2VFu66vKyakK5EvW1OAS6TeaQQgUkPAeJvLHATeZEQ 5CzQs2Zw/2Q36dCuG+ONHs4HzAXREyWwXlGguZklep0RNUoimk SIUzYD5855G3vg8NDe3sXpKbsR8y26Eq/fBtm67ddgHSz+Fn01 CCwBATVI46q4xR41IHw3fDSmNIr5DtLPIkwTu3fRJI= Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:38:50 -0000 Inline (heavily snipped) > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 23 March 2011 19:52 > To: Toby Moncaster > Cc: philip.eardley@bt.com; tom111.taylor@bell.net; ietfdbh@comcast.net; > pcn@ietf.org > Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > >> 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. > > 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... > 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. 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. > > > 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. > 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. 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 menth@informatik.uni-tuebingen.de Wed Mar 23 13:39:42 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7C53A68D6 for ; Wed, 23 Mar 2011 13:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QKg9CNwDC0O for ; Wed, 23 Mar 2011 13:39:40 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 0E7193A68D2 for ; Wed, 23 Mar 2011 13:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1DD8252C9; Wed, 23 Mar 2011 21:41:09 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOHA7isEVJQW; Wed, 23 Mar 2011 21:41:03 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 209B35280; Wed, 23 Mar 2011 21:41:03 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id D217AF0E2DD; Wed, 23 Mar 2011 21:41:02 +0100 (CET) Message-ID: <4D8A5ADF.2050707@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 21:41:03 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Toby Moncaster References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> <003d01cbe983$b2fc0700$18f41500$@com> In-Reply-To: <003d01cbe983$b2fc0700$18f41500$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:39:42 -0000 Hi Toby, Am 23.03.2011 18:56, schrieb Toby Moncaster: > One thought that adds a twist: What if the e2e transport decides to run ECN > 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 > 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? 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 > Toby > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: 23 March 2011 17:22 >> To: menth@informatik.uni-tuebingen.de; toby@moncaster.com >> Cc: tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org >> Subject: RE: [PCN] cl-edge: text for processing of ECN (section 5.2.1) >> >> 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:menth@informatik.uni-tuebingen.de] >> Sent: 23 March 2011 16:16 >> To: Toby Moncaster >> Cc: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; >> ietfdbh@comcast.net; pcn@ietf.org >> Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) >> >> Hi Toby and all, >> >> Am 23.03.2011 16:07, schrieb Toby Moncaster: >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >> Of >>>> philip.eardley@bt.com >>>> Sent: 23 March 2011 10:28 >>>> To: tom111.taylor@bell.net; ietfdbh@comcast.net >>>> Cc: pcn@ietf.org >>>> Subject: Re: [PCN] cl-edge: text for processing of ECN (section >> 5.2.1) >>>> << Non-PCN packets MAY share the network with PCN packets >>>> within the domain.>> >>>> the assumption has been that there will be non pcn-packets/ >>> Or even: "PCN has been designed to allow non-PCN packets to share the >>> PCN-domain"? >>> >>> >>>> 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.) >>> This should probably be reported as an RFC erratum >>> >>>> 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. >>> 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, >> 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 >>> 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. >> 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 >>> 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). >> 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. >> >>>> In fact, I think rfc5559 already has enough:- >>> 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 >> >> >>>> << 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) >>> 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 >>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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) >>>> 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." >>> 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). >>> >>>> 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. >>> 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 >>> >>> >>>> 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. >>>>> >>>> ... >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> 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:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Wed Mar 23 13:43:32 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DF53A68D6 for ; Wed, 23 Mar 2011 13:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjCNpCfcjvns for ; Wed, 23 Mar 2011 13:43:17 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 3BA2728C0F9 for ; Wed, 23 Mar 2011 13:43:17 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LyhBT-1Pz0eJ3Aal-0166T9; Wed, 23 Mar 2011 21:44:46 +0100 From: "Toby Moncaster" To: "'Michael Menth'" , References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> <4D8A2F60.3090009@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net> <4D8A50E7.6010304@informatik.uni-tuebingen.de> In-Reply-To: <4D8A50E7.6010304@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 20:44:43 -0000 Message-ID: <004501cbe99b$2442ee80$6cc8cb80$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CBE99B.2442EE80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvplLMi6vpCSamuS9avKQ5F2h6w/QABex6Q Content-Language: en-gb X-Provags-ID: V02:K0:TOmZSyW066iVArH+zAsw0p2vJo7b/rV2M6N3bjTgLRB 9equWyromIv6Lfelm3KBYAqaXhawPYAp2ig279umfZwCQoYOe/ LrY6g4ND28uD8Q0jxafeyqT3QtukaoPr8xGFtnPjyN5iSZiQeZ 3VitHWPS6hS29rSBhgrVFMiXXGXspwPZ7FQm1egq3rvVXBaD9E 8jLQysqYVGTBjRGhj99IdQTSnnq/nYhdU9yrcTdTiI= Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:43:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0046_01CBE99B.2442EE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] Sent: 23 March 2011 19:59 To: philip.eardley@bt.com Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Hi Phil, Am 23.03.2011 18:50, schrieb philip.eardley@bt.com: From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] Sent: 23 March 2011 17:35 To: Eardley,PL,Philip,DES8 R Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Hi Phil, Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: 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 ], 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. Why that? I do not see a difference. {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. or downgraded to a lower-priority behaviour aggregate, MM: I do not understand how this helps in this context [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. Therefore, I do not think that a pointer to S3.6 in RFC5559 is enough. Regards, Michael -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] Sent: 23 March 2011 16:16 To: Toby Moncaster Cc: Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Hi Toby and all, Am 23.03.2011 16:07, schrieb Toby Moncaster: -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 23 March 2011 10:28 To: tom111.taylor@bell.net; ietfdbh@comcast.net Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) << Non-PCN packets MAY share the network with PCN packets within the domain.>> the assumption has been that there will be non pcn-packets/ Or even: "PCN has been designed to allow non-PCN packets to share the PCN-domain"? 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.) This should probably be reported as an RFC erratum 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. 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, 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 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. 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 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). 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. In fact, I think rfc5559 already has enough:- 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 << 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) 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 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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) 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." 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). 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. 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 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. ... _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de ------=_NextPart_000_0046_01CBE99B.2442EE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] =
Sent: 23 March 2011 19:59
To: = philip.eardley@bt.com
Cc: toby@moncaster.com; = tom111.taylor@bell.net; ietfdbh@comcast.net; = pcn@ietf.org
Subject: Re: [PCN] cl-edge: text for processing = of ECN (section 5.2.1)

Hi = Phil,

Am 23.03.2011 18:50, schrieb philip.eardley@bt.com: =

From: Michael Menth [mailto:menth@informatik= .uni-tuebingen.de]
Sent: 23 March 2011 = 17:35
To: Eardley,PL,Philip,DES8 R
Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org
Subject: Re: = [PCN] cl-edge: text for processing of ECN (section = 5.2.1)

Hi = Phil,

Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: =

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], 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. =

Why that? I do not see a = difference.

{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. =

 &nbs=
p; or downgraded to a lower-priority behaviour aggregate, =

MM: I do not understand how this helps in this =
context

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

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

Regards,

= Michael

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

From: Michael Menth =
[mailto:menth@informatik=
.uni-tuebingen.de]

Sent: 23 March 2011 =
16:16

To: Toby Moncaster

Cc: =
Eardley,PL,Philip,DES8 R; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org

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

Hi Toby and =
all,

Am 23.03.2011 =
16:07, schrieb Toby Moncaster:

-----Original =
Message-----

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On =
Behalf Of

philip.eardley@bt.com

Sent: 23 March 2011 10:28

To: tom111.taylor@bell.net; ietfdbh@comcast.netCc: pcn@ietf.org
Subjec=
t: Re: [PCN] cl-edge: text for processing of ECN (section =
5.2.1)
 
<<  =
Non-PCN packets MAY share the network with PCN =
packets
within the =
domain.>>
the assumption has been that there =
will be non pcn-packets/

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

PCN-domain"?

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=3D00.)

This =
should probably be reported as an RFC =
erratum

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.

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,

What do you mean by =
that?

downgrading,

What do you mean by =
that?

dropping,<=
/pre>

Just CE-packets or also =
ECT(x)?

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.

Wh=
at does admitted mean in this context? Certainly different from =

"admission control" =
...

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

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.

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

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

Th=
e 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,

  &nbs=
p;  =
Michael

 <<  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
   &nb=
sp;   the alternative ECN =
semantics;
 
  &=
nbsp; 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
   &n=
bsp;   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".>>
 
si=
nce 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
 
-----Original =
Message-----
From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] 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)
 
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."
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).
 
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.
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."
 
&nb=
sp;
Toby
  
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.

...

_______________________________________________<=
/o:p>

PCN mailing list

PCN@ietf.org

https://www.ietf.org/m=
ailman/listinfo/pcn

____________________________=
___________________

PCN mailing =
list

PCN@ietf.org

https://www.ietf.org/m=
ailman/listinfo/pcn

_______________=
________________________________

PCN mailing =
list

PCN@ietf.org

https://www.ietf.org/m=
ailman/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:menth@uni-tuebingen.de<=
o:p>

http://www-kn.informat=
ik.uni-tuebingen.de

-- =

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:menth@uni-tuebingen.de<=
o:p>

http://www-kn.informat=
ik.uni-tuebingen.de

------=_NextPart_000_0046_01CBE99B.2442EE80-- From menth@informatik.uni-tuebingen.de Wed Mar 23 13:47:26 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423133A68D6 for ; Wed, 23 Mar 2011 13:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpeu7f9D9kHY for ; Wed, 23 Mar 2011 13:47:25 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 0350F3A6948 for ; Wed, 23 Mar 2011 13:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1A05152C9; Wed, 23 Mar 2011 21:48:58 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pqji8bqQUpz; Wed, 23 Mar 2011 21:48:55 +0100 (MET) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E6CAD5280; Wed, 23 Mar 2011 21:48:54 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id A1D48176710E; Wed, 23 Mar 2011 21:48:54 +0100 (CET) Message-ID: <4D8A5CB7.30909@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 21:48:55 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Toby Moncaster References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <002f01cbe981$17e074b0$47a15e10$@com> <4D8A4F6A.2070505@informatik.uni-tuebingen.de> <004401cbe99a$842231e0$8c6695a0$@com> In-Reply-To: <004401cbe99a$842231e0$8c6695a0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:47:26 -0000 Hi Toby, >>> 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. >> 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. > 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 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 > Toby > > -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Wed Mar 23 13:51:49 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CC23A694C for ; Wed, 23 Mar 2011 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NTEoe8du4Hh for ; Wed, 23 Mar 2011 13:51:48 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by core3.amsl.com (Postfix) with SMTP id A46803A6949 for ; Wed, 23 Mar 2011 13:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3C0895283; Wed, 23 Mar 2011 21:53:18 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJaOKPGgTVBU; Wed, 23 Mar 2011 21:53:13 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E65185256; Wed, 23 Mar 2011 21:53:12 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4490BF0E3E2; Wed, 23 Mar 2011 21:53:12 +0100 (CET) Message-ID: <4D8A5DB8.5090805@informatik.uni-tuebingen.de> Date: Wed, 23 Mar 2011 21:53:12 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Toby Moncaster References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> <4D8A2F60.3090009@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net> <4D8A50E7.6010304@informatik.uni-tuebingen.de> <004501cbe99b$2442ee80$6cc8cb80$@com> In-Reply-To: <004501cbe99b$2442ee80$6cc8cb80$@com> Content-Type: multipart/alternative; boundary="------------010106090901010102010208" Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:51:49 -0000 This is a multi-part message in MIME format. --------------010106090901010102010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Toby, Am 23.03.2011 21:44, schrieb Toby Moncaster: > > *From:*Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > *Sent:* 23 March 2011 19:59 > *To:* philip.eardley@bt.com > *Cc:* toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; > pcn@ietf.org > *Subject:* Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Phil, > > Am 23.03.2011 18:50, schrieb philip.eardley@bt.com: > > > *From:*Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > *Sent:* 23 March 2011 17:35 > *To:* Eardley,PL,Philip,DES8 R > *Cc:* toby@moncaster.com ; > tom111.taylor@bell.net ; > ietfdbh@comcast.net ; pcn@ietf.org > > *Subject:* Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Phil, > > Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: > > > 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 ], 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. > > Why that? I do not see a difference. > > {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 -- 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:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --------------010106090901010102010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Toby,

Am 23.03.2011 21:44, schrieb Toby Moncaster:

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]
Sent: 23 March 2011 19:59
To: philip.eardley@bt.com
Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Phil,

Am 23.03.2011 18:50, schrieb philip.eardley@bt.com:

From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]
Sent: 23 March 2011 17:35
To: Eardley,PL,Philip,DES8 R
Cc: toby@moncaster.com; tom111.taylor@bell.net; ietfdbh@comcast.net; pcn@ietf.org
Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1)

Hi Phil,

Am 23.03.2011 18:21, schrieb philip.eardley@bt.com:
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], 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. 
Why that? I do not see a difference.

{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

-- 
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:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de

--------------010106090901010102010208-- From toby@moncaster.com Thu Mar 24 03:43:01 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBED3A686A for ; Thu, 24 Mar 2011 03:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwW-neB+vflU for ; Thu, 24 Mar 2011 03:42:59 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id B17593A67ED for ; Thu, 24 Mar 2011 03:42:58 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MLkJD-1Q1t4z2W6V-000vVM; Thu, 24 Mar 2011 11:44:27 +0100 From: "Toby Moncaster" To: "'Michael Menth'" References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <002f01cbe981$17e074b0$47a15e10$@com> <4D8A4F6A.2070505@informatik.uni-tuebingen.de> <004401cbe99a$842231e0$8c6695a0$@com> <4D8A5CB7.30909@informatik.uni-tuebingen.de> In-Reply-To: <4D8A5CB7.30909@informatik.uni-tuebingen.de> Date: Thu, 24 Mar 2011 10:44:26 -0000 Message-ID: <002901cbea10$727e5790$577b06b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acvpm7sxmipLcGZSSxmA8dze76nPpgAdDiOw Content-Language: en-gb X-Provags-ID: V02:K0:IaXIIOkxFLLlv26ceh7ch5at3OHPAtqcMLMV6wvW3Yi JhpmJthpLcQC4nWLobBqcsC5hik/iZ84SmaVp12x8QwCtYK0GX easmV0UbT3k2E1bY3T0JstpX6I/sU3TzxqiS2zr1Hcl6he51Xd l7kfV4LgsUEp3qZWpGcCCZMtg/yhepyR1sJIRgP3IWZdGJGOeL +VBWbSyRwgotIsLXwkyZOAGK0XdctZZvg/q0zMtNfA= Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 10:43:01 -0000 Michael, > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 23 March 2011 20:49 > To: Toby Moncaster > Cc: philip.eardley@bt.com; tom111.taylor@bell.net; ietfdbh@comcast.net; > pcn@ietf.org > Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) > > Hi Toby, > > >>> 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. > >> 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. > > 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 > > 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. 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 > > Michael > > > Toby > > > > > > -- > 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:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Thu Mar 24 04:23:12 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C77D3A680F for ; Thu, 24 Mar 2011 04:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRei5m0NO1Ma for ; Thu, 24 Mar 2011 04:23:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 9BFCF3A67FA for ; Thu, 24 Mar 2011 04:23:05 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 24 Mar 2011 11:24:39 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.151]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 24 Mar 2011 11:24:39 +0000 From: To: , Date: Thu, 24 Mar 2011 11:24:37 +0000 Thread-Topic: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Thread-Index: AcvpnF0DYA78dDHzTTm75bVCDBU8+wAd/MWg Message-ID: <9510D26531EF184D9017DF24659BB87F327CF40FD4@EMV65-UKRD.domain1.systemhost.net> References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1> <9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net> <002801cbe96c$06981100$13c83300$@com> <4D8A1CDB.6000705@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net> <4D8A2F60.3090009@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net> <4D8A50E7.6010304@informatik.uni-tuebingen.de> <004501cbe99b$2442ee80$6cc8cb80$@com> <4D8A5DB8.5090805@informatik.uni-tuebingen.de> In-Reply-To: <4D8A5DB8.5090805@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F327CF40FD4EMV65UKRDdoma_" MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 11:23:12 -0000 --_000_9510D26531EF184D9017DF24659BB87F327CF40FD4EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: Does S3.6 from rfc5559 clarify most of your questions? I agree with you that it would be worth then spelling out what "tunnelled t= hrough 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 lik= e a to-do-list rather than a solution. Also the text 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 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. Why that? I do not see a difference. {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 ente= ring 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 shar= e 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 i= n 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 no= t (despite what i said above - brain not fully engaged at the time). The re= ason is that the PCN-egress-node colouring function sets the ECN field to 0= 0. 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 EC= T for some reason or other. --_000_9510D26531EF184D9017DF24659BB87F327CF40FD4EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Am 23.03.2011 18:21, sch= rieb phili= p.eardley@bt.com:

Doe=
s S3.6 from rfc5559 clarify most of your questions?

I =
agree with you that it would be worth then spelling out what "tunnelle=
d 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], the "appropriate =
action"

   is to block ECN-capable traf=
fic that uses the same DSCP as PCN from

   e=
ntering the PCN-domain directly.  "Blocking" means it is dro=
pped

MM: Dropping ECT(0) or ECT(1) packets is certain=
ly 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.

Why that? I do not see a difference.

{TM} I think what Phil means is that if you let ECT in= to 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 the= y are already marked.

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

= [phil] toby, you got my reasoning.

Michael, they are not PCN packets; t= hey 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 p= eople 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 E= CT is ok, in fact it is not (despite what i said above – brain not fu= lly 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 w= ould result in them exiting the PCN-domain as 00. This potentially confuses= ECN endpoints which have set ECT for some reason or other.

= --_000_9510D26531EF184D9017DF24659BB87F327CF40FD4EMV65UKRDdoma_-- From karagian@cs.utwente.nl Thu Mar 24 06:57:05 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F1E3A68C2 for ; Thu, 24 Mar 2011 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16WIJjDUdLEJ for ; Thu, 24 Mar 2011 06:56:59 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id CEE443A68C0 for ; Thu, 24 Mar 2011 06:56:58 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p2ODw6vu012743; Thu, 24 Mar 2011 14:58:09 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <0DF92E3B84734E8A9C764B56EE60D628@23FX1C1><9510D26531EF184D9017DF24659BB87F327CF40657@EMV65-UKRD.domain1.systemhost.net><002801cbe96c$06981100$13c83300$@com><4D8A1CDB.6000705@informatik.uni-tuebingen.de><9510D26531EF184D9017DF24659BB87F327CF40C14@EMV65-UKRD.domain1.systemhost.net><4D8A2F60.3090009@informatik.uni-tuebingen.de><9510D26531EF184D9017DF24659BB87F327CF40C45@EMV65-UKRD.domain1.systemhost.net><4D8A50E7.6010304@informatik.uni-tuebingen.de><004501cbe99b$2442ee80$6cc8cb80$@com><4D8A5DB8.5090805@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F327CF40FD4@EMV65-UKRD.domain1.systemhost.net> Date: Thu, 24 Mar 2011 14:58:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CBEA33.E9798CC0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9510D26531EF184D9017DF24659BB87F327CF40FD4@EMV65-UKRD.domain1.systemhost.net> Thread-Index: AcvpnF0DYA78dDHzTTm75bVCDBU8+wAd/MWgAAVx5/A= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 24 Mar 2011 14:58:19 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 13:57:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01CBEA33.E9798CC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: donderdag 24 maart 2011 12:25 To: menth@informatik.uni-tuebingen.de; toby@moncaster.com Cc: pcn@ietf.org Subject: Re: [PCN] cl-edge: text for processing of ECN (section 5.2.1) Am 23.03.2011 18:21, schrieb philip.eardley@bt.com: 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 ], 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. Why that? I do not see a difference. {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. ------=_NextPart_000_002D_01CBEA33.E9798CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil, Hi all

Regarding the use of ECN signaling for other = purposes, I=20 think that you refer to:

http://www.watersprings.org/pub/id/draft-westerlund-avt-ecn-fo= r-rtp-02.txt

From what I remember, section 3.6. Backwards = Compatibility=20 of RFC5559, was derived after the discussions that we have had in the = context of=20 the above mentioned draft.

Therefore, I think that we sould refer and use as much as = possible=20 section 3.6 of RFC5559 for this challenge.

What=20 we however, have to discuss is if and how RFC6040, would change the = "appropriate=20 action" mentioned in Section 3.6.

If=20 yes, then we will have to mention these new actions in the new PCN edge=20 behaviour documents, if possible!

Best=20 regards,

Georgios

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: donderdag 24 maart 2011=20 12:25
To: menth@informatik.uni-tuebingen.de;=20 toby@moncaster.com
Cc: pcn@ietf.org
Subject: Re: = [PCN]=20 cl-edge: text for processing of ECN (section = 5.2.1)
Am 23.03.2011 18:21, schrieb = philip.eardley@bt.com:
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=20 look to me more like a to-do-list rather than a solution. Also the = text=20
   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
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. =

Why that? I do not see a difference.

{TM} I think what Phil means is that if you = let ECT=20 into a baseline RFC5696 PCN-domain then they just act as PCN packets, = but if=20 you let them into a 3-in-1 PCN-domain, a fraction of them may act as = if they=20 are already marked.
The ECN field of PCN packets is set to NM by = the=20 PCN-ingress-node when entering the PCN domain. That's why I do not = understand=20 this reasoning.

[phil] toby, you = got my=20 reasoning.

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

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

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

Betreff:	Re: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt
Datum:	Mon, 21 Mar 2011 17:47:51 +0100
Von:	Michael Menth <menth@informatik.uni-tuebingen.de>
An:	Steven Blake <slblake@petri-meat.com>, "pcn@ietf.org" <pcn@ietf.org>