Subject: Re: [tsvwg] review of draft-ietf-tsvwg-ecn-tunnel-02 pt 1/2

From: Bob Briscoe <[email-masked]>
Date: Thu, 09 Jul 2009 20:08:07 +0100

David,

Bringing to the list as agreed. I'll reply in 2 parts. Part 1/2...

Your comments get to the nub of the proposed egress protocol changes. 
Great... inline...

At 00:43 09/07/2009, [email-masked] wrote:
>Bob,
>
>Sorry for the delay on this: things got entirely too busy around the
>end of the quarter here.  Having re-read the draft from scratch, I
>have a number of things to comment on ... I will be in Stockholm,
>and some of these items are going to need further discussion
>(private and/or public) in Stockholm.
>
>Starting with this table in Figure 4:
>
>+------------------+----------------------------------------------+
>|  Incoming Inner  |             Incoming Outer Header            |
>|      Header      +---------+------------+------------+----------+
>|                  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
>+------------------+---------+------------+------------+----------+
>|     Not-ECT      | Not-ECT |Not-ECT(!!!)|   drop(!!!)| drop(!!!)|
>|      ECT(0)      |  ECT(0) | ECT(0)     | ECT(1)     |   CE     |
>|      ECT(1)      |  ECT(1) | ECT(1)(!!!)| ECT(1)     |   CE     |
>|        CE        |      CE |     CE     |     CE(!!!)|   CE     |
>+------------------+---------+------------+------------+----------+
>                    |                Outgoing Header               |
>                    +----------------------------------------------+
>
>My initial focus is on what needs to change from RFC 3168/RFC 4301
>behavior and why.  Given that these two RFCs line up, I think changes
>need strong motivation.  So, here are the four changes, and my thoughts:
>
>a) Inner: Not-ECT, Outer: ECT(0)
>         3168/4301: drop (!!!)
>         Change: Not-ECT (!!!)
>         Rationale: "allow future standards actions to use this
>                 combination"
>         My view: This ain't broke, why are you fixing it?

It is broke in the sense tunnel egresses unnecessarily drop harmless 
packets merely because they carry a "currently unused" (CU) 
combination of codepoints. This is similar to the problem ECN faced 
with firewalls dropping packets unless they were Not-ECT.

(a) wasn't originally part of the changes I was proposing. But Anil 
Agawaal convinced me it is worth doing. Reasoning: If we are making a 
change to decap anyway, let's get it as right as possible. If we 
decide not to make any other changes to decap, I wouldn't fight for 
this one alone.

>b) Inner: ECT(0), Outer: ECT(1)
>         3168/4301: ECT(0)
>         Change: ECT(1)
>         Rationale: Treat ECT(1) as more severe congestion than ECT(0).
>         My view: Longer discussion below.
>
>c) Inner: ECT(1), Outer: ECT(0)
>         3168/4301: ECT(1)
>         Change: ECT(1) (!!!)
>         Rationale: "no currently legal transition" can produce this
>combo.
>         My view: Not a good idea, among other reasons because it's at
>                 odds with your "future standards action" explanation for
>                 the first change.  I'd remove this change and instead
>deal
>                 with the possibility of raising an alarm in a
>PCN-specific
>                 draft rather than declaring this to be an alarm-able
>combo
>                 in general.
>
>d) Inner: CE, Outer: ECT(1)
>         3168/4301: CE
>         Change: CE (!!!)
>         Rationale & My view: <same as previous change.

c) & d) aren't PCN specific.

Reasoning for adding alarms (also said this eariler on list in 
conversation with Gorry):
If security folks have concerns over possible attacks from "currently 
unused" combinations, I want to give them a way to manage the 
perceived threat without just dropping packets. RFC3168 recommended 
alarms for CU combinations. In these cases, I believe RFC3168 simply 
overlooked that these are also CU combinations.

>So, I would remove a) as not defensible (no good reason for change),
>and I would push the discussion of adding alarms for c) and d) into
>a PCN-specific document.

c) & d) are not to do with PCN.

My motivation is: While making change (b) to enable PCN, lets do 
(a,c,d) to make the IP layer as clean as possible, to ensure easier 
future evolvability.

I don't see the issue. It says SHOULD log and MAY alarm. So the 
operator doesn't have to do anything.

>The c) alarm in particular is only
>meaningful if PCN or something like it is in use.

No. The combination in c) always was CU, and it's still CU with PCN. 
None of the proposed changes are PCN-specific.

Even (b) is intended to also be useful for any 3-level ECN while not 
precluding 2-level ECN and the nonce.

NB:  3 level = 2 'congested' levels + 1 level not congested, e.g. VCP 
or PCN which were both mentioned in RFC4774. This doesn't count the 
not-ECN-capable state, which makes 4 states.

>I don't view d)
>as deserving of an alarm in general, as even though something has
>happened, no damage has been done - this is in line with the
>"be liberal in what you accept" principle of protocol design.

That's why I'm proposing an optional alarm. Optional alarms *are* 
liberal, but they allow operators a way to address security concerns 
about 'known unknowns' [Rumsfelt], while still allowing new 
behaviours to be introduced.

>That leaves b), which I think is the key desired change, because
>it makes a third ECN code point usable through tunnels.

Yes - exactly.

>Much as
>this might be useful for PCN, it may be too late to do this.  The
>problem starts from the need to say that this draft updates RFC 4301.
>The result will be a mix of 4301 and updated-4301 implementations
>that render the third state difficult to use in practice.  The
>problem's even worse for non-IPsec tunnels.

The idea is that an operator wanting to implement PCN will have a 
spec they can point to in their invitation to tender. At the same 
time this spec both UPDATEs and is backward compatible with RFC3168 & 
RFC4301 because it only changes CU stuff at egress and the change at 
the ingress leads to the same output at the egress. Therefore vendors 
can update 3168 & 4301 tunnels lazily - only when their customers ask 
for the new features (whether for PCN or for something else like VCP).

>I also read Appendix D
>as saying that PCN is going the two-state route, not three.

That's not how it should be read - I'll clarify it. The PCN w-g wants 
3 states, but can't have them while ecn-tunnel is not proposed 
standard. Therefore, it has decided to define a 2-state baseline and 
a number of experimental schemes to work round this tunnel issue 
(plus a comparison doc about them all). It has agreed that eventually 
just one experimental scheme will be chosen for standards track:
- 3-in-1 (the simplest, which depends on (b) of ecn-tunnel)
- 3-state (which uses an extra DSCP)
- psdm (which requires out of band state)
- sm (single marking gets 3 functions from 2 encoding states but 
admits admission control & termination aren't very precise in all cases)

___
See part 2/2 for responses to your comments on specific parts of the test.

Thanks again for the review

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: <[email-masked]>
Date: Fri, 10 Jul 2009 15:47:47 +0100

Just a brief email to say I generally support most of Bob's reasoning
here. Why put in place artificial blocks on currently unused transitions
that just constrain future standards. This really isn't just relevant to
PCN, it just happens that PCN is (seemingly) the first protocol that has
hit this as an obstruction and so it is as a result of PCN that this
issue has come to the fore...

Clearly once you have RFC4774 on guidelines for re-using the ECN
codepoints you need to assume that novel uses for the ECN codepoints
will come up. To then constrain them because of contradictory, outdated
or restrictive tunnelling rules is just digging a hole and reducing
their chance of success, thus stifling innovation in the transport
layer. 

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bob Briscoe
> Sent: 09 July 2009 20:08
> To: [email-masked]
> Cc: [email-masked]; tsvwg IETF list
> Subject: Re: [tsvwg] review of draft-ietf-tsvwg-ecn-tunnel-02 pt 1/2
> 
> David,
>

---

From: <[email-masked]>
Date: Fri, 10 Jul 2009 12:09:37 -0400

Quick summary of the four changes proposed in the draft:

a) Inner: Not-ECT, Outer: ECT(0)
	RFC 3168/4301: drop(!!!), Change: Not-ECT(!!!)
b) Inner: ECT(0), Outer: ECT(1)
	RFC 3168/4301: ECT(0), Change: ECT(1)
c) Inner: ECT(1), Outer: ECT(0)
	RFC 3168/4301: ECT(1), Change: ECT(1)(!!!)
d) Inner: CE, Outer: ECT(1)
	RFC 3168/4301: CE, Change: CE(!!!)

If we were designing from scratch, all of these changes would
be fine things to do.  We're not, and especially after the
discussion of how this impacts RFC 2003 gets added, this
draft will be proposing changes to some of the most widely
deployed mechanisms in the Internet.  To me, that strongly
suggests a conservative design approach - focus on what really
needs to be changed, and resist them temptation to fix other
things that would be "nice to have".  In other words, IMHO
the appropriate criteria for "fixing it" is a very strong
cast that "it's broken".

This is an area of principled disagreement on goals between
Bob and myself that list discussion is unlikely to resolve.
My view of the above four changes is that only b) makes it
over the "really needs to be changed" bar (and even then,
only with a *much* stronger statement of the PCN-based
rationale than is in the current draft, and Bob concurs
with strengthening the rationale).

Turning to the other three changes, a) is clearly described
as "nice to have", enough said.

For c) and d), I don't believe the optional alarms are
justified based on ECN (RFC 3168) alone.  A key observation
is that this draft does not make the < b) ECT(0) [Inner]
to ECT(1) [Outer], forward with ECT(1) > case subject to an
optional alarm.  What this means is that this draft not only
enables three codepoints (ECT(0), ECT(1) and CE), but it
*assumes* that they are ordered in terms of priority,
severity, or something analogous.  That is unwarranted as
a general design assumption, IMHO.

For this, reason, I think discussion of which transitions are
optionally alarm-able in this fashion belongs in the context of
a protocol that actually orders these codepoints, not in a
general document that would serve to "just constrain future
standards," borrowing Toby's words ;-).

I could see discussion of optional alarms in an Appendix that
discusses 3-valued PCN as an example, but not in the main body
of the draft.  In the main body, it would be fine to say that
specific uses of the ECN codepoints may assign meanings that
cause some of these transitions to be appropriate for alarms
(and point to the Appendix for a PCN example), but it would
not be ok to constrain the assignment of those meanings by
making the ECT(0) [Inner] to ECT(1) [Outer] change not
optionally alarm-able.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bob Briscoe
> Sent: Thursday, July 09, 2009 3:08 PM
> To: Black, David
> >         Rationale: "no currently legal transition" can 
> produce this combo.
> >                 the first change.  I'd remove this change 
> and instead deal
> >                 with the possibility of raising an alarm in 
> a PCN-specific
> >                 draft rather than declaring this to be an 
> alarm-able combo
> >                 in general.
> >
> >         Rationale & My view: <same as previous change>
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 10 Jul 2009 18:31:37 +0100

David,

I'm not so pessimistic about reaching consensus on the list. This is 
all about the 3 "nice to have" things (a,c,d). As I've already said, 
none are anything to do with PCN. All the controversial combinations 
are currently unused by ECN and currently unused by PCN.

Our disagreement is over this abstract principle:
When changing something that's needed, is it worse or better to leave 
other things unchanged that would be "nice to have" (ie. things that 
are closing off  future evolvability)?

You say it's better to leave them unchanged. Why?

I say it's worse to leave them unchanged, because you get a big 
potential future gain for minimal extra effort. It costs diddly-squat 
to make 4 changes to a code block if you're already going to make 1 
change. It requires nearly the same testing, etc etc. In return you 
get a greater chance of 3 extra usable codepoint combinations in the IP header.

I look at the 5 different ways that ECN tunnelling has gone through 
in the past, and I think "if we're going to add a 6th, let's avoid a 7th".

Bob

---

From: <[email-masked]>
Date: Fri, 10 Jul 2009 18:28:23 -0400

Bob,

Actually it's only about a) if you can accept the following
approach for the optional alarms in c) and d):

- Main body of draft says that specific uses of ECN may raise
	optional decapsulation alarms for selected cases in which
	the inner and outer header values don't match.
- An Appendix that discusses PCN as an example points out that
	for PCN, it is appropriate to raise alarms for c) and d).

As for "How does this have anything to do with PCN?", the answer
to that question is the same as the answer to "Why does the
draft not propose an optional alarm for case b)?" ...  the
answer is probably some form of "no current use", in which case,
what's the current use for the c) and d) alarms? ... it's PCN.

Thanks,
--David

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: Friday, July 10, 2009 1:32 PM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: [tsvwg] review of draft-ietf-tsvwg-ecn-tunnel-02 pt 1/2
> 
> David,
> 
> > > >|      Header      
> +---------+------------+------------+----------+
> > > >                    |                Outgoing Header     
>           |

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jul 2009 12:07:09 +0100

David,

We're getting somewhere (if we set aside (a) for now).

I'll first try to reverse engineer how the way we think differs...
- You seem to be thinking of different ECN tunnel behaviours for 
different types of tunnel (IPsec, non-IPsec, PCN, non-PCN etc).
- My goal with this draft is to find a lowest common denominator ECN 
tunnel behaviour for all types of tunnel (IPsec, non-IPsec, 3-level, 
2-level, ECN not supported, whatever).

This separation is important in both directions:
- all nodes should be able to expect the ECN field to behave in the 
same way whether or not tunnels intervene without their control
- all tunnels should be able to process the ECN field in the same 
way, whatever ECN is being used for, because tunnels get deployed 
independently of congestion control schemes like ECN & PCN.

However, at encap I've had to accept that just one mode is 
impossible, as we still need the two RFC3168 behaviours for safety 
with legacy egresses.

now inline...

>         the inner and outer header values don't match.

Well, it's not that they don't match, it's that the combination isn't 
expected to arise - it's currently unused. But I know what you meant.

>         for PCN, it is appropriate to raise alarms for c) and d).

I think what you mean is: if PCN weren't being used, it would be _as_ 
appropriate to raise an alarm for b) as it is for c) & d).

>what's the current use for the c) and d) alarms? ... it's PCN.

Because I'm trying to find the lowest common denominator, I say raise 
alarms for c) & d) whether using PCN or not.

Then the question is, "Should we alarm on b) if PCN is _not_ being used?"

Is this what we really disagree on? If so, we could say:
"MAY alarm on c) & d). MAY also alarm on b) if certain that no 
3-level scheme is being used through the tunnel, but NOT RECOMMENDED 
due to the extra complexity of finding out whether a 3-level scheme is in use."

Does this help? Or have I still mis-estimated where you're coming from?

Bob

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 08:53:57 -0400

Bob,

> 2-level, ECN not supported, whatever).

We're actually aligned on this - I agree with you that the latter is
the goal.  However, we disagree on what the lowest common denominator
is ...

[... snip ...]

> alarms for c) & d) whether using PCN or not.

If PCN is not in use, alarms on c) and d) are not needed, IMHO
(e.g., cf. RFC 3168).

I believe no alarms on c) and d) is the lowest common denominator.
What this means is that the baseline (lowest common denominator)
alarms only when a not-ECT Inner packet comes through with an ECN
codepoint in Outer header.

I'd state that the baseline is no alarms added, and then PCN-specific
text can then explain why for PCN:
- c) and d) are alarming, but
- b) is expected behavior.

> Is this what we really disagree on?

No - IMHO, we should not alarm on b), c) or d) unless something
like PCN is being used.

Thanks,
--David

> Sent: Monday, July 13, 2009 7:07 AM
> To: Black, David
> Cc: [email-masked]

[... snip ...]

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jul 2009 18:30:08 +0100

David,

Optional alarms c) & d) have no more effect on PCN than on anything 
else, and they have no more impact on anything else whether or not 
PCN is there. They have absolutely nothing to do with PCN.

>         RFC 3168/4301: ECT(1), Change: ECT(1)(!!!)

In RFC3168, if you get this combination, something along the tunnel 
has changed ECT(1) to ECT(0). That implies something weird has 
happened - not necessarily dangerous but, as no known or envisaged 
protocols do this, it could turn into something dangerous if the 
tunnel operator doesn't find out what's going on  - which needs an 
(optional) alarm to trigger some action.

>         RFC 3168/4301: CE, Change: CE(!!!)

Again, RFC3168 full functionality mode says if the inner is CE, set 
the outer to ECT(0). So ECT(1) in the outer implies a similar 
weirdness has happened as above. So ditto: MAY alarm.

Just because RFC3168 didn't say "MAY alarm" in these cases, doesn't 
mean it shouldn't have. I'm suggesting these were missed, that's all.

Bob

---

From: <[email-masked]>
Date: Tue, 14 Jul 2009 23:18:59 -0400

Bob,

> PCN is there. They have absolutely nothing to do with PCN.

I think you've missed the point; in isolation, the above statement
is correct, ... BUT ... the triple of <no b) alarm, c) alarm,
d) alarm> is PCN-specific, AFAICT ...

> (optional) alarm to trigger some action.

The problem with this reasoning is that wrt RFC3168, b) is the same
class of weirdness - ECT(0) has changed to ECT(1), yet no (optional)
alarm is proposed.  Keep in mind that ECT(0) and ECT (1) are *not*
ordered values in RFC3168 - they're unordered code points.  The
only escape I see is from this is that PCN is the "known or
envisaged" protocol that uses b) - is there something I've missed?

The d) discussion has the same issue, hence it's snipped.

[... snip ...]

> mean it shouldn't have. I'm suggesting these were missed, that's all.

And had RFC 3168 done that, it would also have suggested an optional
alarm for b).  If an optional alarm for b) is not wanted, the result
is PCN-specific and belongs in an Appendix, IMHO.  The result
enhances flexibility for future usage:
- Main body says that some unexpected changes within the tunnel MAY
	generate optional alarms, but expected ECN transitions (per
	RFC3168) SHOULD NOT generate alarms.
- Appendix discussing PCN as an example says that *if* ECT(0) and
	ECT(1) are ordered (true for PCN, false for RFC3168), *then*
	b) is expected behavior, but c) and d) deserve optional alarms.

Thanks,
--David

> Sent: Monday, July 13, 2009 1:30 PM
> To: Black, David
> Cc: [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 Jul 2009 11:01:16 +0100

David,

At least we now understand each other's position.
We agree a set of alarms on all of b)c)d) would not be PCN-specific.
And when looked at as a whole, missing out an alarm on b) but keeping 
alarms c)d) would be PCN-specific (or 2-severity-level-specific to be precise).

But when looking at each case on its individual merits, an optional 
alarm on c) or d) makes sense to pick up unexpected behaviours, 
whether or not b) is alarmed.

I am happy to say that all three of b)c)&d) SHOULD be logged and MAY 
be alarmed, then when I say that logging & alarms will need to be 
turned off if new standards actions use a combination, I can give PCN 
as an example where b) alarms should be turned off.

As PCN is on the standards track, this mention of an exception for 
PCN ought to be in the body, not an appendix, IMO.

Acceptable?

__________
I have also decided to remove completely the alarm states '(!!!)' 
from my table recapping RFC3168 & RFC4301. Originally, I found the 
mention of logging in RFC3168, but on a re-read I shouldn't have been 
so certain of what it meant, as the text is rather vague. Also I've 
found there's actually no mention of alarms in RFC4301. So all we 
have is this sentence in RFC3168:

"9.2.2.  Changes to the ECN Field within an IPsec Tunnel.

    If the ECN Field is changed inappropriately within an IPsec tunnel,
    and this change is detected at the tunnel egress, then the receipt of
    a packet not satisfying the appropriate condition for its SA is an
    auditable event. [...]"

It doesn't actually enumerate the "inappropriate" cases, so an 
operator could construe this as already blessing alarms on b)c)d), at 
least in the IPsec case.

[Sorry for spending a couple of days before responding...]

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 Jul 2009 12:48:04 +0100

David,

I wanted to move on from optional alarms to my proposed functional 
changes, ie. your case a).

But I have to admit a big error which makes that moot. In 
ecn-tunnel-02 I incorrectly reported what RFC3168 & RFC4301 said (I 
just re-read them). See the table below.

IP in IP Decapsulation; Recap of Pre-existing Behaviour
+------------------+----------------------------------------------+
|  Incoming Inner  |             Incoming Outer Header            |
|      Header      +---------+------------+------------+----------+
|                  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
+------------------+---------+------------+------------+----------+
|     Not-ECT      | Not-ECT | drop       | drop       | drop     |<my error
|     Not-ECT      | Not-ECT | Not-ECT    | Not-ECT    | drop     |<-3168
|     Not-ECT      | Not-ECT | Not-ECT    | Not-ECT    | Not-ECT  |<-4301
|      ECT(0)      |  ECT(0) | ECT(0)     | ECT(0)     |   CE     |
|      ECT(1)      |  ECT(1) | ECT(1)     | ECT(1)     |   CE     |
|        CE        |      CE |     CE     |     CE     |   CE     |
+------------------+---------+------------+------------+----------+
                    |                Outgoing Header               |
                    +----------------------------------------------+

RFC4301 seems to say: If the inner is Not-ECT, anything else in the 
outer must be an error. But whereas RFC3168 dropped the packet if 
there was CE in the outer, RFC4301 says forward it as Not-ECT in all cases.

RFC4301 gives no justification for this rather important change from 
RFC3168. I've spent the last hour or so trawling the IPsec and tsvwg 
archives and can't find any discussion on this point either. Was it 
discussed anywhere?

This RFC4301 behaviour seems unsafe, but perhaps understandable. It 
all depends how the situation arose:
* If the ingress wrongly turned a Not-ECT inner into an ECT outer, 
then subsequently a congested router marked it CE, then it's unsafe 
to remove CE and forward Not-ECT - drop would have been safer.
* If something broken set CE on the outer even tho there was no 
congestion, it's safe.

Bob

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 17:44:04 -0400

Bob,

> archives and can't find any discussion on this point either. Was it 

Not that I recall.  I believe you're looking at a judgment call for
error case handling.  RFC 4301 was specified with close to the
minimum necessary to get ECN to work across an IPsec tunnel, as
security is an area where the default should be leaving out things
that aren't really necessary.  I believe that handling of this error
case was essentially treated as a "don't care."  Looking at your

> to remove CE and forward Not-ECT - drop would have been safer.

The ingress is rather unlikely to have put ECT in the outer - that
clearly violates both RFC 3168 and RFC 4301, and is a bad idea.
Hence something's almost certainly broken ...

> * If something broken set CE on the outer even tho there was no 

If the packet shows up with Not-ECT in the inner and CE in the
outer, something's definitely broken, even if the breakage is
actually a bad Not-ECT -> ECT transition followed by a correct
downstream ECT->CE transition.  Not attempting to perform a
compensating fix is a reasonable course of action, IMHO ...
but I could also defend the 3168 drop behavior as within
reason, along the lines that you suggest.

Thanks,
--David

> Sent: Monday, July 20, 2009 7:48 AM
> To: Black, David
> Cc: [email-masked]
> Subject: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap
> 
> David,
>

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 17:16:16 -0400

Bob,

Sorry for the delayed response.

> alarms c)d) would be PCN-specific (or 2-severity-level-specific to be
precise).

Yes, that captures the important point of agreement on alarms.

> PCN ought to be in the body, not an appendix, IMO.

Yes, including discussion of PCN in the body.  My primary concern is
that the general framework not be specific to PCN-like requirements,
and this approach satisfies that concern.

Thanks,
--David

> Sent: Monday, July 20, 2009 6:01 AM
> To: Black, David
> Cc: [email-masked]
> alarms c)d) would be PCN-specific (or 
> 2-severity-level-specific to be precise).
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jul 2009 09:49:29 +0100

David,

Thanks for the insight into the likely reasoning.

 From a transport perspective, I think now is the right time to say 
safety needs greater attention...
- there's a desire to change 4301 decap anyway to support 2 severity levels,
- safety's become more important since 4301 - greater chance of errors...

Guys I've talked to in the pseudowire area are considering using ECN 
for middlebox to middlebox congestion control (a bit like PCN). 
Pseudowires (or PCN) might or might not also require IPsec. But it's 
quite an art to turn on ECN across a tunnelled segment and do no harm 
in both the following cases:
- if e2e ECN is on, avoiding polluting e2e ECN signals
- if e2e ECN is off, avoiding turning it on
(see recent PCN list).

This all means the chances that an error will occur increases, either 
in broken implementations or broken deployments.

The new rules in ecn-tunnel are designed so that tunnels should "just 
work" and "safely", even if they are deployed by someone who doesn't 
know they have to cater for an in-path internal ECN loop as well.

Q. What do you think of extending drop to both CE and ECT(1) outer if 
there's a Not-ECT inner (see table)?
Reasoning: As these are both currently error conditions and likely to 
remain so, rather than two different safety rules for different 
circumstances just make tunnels safe in all potential cases. 
Otherwise someone has to remember to configure a different safety 
rule on all their tunnels when PCN or pseudowires get deployed in 
their network.

+----------------+----------------------------------------------+
| Incoming Inner |             Incoming Outer Header            |
|     Header     +---------+------------+------------+----------+
|                | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
+----------------+---------+------------+------------+----------+
|    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    | drop     |<-3168
|    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    |Not-ECT   |<-4301
|    Not-ECT     | Not-ECT | Not-ECT    | drop       | drop     |<-ecn-tun
+----------------+---------+------------+------------+----------+
                  |                Outgoing Header               |
                  +----------------------------------------------+

Bob

At 22:44 23/07/2009, [email-masked] wrote:
> >+----------------+----------------------------------------------+
> >+----------------+---------+------------+------------+----------+
> >|    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    |Not-ECT   |<-4301
> >+----------------+---------+------------+------------+----------+
> >                 |                Outgoing Header               |

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jul 2009 23:41:23 +0100

David,

>and this approach satisfies that concern.

Good.

Here's my logic for why I concede you could be right in this case:

If poss we want a generic ECN behaviour for all tunnels that will 
"just work" whether for ECN, PCN, IPsec, VPN, Mobile IP, VCP, xyz, 
whatever. Then no-one has to go round re-configuring all the tunnels 
when someone else independently deploys new feature xyz. And no-one 
has to config each new tunnel they install depending on whether there 
is also xyz in the network.

A different alarm config for decapsulators if they are within a PCN 
domain seems at odds with this goal.

But alarms are there for safety. If an operator wants safety, they 
*might* want to alarm *all* the unsafe cases. If they don't want to 
support VCP or PCN, then codepoints used by VCP or PCN are unsafe in 
their view. But this is still OK - it doesn't stop VCP or PCN being 
deployed by someone independently - they will still work, even if 
bells go off all over the place at first.

Independent deployability is the important property that we need to 
provide in a generic internetwork layer.

For instance a network operator might want to deploy VCP or PCN over 
a network they lease from a wholesaler. They don't want to have to 
depend on the wholesaler blessing what they do.

I will stick out a lot longer if anyone wants unnecessarily different 
ECN _behaviours_ in different types of tunnel.

Bob

---

From: <[email-masked]>
Date: Sun, 26 Jul 2009 09:28:52 -0400

Bob,

I think you may have gone back into the PCN-like behavior swamp
by proposing to distinguish ECT(0) from ECT(1).

Alternatively, are you arguing that this distinction is
necessary in tandem with change b):
  [ECT(0) inner + ECT(1) outer -> ECT(1) in resulting header]
in order to make 3 ECN codepoints really usable?

Thanks,
--David

> Sent: Friday, July 24, 2009 4:49 AM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap
> 
> David,
> 
> > > >> > > > >need strong motivation.  So, here are the four 
> changes, and
> > > >> > > > my thoughts:
> > > >> > > > >
> > > >> > > > >         Rationale: Treat ECT(1) as more severe 
> congestion
> > > >> > > > than ECT(0).
> > > >> > > > >                 odds with your "future 
> standards action"
> > > >> > > > explanation for
> > > >> > > > admits admission control & termination aren't 
> very precise in
> > > >> > > > all cases)
> > > >> > > >
> > > >> > > > ___
> > > >> > > > See part 2/2 for responses to your comments on 
> specific parts
> > > >> > > > of the test.
> > > >> > > >

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Jul 2009 00:28:13 +0100

David,

The whole point of doing this is because we want to support PCN-like 
behaviour in combinations of codepoints that weren't otherwise used. 
So we are proposing to change the ECN behaviour for combinations that 
aren't otherwise used, so PCN can use them.

We've worked out a single ECN tunnel behaviour that's good for IPsec, 
mobile IP, VPNs, PCN, any 2-severity level ECN scheme, any 1-severity 
level ECN scheme, with a nonce or without a nonce.

This is an update to RFC3168 & RFC4301 tunnels that a network 
operator can require compliance with if it wants to support 
2-severity level ECN (like PCN).

It's backwards compatible, so any other tunnel can be updated to this 
(or not), and the previous ECN behaviour will still work as before.

Tunnels get deployed in domains independently of congestion signalling schemes.
So we don't want different tunnels for different purposes.
One tunnel behaviour for all purposes. Please.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Jul 2009 00:35:59 +0100

David,

offlist

>in order to make 3 ECN codepoints really usable?

Of course. All the MUSTs in any draft should be read as a set of 
mutually supporting changes.

Bob