Subject: [tsvwg] Ben Campbell's Discuss on draft-ietf-tsvwg-circuit-breaker-13: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 19:18:49 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-circuit-breaker-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I expect to ballot "yes" for this, but I have one item that I think needs
discussion first (as well as some non-blocking comments in the comment
section.):

The rule 18 "out of band" section says loss of control messages SHOULD
NOT trigger the CB.  But rule 1 said "The CB MUST trigger if there is a
failure of the
        communication path used for the control messages." These seem to
be contradictory normative requirements.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Substantive: =

- General:

I'm surprised not to see much, if any, commentary about how endpoints are
expected to learn of and react to triggered CBs. Flows that just stop
working for no apparent reason will violate the principle of least
surprise for users. Users are likely to do exactly the wrong things (e.g.
restart flows), unless they are informed of why.

- 1, last paragraph: 

-4, req 10:

What is meant be default here? Does this suggest that an implementation
must disable all traffic unless a user explicitly configures it to behave
differently?

- req 12: "... MUST be much more severe"
How do you measure that sort of requirement? Isn’t this already covered
by 10 and 11 and 13?

- 5.1, last paragraph, last sentence:

Does this imply that circuit breakers can/will be stacked? If so, an
explicit mention of that fact early in the document would be helpful.

- 5.1.1:
Why not reference draft-ietf-avtcore-rtp-circuit-breakers ?
(Informational should be fine.)

= Editorial: =

-1, third paragraph: "Avoiding persistent excessive prevention ..."

Should that be "Avoiding persistent excessive _congestion_ ..."?

-- 5th paragraph, first sentence:

Is there a such thing as “normal excessive congestion?”

-- 8th paragraph: "This is to
   ensure that a Circuit Breaker does not accidentally trigger following
   a single (or even successive) congestion events (congestion events
   trigger transport congestion control, and are to be regarded as
   normal on a network link operating near capacity). "

I’m confused by this sentence. What is the subject of “are to be regarded
as normal”?

-- 10th paragraph, first sentence: Is this the same as saying that
circuit breakers should not trigger under normal conditions?

- 2nd to last paragraph, 2nd sentence:
In contrast to what? Not knowing the cause of congestion? (Are
contestion-controlled protocols expected to know the cause?)

-4, req 3: It would have been helpful to mention ECN (or forward
reference it) prior to the first mention of "lost/marked packets".

-- req 9: Isn’t this the point behind the last 3 (or more) requirements?
That is, it seems like this is the real requirement and those were more
implementation details.

- 5.1, first paragraph, 2nd sentence:
The sentence structure makes it look like you are using (TCP, SCTP, DCCP)
as examples of "applications that do not use a full-fledged transport",
which is  obviously not the intent.

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Mar 2016 00:33:21 +0000

Ben,

On your DISCUSS point, the draft appears to be guilty as charged:

   The rule 18 "out of band" section says loss of control messages SHOULD
   NOT trigger the CB.  But rule 1 said "The CB MUST trigger if there is a
   failure of the communication path used for the control messages."
   These seem to be contradictory normative requirements.

They certainly do appear to be contradictory.

The history (as one might guess) is that requirement 1 significantly predated
requirement 18.  Requirement 18 was added to the -07 draft (last October)
based on list discussion of review comments to the effect that fate sharing
between control and data paths was not a good thing to require.  In particular,
the current "SHOULD NOT" in rule 18 is the result of WG list discussion that
started from a "MUST NOT" version of that rule.  Nobody noticed the
related text in rule 1 at the time or subsequently :-(.

Based on that WG list discussion, I think rule 1 ought to be edited to align
with rule 18.   I'd prefer to delay doing that until after tomorrow's (March 17)
telechat, as I think the WG should have the opportunity to comment on
changing  he "MUST" in rule 1, and I'd prefer to handle any other significant
draft changes arising from the IESG telechat in one email thread.

> restart flows), unless they are informed of why.

No surprise there - a typical first reaction to lights going out when an
electrical breaker trip is to flip them off and back on ;-).   I'd suggest that
protocol design and operational attention would be better invested in
avoiding and recovering from problems before they trip a circuit breaker
that cuts off traffic (and please note that a CB may operate to reduce rate,
not just cut off traffic).  If the circuit breaker is in the middle of the network,
it's hard to communicate back to the endpoints (e.g., witness all the ways
in which ICMP messages can fail to be delivered).

We’ll address the rest of the comments in the next revision - thanks for
the careful review.

Thanks, --David

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, March 14, 2016 10:19 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; Black, David;
> [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-tsvwg-circuit-breaker-13: (with
> DISCUSS and COMMENT)
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 16 Mar 2016 23:23:05 -0500

> draft changes arising from the IESG telechat in one email thread.

That's fine, and since "discussion" is happening, I'll clear the 
DISCUSS.

> in which ICMP messages can fail to be delivered).

I agree that work would be better spent on keeping the CB from firing in 
the first place. Perhaps some text pointing out the potential bad 
behavior of surprised users would help further motivate that :-)

>> Subject: Ben Campbell's Discuss on 
>> draft-ietf-tsvwg-circuit-breaker-13: (with
>> DISCUSS and COMMENT)
>>
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: [email-masked]
Date: Thu, 17 Mar 2016 07:55:56 -0000

Just to confirm my take (as editor)... Sorry. I agree with the analysis
below.

The test in (1) that states MUST needs to be removed:

      "The CB MUST trigger if there is a failure of the
        communication path used for the control messages."

- The original text indeed referred to an in-band method. I believe the
SHOULD expressed later in (18) was thought more appropriate, but I think 
there still needs to be a strong warning for in-band methods to consider
the second part of (1):

      "when it fails to receive measurement
        reports that indicate an absence of congestion, rather than
        relying on the successful transmission of a "congested" signal
        back to the sender.  (The feedback signal could itself be lost
        under congestion)."

- I'm sure we can work out how to provide this guidance, without
contradicting (18).

Gorry