Network Transport Circuit Breakers
draft-ietf-tsvwg-circuit-breaker-15

Received changes through RFC Editor sync (created alias RFC 8084, changed abstract to 'This document explains what is meant by the term "network transport Circuit Breaker".  It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.  It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.', changed pages to 24, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2017-03-07, changed IESG state to RFC Published, created alias BCP 208)

[Ballot comment]
= Substantive: =

- General:

-- [I moved the following here from my original DISCUSS position. I've cleared the DISCUSS, since "discussion" has started and looks promising.]  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.

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

[Ballot comment]

- I agree with Ben's discuss.

- Do the MPLS folks and similar agree with 6.1? If so, great.
(And how did you figure that out?) If not, doesn't that make a
big part of this BCP mythical?  (Which would seem
undesirable.)

- 6.2, 2nd para: what question?

- Section 7 (and earlier): You RECOMMEND a crypto mechanism to
mitigate possible DoS. In both cases however, the statement is
ambiguous. Are you RECOMMENDing a mechanism be defined or that
one be used? (And of course if you asked me, I'd say that it'd
be better to a crypto mechanism MUST be used, even when
off-path attacks seem unlikely to work.)

[Ballot comment]
Agree with Ben's Discuss point. Also Requirement 18 says for in-band "SHOULD" and "ought to" vs. Requirement 1's "MUST". Would prefer Requirement 1 be clarified by combining with Requirement 18. Prefer 18's requirement that an out-of-band control channel failure does not trigger the CB and disrupting traffic. May want to consider adding the ability to configure if a loss of the control channel should trigger the CB. Other technologies consider the loss of control protocol as a freeze on the bridge selector state. Also may want to consider adding the ability to configure a freeze of the CB for maintenance/operations.

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

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

[Ballot discuss]
This is a "let's talk about it" DISCUSS (i.e., may not require any document changes) to make sure I understand what is being recommended...

1. Rules 12 and 13 in section 4 seem more pertinent to sender-based flows than to tunnels. Is it best current practice to terminate all tunnel traffic in the face of long-term congestion rather than attempt to terminate/regulate the worst offenders within the tunnel? If the circuit breaker capability is implemented within the tunnel ingress point (as is recommended), it would seem straightforward to penalize the flow(s) causing the congestion rather than all the flows. Or am I misinterpreting the rules 12 and 13?

2. Does the need for these types of circuit breakers imply that raw UDP (and UDP-Lite) is no longer sufficiently functional and that DCCP (or an equivalent) needs to be used?

3. If this BCP is expecting to influence the implementation of traffic sources and sinks, should there be some guidance on what should be used (e.g., ECN) prior to invoking circuit breaker logic? The text says numerous times that CBs are a last resort, but I don't see much in the way of what should be used prior to this last resort.

[Ballot comment]
linda.dunbar@huawei.com

performed the opsdir review

  Simple protection can be provided by using a randomized source port,
  or equivalent field in the packet header (such as the RTP SSRC value
  and the RTP sequence number) expected not to be known to an off-path
  attacker.  Stronger protection can be achieved using a secure
  authentication protocol.  This attack is relatively easy for an on-
  path attacker when the messages are neither encrypted nor
  authenticated.  When there is a risk of on-path attack, a
  cryptographic authentication mechanism for all control/measurement
  messages is RECOMMENDED to mitigate this concern.

By on-path attacker we mean service provider.

As with for example HLS (which is congestion controlled), and which ISPs particularly wireless carriers then deliberately degrade; Providing a protocol with a well understood mechanism for shutting it down can be used to do so maliciously without imposing a strict firewall policy. that's convenient for plausible deniability.  I wonder if the technical response from implementors isn't to wrap the flow in something harder to inspect.

The discussion of a multicast circuit breaker seems largely anchored in SSM with respect to there being one (reliable) sender. In the ASM case it seems trivial for a malicious sender to cause all the other parties to leave the group by misreporting it's own sending properties (and do so with very few packets).

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-circuit-breaker-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank  you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: david.black@emc.com, tsvwg@ietf.org, spencerdawkins.ietf@gmail.com, draft-ietf-tsvwg-circuit-breaker@ietf.org, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Network Transport Circuit Breakers) to Best Current Practice


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Network Transport Circuit Breakers'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document explains what is meant by the term "network transport
  Circuit Breaker" (CB).  It describes the need for circuit breakers
  for network tunnels and applications when using non-congestion-
  controlled traffic, and explains where circuit breakers are, and are
  not, needed.  It also defines requirements for building a circuit
  breaker and the expected outcomes of using a circuit breaker within
  the Internet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ballot/


No IPR declarations have been submitted directly on this I-D.

Document shepherd write-up:

                  Network Transport Circuit Breakers
                  draft-ietf-tsvwg-circuit-breaker-04

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  This document explains what is meant by the term "network transport
  Circuit Breaker" (CB).  It describes the need for circuit breakers
  when using network tunnels, and other non-congestion controlled
  applications.  It also defines requirements for building a circuit
  breaker and the expected outcomes of using a circuit breaker within
  the Internet.

The WG has requested Best Current Practice status because this draft
provides protocol design (and in some cases, operational) guidelines
for the Internet.  This request is the rough consensus of the WG.

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is strongly supported by the portion of the TSVWG that is
concerned with congestion, and has received reviews and discussions from
several experts within that community.  Overall support for this draft
comes from about a dozen members of the WG, which is relatively broad
support for a TSVWG draft.  Discussion in TSVWG has not been controversial;
the draft has evolved moderately from the initial -00 version that the
WG adopted about a year ago, with no major objections to its content in
WG discussion.

In contrast, the circuit breaker concept has been controversial in other
IETF forums, with strong opposition observed to imposing circuit breaker
support as a protocol design requirement.  The concept of a managed
circuit breaker is intended to allow response via a different control-plane
protocol or via other mechanisms such as OAM and/or network operator
monitoring of service delivery.  The shepherd expects this issue to
resurface at IETF Last Call, and is accordingly dusting off his (virtual)
Kevlar vest.

There is complementary work elsewhere in the IETF, e.g., the RTP circuit
breaker activity in the AVTCORE WG.

3. Intellectual Property

The draft author has stated his direct, personal knowledge that any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79.

4. Other Points

idnits 2.13.02 ran clean on the -04 version.
There are no DOWNREFs or IANA Considerations.

The IESG should take note of the potential controversy surrounding the
circuit breaker concept in general (see Section 2 above).