Subject: [tsvwg] apps directorate review of draft-ietf-tsvwg-circuit-breaker-07

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Oct 2015 19:42:20 +0200

Greetings Gory!

I have been selected (by me) as the Applications Area Directorate
reviewer for this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your WG chairman(s)
before posting a new version of the draft.

Document: draft-ietf-tsvwg-circuit-breaker-07
Title: Network Transport Circuit Breakers
Reviewer: Eliot Lear
Review Date: 21 October 2015
IETF Last Call Date: not yet
IESG Telechat Date: not yet

Summary: Nice draft. Needs a little bit of work still.

Comments:

This draft provides very useful guidance about how circuit breakers
should behave.  There are some aspects that can be expanded, and the
draft highlights a gap in the Internet architecture (see Major Issues),
which perhaps should be noted.  While this review is somewhat long, I
want to stress that most of the issues can be addressed with relatively
small changes.

Major Issues:

High level issue: the document should make clearer just how anomalous
these events are expected to be.  At one point the author states that
this should be treated as an abnormal network event, and elsewhere that
operator intervention will normally be needed to reset a breaker, but
then automated processes are discussed.  Perhaps my confusion could be
solved with some additional text in section 1 near this text:

   These measurements
   need to be taken over a reasonably long period of time. 

Is it worth mentioning what "reasonably long" means at this point? 
Above you talk about RTTs.  There's not a direct comparison in the
introduction, which would be useful.

Another way to put this question: when a circuit breaker trips, does it
indicate that there a network configuration error?

The document makes clear that circuit ingress routers SHOULD log when
the circuit breaker is tripped.  Unfortunately this may not be
sufficient to avoid the principle of least astonishment with regard to
application owners and users.  This can occur in two different ways:
applications are using excessive amounts of bandwidth either because
they are misbehaving or there is more used than planned, or because the
circuit breaker is broken.  In either case, the application may perform
poorly once the circuit breaker is tripped.  The support path between a
slow trip or managed circuit breaker and the application can be quite
long.  It is even conceivable for a fast trip circuit breaker to not be
implemented within an application but outside by the O/S.  One or more
signaling methods to the application would be ideal in these
circumstances, but they have to be trusted.  I do not think this draft
needs to specify a solution here, but it should state the problem.

There is what I would call a very high level discussion about length of
time a circuit breaker is tripped.  Additional detail would be helpful. 
The length of time a circuit breaker is active will have some bearing. 
A very short lived circuit breaker would be very hard for a network
administrator or system administrator to detect.  A long lived circuit
breaker might live well after its usefulness.  And so there is a
tradeoff involving excessive policing and the principle of least
astonishment, and an elaboration about this would be useful.

As a security consideration, is it possible for some circuit breakers to
be triggered intentionally by attackers, thus harming certain traffic?

Section 3.1:

It seems to me that there is additional text needed in Step 5 relating
to the trigger function as to when to terminate the circuit breaker,
even if it's manual.

Minor Issues:

Question about the following text in Section 1:

>    The goal is usually to limit the
>    maximum transmission rate to a rate that reflects the available
>    capacity across a network path.

Does fairness come into play here?  The idea of the "gentleman's
agreement" is that circuit breakers not be needed when people are
backing off in a way that is generally agreed to be fair.

>    This includes traffic sent using a network tunnel.
>    Designers of other protocols and tunnel encapsulations also ought to
>    consider the use of these techniques to provide last resort to
>    protect traffic that shares the network path being used.

This sentence isn't terribly clear, and doesn't seem grammatically
correct.  A last resort to protect against what?  And what precisely is
being protected?  I ask because some confusion sets in around this
point.  Are we protecting the rest of the network from
non-congestion-controlled traffic?  Are we protecting that the
non-congestion-controlled traffic itself?  I think it's the former, but
this makes it sound like the latter.

Nits:

Section 3.1:

>    6.  A reaction that is applied that the Ingress when the Circuit
>        Breaker is triggered. 
s/applied that/applied at/

Eliot