Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

From: <[email-masked]>
Date: Fri, 18 Sep 2009 14:09:38 -0400

I'm going to back up to a high-level summary on this one.

The four ECN field values are Not-CET, ECT(0), ECT(1) and CE.
Going back to RFC 3168, ECT(0) and ECT(1) are specified as
peer values - same meaning, either can be used.

PCN would like to use ECT(0) and ECT(1) as ordered values with
ECT(1) denoting a lesser level of congestion than that denoted
by the CE value.

I have no problem with PCN doing that, *as long as* the result
does not obstruct possible future uses that treat ECT(0) and
ECT(1) as unordered values.  Hence I view any mechanism that
is based on ordering ECT(0) and ECT(1) as PCN-specific and
want such mechanisms to be in PCN documents, not ECN documents.

That leads to the following ECN tunnel specifics, which I think
cover everything that's open in discussion.  My views are:
- Not-ECT [inner], CE [outer] -> Drop is ok.  This is a serious
	error case.
- Not-ECT [inner]:  ECT(0) [outer] and ECT(1) [outer] should
	have the same behavior.  That behavior could be Forward
	with Not-ECT or Drop.
- ECT(0) [inner], ECT(1) [outer] and
  ECT(1) [inner], ECT(0) [outer]: These two should have the
	same behavior.  Since PCN considers one of these to be
	a normal case that should not raise an alarm, no alarm
	should be raised for either of these combinations.

Let's see if that's enough to move this towards a conclusion.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Wednesday, August 05, 2009 8:56 AM
> To: [email-masked]
> Subject: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> 
> hi
> i wanted to follow up on this from stockholm. i've tried to 
> catch up with bob & david's discussion, sorry for where my 
> reading is incomplete.
>  
> - tunnel egress behaviour for 3168 & 4301 is inconsistent, 
> amongst other motivations for change to a single consistent 
> tunnel egress behaviour
>  
> - one set of changes is about
> inner: not-ect
> outer: isn't not-ect
> which should neve be seen.
> i think bob & david have converged (?). i have no desire to 
> upset their convergence!
>  
> - another cahnge is about:
> inner: ect(0)
> outer: ect(1)
> decaps header: ect(1)
> this is a change from the current specs, although it's 
> somethng that should never be seen. 
> making this change enables 2 levels of congestion severity.
> i think bob & david both agree with this change.
>  
> the point where there is disagreement:
> David: in environements without 2 levels of congestion 
> severity, then this is an error, so the tunnel egress MAY 
> raise an alarm.
> Bob: don't raise an alarm. 
>  
> David, my argument against your view is: this 'MAY raise an 
> alarm' is actually different from all the other combinations 
> of codepoints where the egress 'MAY raise an alarm'. in those 
> other cases it's always the right thing for the egress to do. 
> in this case however, if it's a domain that uses 2 levels of 
> congestion severity, then it MUST NOT raise an alarm (becuase 
> it's the expected behaviour), whereas if it's a domain that 
> uses 1 level of congestion severity, then it MAY raise an 
> alarm (becuase something's wrong).
> to me the simplest thing would be not to raise an alarm, so 
> there doesnt have to be different configuration depending on 
> the domain. if the std does mention the alarm then somehow it 
> has to be very clear that this is different from the other alarms.
>  
> best wishes
> phil
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Sep 2009 17:57:32 +0100

David,

In the process of answering Phil's point from early Aug about alarms, 
your response reveals differences over primary goals. I felt I should 
jump in to try to get consensus on goals, then we can get back to alarms...

At 19:09 18/09/2009, [email-masked] wrote:
>ECT(1) as unordered values.

We already have an existing use (the nonce) that treats the two the 
same and ecn-tunnel-03 doesn't obstruct that. You now want to also 
cater for some possible future case where ECT(0) & ECT(1) are still 
unordered but also somehow different to the current unordered case. 
This is surely becoming rather esoteric and unattainable.

>Hence I view any mechanism that

Can we agree ECT(0) and ECT(1) need the same behaviour; but only for 
cases that can actually occur in any known ECN environment?

This is critical to consensus, because I've found a way to support 
PCN by only updating cases that can never occur in any known ECN 
environment. Then a single updated tunnel behaviour still does 
exactly what ECN traffic would expect, but it also supports PCN.

If we're free to change the cases that ECN never uses, then we can 
have a single tunnel behaviour for all purposes - a big win.

Bob

> > has to be very clear that this is different from the other alarms.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Mon, 28 Sep 2009 08:48:06 -0400

Bob,

> Can we agree ECT(0) and ECT(1) need the same behaviour;

This is ok, but for the rest of the concern:

> but only for cases that can actually occur in any known ECN
environment?

What are the specific cases where you want to treat ECT(0) and
ECT(1) differently, and why?

Thanks,
--David

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: Tuesday, September 22, 2009 12:58 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; Black, David
> Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> 
> David,
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 28 Sep 2009 15:33:02 +0100

David,

At 13:48 28/09/2009, [email-masked] wrote:
>ECT(1) differently,

You enumerated the two cases from the draft yourself (lower down this 
mail thread). I've repeated them below.

>and why?

The reasoning is in the draft, but here's a brief recap....

1/ Not-ECT [inner]
------------------
> > >         have the same behavior.  That behavior could be Forward

Both these cannot occur in an ECN environment unless something's broken.

ECT(0) [outer] was safe for the egress to forward as Not-ECT, and 
nothing has changed to make it any less safe.

ECT(1) [outer] was safe to forward as Not-ECT up to now,... but once 
PCN exists, this broken combination might be caused by rogue PCN 
routers set up in the wrong place in the Internet, so rather than 
remove a marking that might imply congestion, it's safer to drop.

Obviously, rogue conditions can be caused by anything, so it's a 
balance of probabilities what you do with them. The above is as safe 
as necessary while still allowing some room for future evolution.

2/ ECT(0) [inner]
-----------------
ECT(0) [inner] and
ECT(0) [outer] => ECT(0) [forwarded]
because this is normal in an ECN environment and no different for PCN.

ECT(0) [inner] and
ECT(1) [outer] => ECT(1) [forwarded]
This cannot occur in an ECN environment unless something's broken, 
but it's normal in a PCN environment.

The idea is to avoid any tunnel logic having to be configured to 
check whether the DSCP implies ECN or PCN marking. Only operators 
wanting PCN need to actually insist that vendors comply with this 
update. But it works for either ECN or PCN (because ECN doesn't use 
this combination).

[let's defer talking about alarms until we agree on functions.]

Is this clearer now?

Bob

---

From: <[email-masked]>
Date: Mon, 28 Sep 2009 15:41:19 +0100

David

I know you & bob are discussing other points, but on the point I raised,
I confirm that I think we've converged, ie 
" ECT(0) [inner], ECT(1) [outer] and
  ECT(1) [inner], ECT(0) [outer]:
... no alarm
	should be raised for either of these combinations"

thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 18 September 2009 19:10
To: Eardley,PL,Philip,DER3 R; [email-masked]
Cc: [email-masked]
Subject: RE: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

Thanks,
--David

---

From: <[email-masked]>
Date: Wed, 30 Sep 2009 02:28:13 -0400

Bob,

I started out to write a much longer message, but I'm ok with much
of what you've written.  The only case where I think we aren't yet

> > > >         have the same behavior.  That behavior could be Forward

Whereas you want to Forward with Not-ECT in the ECT(0) [outer] case
vs. Drop in the ECT(1) [outer] case.  Both of these are error cases.

Let me suggest that if PCN will use ECT(1) to indicate a level of
congestion comparable to CE for ECN (non-PCN) traffic, then this
difference is justified, otherwise, I would forward with Not-ECT
in both cases to avoid dropping traffic that isn't causing non-PCN
congestion.  I'm presuming that CE has comparable ECN and PCN
meanings, justifying Drop for traffic that arrives with CE [outer]

Thanks,
--David

> Sent: Monday, September 28, 2009 10:33 AM
> To: Black, David
> Cc: [email-masked]; Black, David
> but only for