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

From: <[email-masked]>
Date: Tue, 3 Nov 2009 12:02:00 -0000

Thanks david

> 
> > Over the last few months, our conversation has been progressing like
> > two guys at each end of a blunt saw. 

It is too painful to speculate how I fit into this analogy.

> 
> My concern is based on the following two points:
> 
> (A) I agree with reasoning of the form "<X> needs to be done for
ECN:CE,
> 	therefore it needs to be done for PCN:CE."  That's has to be
> 	valid, because if it were not, PCN would not have used the CE
> 	codepoint.
> 
> (B) I do not agree with reasoning of the form "<X> needs to be done
> 	for ECN:CE and PCN:CE, therefore it needs to be done for
> PCN:ECT(1)."
> 	As noted above, PCN:ECT(1) is not a directly comparable
> congestion
> 	indication to either ECN:CE or PCN:CE.
> 
> The immediate consequence of this is that we disagree on the treatment
> of Inner:Not-ECT/Outer:ECT(1).  I view the arguments for Drop in this
> case as instances of the (B) reasoning that I do not agree with.
Hence
> I prefer the treatment of this case to be forwarding with Not-ECT
(!!!)
> [exclamation points indicate unusual case that gets logged/alarmed.]
> 
> OTOH, this is splitting hairs over an error case [i.e., (!!!)].  If
I'm
> the only person with this concern, at some point the chairs should
> declare that I'm on the "rough" end of "rough consensus" and that'll
> be that - this issue is not worth the time of the ADs or IESG.

I'll leave the hair splitting to you & bob (presumably using an
extremely sharp saw)

> 
> That issue surrounded what to do when the inner and outer headers
> have different ECT values.  PCN uses Inner:ECT(0)/Outer:ECT(1), but
> has no use for the other case, Inner:ECT(1)/Outer:ECT(0).
> 

> 
> Let me suggest a blunter alternative:
> 
> - Only log/alarm (!!!) by default the transitions away from Not-ECT
> 	in the inner header (first line in Figure 4, 3 right hand
> boxes).
> 	These are just plain wrong, no matter what.
> - Do not alarm any other combinations by default.  That puts a rapid
> 	end to this discussion.

My original concern was about needing to have different configuration of
the alarms depending on the domain (PCN vs not). Not alarming any other
combinations is therefore ok with me.

> - Provide an explanation (in an Appendix?) about what to alarm in a
> 	controlled PCN environment.  The short summary is that because
> 	PCN has to be deployed in a closed/controlled network, it's
> 	reasonable for the operator to know (in some cases) that there
> 	are no RFC 3168 encapsulators, and therefore be confident I
> 	explicitly enabling a considerably more aggressive log/alarm
> 	approach that catches all reduction/removal of congestion
> 	markings by comparison to what's in Figure 4.
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 04 Nov 2009 16:16:35 +0000

David,

Now you've explained it, I understand your disagreement with dropping 
Not-ECT inner; ECT(1) outer. And you have a reasonable point - I 
agree. I'll change the Outgoing header in this case to Not-ECT and 
add reasoning along the lines of the following paragraph (I'll work 
on simplifying it).

============================================================================
A tunnel egress MUST clear an ECT(1) marking back to Not-ECT that 
must have been erroneously added to a Not-ECT packet. Forwarding 
rather than dropping such a packet allows this codepoint combination 
to be used in future standards actions. Bearing in mind this is an 
error case that shouldn't happen, even if forwarding as Not-ECT loses 
a genuine ECT(1) marking it won't be so dangerous, because any 
resulting lack of response to low severty marking (ECT(1)) will 
eventually lead to high severity marking (CE), which will be dropped 
at the tunnel egress.
============================================================================

Next mail I'll deal with the alarms text.

Bob

At 21:24 29/10/2009, [email-masked] wrote:
>Bob and Phil,
>
>I've pulled out just the topics that I think need discussion:
>
> > two guys at each end of a blunt saw. Can we try to reach a conclusion
> > on each of the three 'cuts' below? I shall be posting a rev
> > before Monday.
>
>Let's see if this sharpens the saw.  I apologize for the delays on
>my part - the people who pay my salary expect me to do my day job
>for some strange reason :-).  I will not be in Hiroshima (can't
>justify the travel, sorry).
>
> > 1/
> > >[DB] I'm not comfortable with PCN:ECT(1) being treated like ECN:CE,
> > >as I expect PCN to be setting it earlier than ECN:CE.  If the queue
> > >occupancy is above the desired operating point, PCN:ECT(1) isn't
> > >going to help, because it only stops the situation from getting worse
> >
> > [BB] You may not be aware that PCN has two threshold bit-rates: a
> > lower one when PCN:ECT(1) is triggered meaning 'stop admission' and a
> > higher one when PCN:CE is triggered, which means 'terminate flows'.
>
>I have been aware of that.  PCN:CE causes reduction of traffic load in
>a fashion similar to ECN:CE.  PCN:ECT(1) is a indication of less severe
>congestion that is triggered earlier as congestion increase.  IMHO, it
>therefore does not directly correspond to ECN:CE.
>
> > Anyway, (paraphrasing Phil Eardley) are you uncomfortable about
> > 'treatment' in the sense of tunneling treatment (wire protocol), or
> > is this about PCN marking algo treatment, which ought to move
> > to the PCN list?
>
>The former.  How PCN marks packets is specified in PCN documents, and
>should not be changed here.  I clearly used poor words in leaving you
>and Phil with the impression that I wanted to change PCN - that was
>*never* my intention (sorry).
>
>(A) I agree with reasoning of the form "<X> needs to be done for ECN:CE,
>case as instances of the (B) reasoning that I do not agree with.  Hence
>I prefer the treatment of this case to be forwarding with Not-ECT (!!!)
>OTOH, this is splitting hairs over an error case [i.e., (!!!)].  If I'm
> > 2/
> > >[DB]> >If we are going to bless that PCN usage,...
> > >
> > >[BB]> For Not-ECT inner the draft makes it clear:
> > > >          forward ECT(0) outer; drop ECT(1) outer
> > > >
> > > > The question is, do you agree [to bless that PCN usage]?
>
>Not in that fashion - see above.
>
> > 3/
> > >[DB] > >...we will need to say so clearly and bluntly in the
>ecn-tunnel draft.
> > >
> > >[BB]> Would something like the change below be sufficient? Remember
>this is
> > > > in addition to all the motivation using PCN that's already in
> > > > ecn-tunnel-03. Pls search thru for the string "PCN".
> > > >
> > > > s/ The above logic allows for ECT(0) and ECT(1) to both represent
>the
> > > >     same severity of congestion marking (e.g. "not congestion
>marked").
> > > >     But it also allows future schemes to be defined where ECT(1)
>is a
> > > >     more severe marking than ECT(0).  This approach is discussed
>in
> > > >     Appendix D and in the discussion of the ECN nonce [RFC3540] in
> > > >     Section 9, which in turn refers to Appendix F.
> > > >
> > > > /  The above logic allows for ECT(0) and ECT(1) to both represent
>the
> > > >     same severity of congestion marking (e.g. "not congestion
>marked").
> > > >     But it also allows future schemes to be defined where ECT(1)
>is a
> > > >     more severe marking than ECT(0), in particular enabling the
>simplest
> > > >     possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding].
>This
> > > >     approach is discussed in Appendix D and in the discussion of
>the
> > > >     ECN nonce [RFC3540] in Section 9, which in turn refers to
>Appendix F.
> > > > /
>
>Independent of our other discussions, I think that text change should
>be made, as it clearly states the primary motivation for some of the
>changes, and I see that it's been done in the -04 draft.
>
>We have one more issue, pulling text out of an earlier message:
>
> > FWIW, this decision about whether ECT(1) can be another form of CE
> > will probably also mostly resolve the dangling topic of what
> > transitions may generate alarms.
>
>The log/alarm behavior in Figure 4 of the -04 draft is somewhat
>alarming ;-) ;-).
>
>Clearing ECT(1) to Not-ECT doesn't get logged or raise an alarm,
>but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT
>doesn't.  Before you write a long response, I'm aware that the
>explanations of what does vs. does get the log/alarm treatment
>involve what happens when a new tunnel decapsulator is paired with
>one of the two RFC 3168 encapsulator variants, but the result is
>still strange and possibly of limited value for PCN.
>
>If this is done, I think the current Appendix F can be bit-bucketed,
>and that's probably an improvement.
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Distinguished Engineer
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 04 Nov 2009 17:03:23 +0000

David,

On alarms - our final issue...

We're agreed a Not-ECT inner with anything else in the outer gets 
logged/alarmed.

At 21:24 29/10/2009, [email-masked] wrote:
>doesn't.

Eh? I think somehow you're reading the table wrong, or typing wrong, 
or I'm misunderstanding what you mean by 'clearing'.

Clearing ECT(1) to Not-ECT does raise an alarm in Fig 4. There's no 
case where ECT(1) is cleared to ECT(0). And no case where CE is 
cleared to Not-ECT.

Ug.

>Before you write a long response, I'm aware that the
>one of the two RFC 3168 encapsulator variants,

The reason I added these alarms is actually not to do with pairing 
with 3168. They are just cases that have always been errors, but 3168 
omitted to log/alarm them.

What's the reasoning for removing them? I'm happy to remove the two 
alarms for mixed ECT, just because the case for them is marginal.
But ECT(1) outer with CE inner is an unambiguous error case.

We don't have to alarm any of these, but we ought to have a reason.

>but the result is

True.

Cheers

Bob

---

From: <[email-masked]>
Date: Fri, 6 Nov 2009 15:53:29 -0500

Bob,

> We're agreed a Not-ECT inner with anything else in the outer gets 

Yes, we agree on this baseline.

> or I'm misunderstanding what you mean by 'clearing'.

It's probably the latter.  I meant "clearing" as an action performed
by a node within the tunnel to the outer header, so "clearing ECT(1)
to Not-ECT" by a node within the tunnel results in "Inner:ECT(1),
Outer:Not-ECT" ... which is not alarmed.

> >explanations of what does vs. does not get the log/alarm treatment

And turning this reasoning around, anything that 3168 could cause did
not get error treatment, independent of whether it might be a problem
for PCN.

> alarms for mixed ECT, just because the case for them is marginal.

I think those both need to be removed, as Phil wants one of them
removed, and I want both of them removed if one is removed, leaving
one last case ...

> But ECT(1) outer with CE inner is an unambiguous error case.

I agree that it's an "unambiguous error case" - my concern is whether
it's worth detecting in isolation.
 
> We don't have to alarm any of these, but we ought to have a reason.

I'm trying to figure out "who cares?" (aside from us), i.e., is the
alarm useful by itself?

I come up with two scenarios:
- In an ECN environment, the problem situations of concern are loss
	of congestion indications.  Any change of Not-ECT (inner) to
	something else is the big one; we agree on alarming that.
	Secondarily, clearing of Inner:CE to something else in the
	Outer also drops congestion indications, but 3168 prevents
	default alarms on two of the three cases [Not-ECT and ECT(0)],
	so I'm having difficulty seeing the value in alarms for
	1 of 3 error cases.
- In a PCN environment, any downgrade of either CE or ECT(1) should
	be alarming ;-), as both carry congestion indications.  There
	are 5 downgrade cases (CE -> anything else; ECT(1) -> ECT(0)
	or Not-ECT), of which only 1 will carry an alarm.  Alarming
	1 out of 5 error cases seems even more unproductive by
	comparison to not alarming any of them ... and instead
	writing an appendix that suggests all 5 cased could/should
	be alarmed in a (closed system) PCN environment.

Thanks,
--David

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: Wednesday, November 04, 2009 12:03 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: Sat, 07 Nov 2009 19:22:15 +0000

David,

The saw it is a-bluntening :) ...

> > >but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT

[BB]: OK, now I understand your 'clearing' terminology (something 
happening at intermediate nodes, not at the egress).  I also think I 
now understand the nub of our disagreement. (For brevity below I use 
'danger' to mean 'suppressing congestion indications' and I use 
'alarm' to mean 'log and alarm'.)

1/ You are using alarms to hilite potential danger, whereas I am 
using alarms to hilite any protocol violation, whether dangerous or not.

The troublesome cases are where a combination of headers could 
indicate danger, or it could be the result of legal legacy ingress 
behaviour. This leads to the second nub of disagreement (I know, you 
can't have two nubs ;)

2/ You don't want to raise alarms unless we can raise them 
consistently for all potentially dangerous cases, whereas I want 
alarms in all cases where we can be *sure* there is a protocol violation.

I suggest the following compromise rules in this order:
a) Don't alarm combinations that might be valid
b) Alarm combinations that are potentially dangerous and always invalid
c) Only alarm combinations that are invalid but not dangerous if they 
can be done consistently.

I'll turn these rules into a proposed new Fig 4 at the end.

>I'm trying to figure out "who cares?" (aside from us), i.e., is the

[BB]: We should care, because we are messing with IP itself - the 
neck of the hour-glass. If a header combination is unambiguously 
wrong, it means there's some bit of kit out there that needs to be 
tracked down and shot. Alarms say that to an operator. So we should 
continue trying to reach technical consensus rather than compromising 
through some voting algorithm.

Put another way, given these are all "SHOULD log and MAY alarm," why 
do you  care so much to not mention one or two, when an implementer 
doesn't have to implement them anyway?

>         so I'm having difficulty seeing the value in alarms for

[BB]: It's like saying "Better consistent than safe", whereas safety 
should override consistency. Put another way, it's like saying "Don't 
tell the child not to stroke a doberman unless you have always told 
the child not to stroke alsatians".

>         be alarmed in a (closed system) PCN environment.

[BB]: Losing ECT(1) is less dangerous than losing CE, because 
congestion will rise until CE kicks in. That leaves 3 cases that are 
potentially dangerous (CE -> anything else). 2 of these could be 
valid (CE -> ECT(0) or Not-ECT), so by rule a) they have no alarm.

Even tho Inner:CE; Outer:ECT(1) is invalid, one might think it's 
safe, because the egress will revert it to CE. But it is a sign that 
some crap implementation is (probably) changing CE to ECT(1). It 
might be doing the same to non-tunnelled packets too - potentially 
dangerous. This is both invalid and potentially dangerous, therefore 
by rule b) it gets an alarm.

Finally, the two with an ECT inner and a different ECT outer are not 
potentially dangerous. One might be valid if PCN is being used but 
the other is always invalid. Therefore, by rule c) neither get 
alarmed, because neither is dangerous and they can't be done consistently.

In summary, I propose we have Fig 4 like this:
+---------+------------------------------------------------+
|Incoming |            Incoming Outer Header               |
|   Inner +---------+------------+------------+------------+
|  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)|   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                  |
           +------------------------------------------------+

Grounds for consensus?

If so, I will also modify the last bullet of Section 7 to roughly 
reflect the above abc rules (the alarms part of the design guidelines 
for alternate ECN tunnels).

Bob

---

From: <[email-masked]>
Date: Mon, 16 Nov 2009 10:10:50 -0500

Bob,

> using alarms to hilite any protocol violation, whether 

I would suggest that the latter is more interesting to a network
operator than the former.  OTOH, you actually work for an operator,
so what's BT's view?

> alarms in all cases where we can be *sure* there is a 

My view of 2/ follows from my view of 1/, FWIW.

> c) Only alarm combinations that are invalid but not dangerous
> if they can be done consistently.

This is entirely about what's alarmed by default.

I would modify b), "potentially dangerous" --> "always
potentially dangerous".  We disagree on c) - I would not alarm
(be default) things that aren't dangerous, particularly when a
significant portion of the dangerous things can't be alarmed
under the assumptions made.

Beyond this, we disagree about the approach to alarms for PCN.
Even before we get to the loss of ECT(1) indications, there are
far worse problems that lose CE indications which can't be alarmed
due to non-PCN situations in which RFC 3168 can cause that header
combination at the egress without dropping the indication.

If you want to alarm potential loss of congestion indications
for PCN, I think there will need to be "SHOULD NOT" or "MUST
NOT" language *for PCN* about the RFC 3168 encapsulation behaviors
that can (validly) cause the problematic egress combinations so
that those problematic egress combinations can be alarmed in a
PCN environment.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bob Briscoe
> Sent: Saturday, November 07, 2009 2:22 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> 
> David,
>

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 09:07:49 -0500

> operator than the former.  OTOH, you actually work for an operator,

Brain fault - I meant to suggest that indication of potential danger
is more interesting than a subset of protocol violations.  Coffee
clearly wasn't working :-).

Thanks,
--David

> From: Black, David 
> Sent: Monday, November 16, 2009 10:11 AM
> To: Bob Briscoe
> Cc: [email-masked]; Black, David

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 17 Nov 2009 19:14:30 +0000

David,

In practice, an alarm will indicate what condition caused the alarm. 
Therefore, we don't have to only alarm dangerous cases - we can alarm 
both dangerous and invalid cases, because the two can be 
distinguished by the operator.

I believe all a stds track doc has to do is identify which cases MAY 
be alarmed, then leave it to the implementer or operator to decide 
which alarms are actually armed.

In the draft, how about indicating potential danger by (!!!) and 
invalid by (!).

I could also add that, where the ingress is also known to comply with 
the present spec, an implementer MAY alarm additional combinations 
known to be dangerous or invalid <which I could specify>.

But I'd rather not go there. This enters territory too close to 
tunnel negotiation, which I don't want to imply is necessary or 
recommended. I'd rather not say anything like this in this spec.

more inline...

> > My view of 2/ follows from my view of 1/, FWIW.

[BB]: See opening point - doing both doesn't preclude distinguishing 
between them.

> > potentially dangerous".

[BB]: Fine

>We disagree on c) - I would not alarm

[BB]: It's a MAY anyway. So implementers can choose to agree with you 
or with me, esp. if we tell them which ones are dangerous vs invalid.

> > combination at the egress without dropping the indication.

[BB]: As you yourself said much earlier in this thread, even valid 
looking protocol headers could result from a combination of invalid 
behaviours that happen to have cancelled each other out.

So I decided to only worry about combinations that cannot be anything 
but wrong.

> > that those problematic egress combinations can be alarmed in a

[BB]: We don't need "SHOULD NOT" or "MUST NOT" language. Just 
compliance with this spec is sufficient (because the 3168 behaviours 
that have been updated by this spec are automatically non-compliant 
to this spec).

If you really think it necessary, I could include additional alarms 
for an egress that is part of a tunnel pair where both are known to 
be fully compliant with this spec (not only PCN, but any case that 
needs fully up to date compliance). But personally I think that's an 
unnecessarily esoteric rat hole.
How about just saying:

"The combinations that Table 4 says may trigger alarms are the 
minimum set that are invalid or dangerous whatever earlier RFC the 
tunnel ingress complies with. An implementation MAY allow alarms to 
be configured for additional header combinations known to be invalid 
for the particular configuration of tunnel deployed at run-time."

?

Bob