Subject: [tsvwg] draft-ietf-tsvwg-circuit-breaker-05 - flows and microflows

From: "Black, David" <[email-masked]>
Date: Wed, 4 Nov 2015 23:47:10 +0000

Bob,

On the first major issue:

> >> *1. Circuit-breaking of real-time traffic without regard to microflows
> >> considered (very) harmful**

That sounds like a pointed restatement of the general principle that a
circuit breaker is a last-resort mechanism to prevent more severe damage
(which, coincidentally, is a reasonable characterization of what an
electrical circuit breaker does), and needs to be configured and operated
accordingly.

> >> *
> >> 1a. The main problem: the transport area sends out totally the wrong
> >> message if it offers a network circuit-breaker as its apparent
> >> recommended remedy for persistent congestion. The IETF transport area
> >> has developed a wide range of remedies to this problem over the years,
> >> and one of them will nearly always be better than a circuit breaker,
> >> where the phrase "nearly always" leaves an extremely small exception
> >> space.
> >
> > Your last part is rather generic. Can you be more precise in what you
> > see the remedies are?
> That was in the following part of the original email, ie. PCN flow
> termination, congestion policing, the advice in draft-ietf-pals-congcons
> (re-pasted below for your convenience)

All of which are fine when possible and should be done to avoid creating
conditions in which circuit breaking is appropriate.  However the nature
of flows varies depending on where one is located in the network and what's
visible; the protocol and network operator dealing with the aggregate may
lack visibility above some level in the protocol stack.

As an example, consider RFC 7510 on MPLS/UDP.  This UDP encapsulation does
not participate in MPLS label distribution, hence cannot see flows within
the carried MPLS aggregate, and really should not be making guesses about
what labels might mean.

I concur with Gorry that this suggested sentence is problematic, although
the underlying goal is worthy:

> ***The idea of cutting down unresponsive traffic from a tunnel without
> regard to microflows will rarely if ever be appropriate.***

I would prefer text that characterizes this as a last resort to prevent
more serious damage and strongly recommends use of any/all other available
mechanisms to avoid this situation.

> >
> On 02/11/15 01:27, Bob Briscoe wrote:
> > I've realised that this is verging on vandalism: promotion of
> > vandalism of customer traffic, and vandalism of all the hard work of
> > dozens/hundreds of people over the years to address these problems in
> > a more considered way.
> >
> >   * That work started with pre-congestion notification (PCN) for
> > unresponsive flows, keeping per-flow operations to the edge of a
> > network. That included flow admission control and flow termination.
> >
> >   * We then developed the congestion policer to work at an aggregate
> > level, dealing with a mix of unresponsive and responsive traffic in
> > whole networks, or in tunnels or at single bottlenecks. It was
> > designed to cause the least disruption to each of the flows, when it
> > is impractical to police each flow separately. A congestion policer
> > deals effectively with persistent congestion, whether caused by
> > unresponsive flows, or an excess of responsive flow arrivals, or both.
> > As congestion rises, i) initially it gives responsive flows more drop
> > signals, while only removing a small fraction of unresponsive traffic,
> > so the latter should still be able to continue; ii) if congestion
> > persists, it removes larger and larger fractions of the aggregate,
> > irrespective of whether flows are responsive or unresponsive. iii) It
> > can be complemented by well-known techniques from the 1990s to
> > randomly identify heavy flows to give a compromise between per-flow
> > and aggregate processing.
> >
> >   * The draft cites the work of Yaakov Stein, David Black and myself
> > <draft-ietf-pals-congcons>, which the authors and WG have finally
> > reached consensus on (after years). Your draft is correct that it
> > proves that typical pseudowires for TDM traffic will become useless in
> > themselves before they consume more capacity than responsive traffic.
> > And the draft refers to this circuit-breaker as a possible solution.
> > But that depends how you define circuit-breaker:
> >    - If it indiscriminately removes packets from the pseudowire
> > aggregate, it is /not/ the best solution at all.
> >    - The best solution is briefly described in the pals draft
> > (briefly, 'cos remedies were out of scope): removal of inactive voice
> > channels, and admission control of individual flows from the
> > pseudowire. Failing that, the PW should remove random individual flows
> > until congestion is reduced sufficiently.

Which may or may not be possible, based on the nature of the PW and whether
the operator who has provisioned the PW has control over the flows that use
it.  As the draft says:

   Nonetheless, under
   certain conditions it may be possible to reduce the bandwidth
   consumption of an emulated TDM service.

"certain conditions" != "all conditions"

> >    - Indiscriminate removal of packets is only appropriate, if the
> > network cannot see the microflows (e.g. due to encryption at the
> > aggregate level).

I concur that indiscriminate removal of packets is not appropriate
for TDM pseudowires.  What is anticipated in that draft is a managed
circuit breaker that may shut down the TDM PW (probably a human-in-the-loop
decision), not one that somehow automatically decides to forward
only some of the packets.

> > If circuit-breaking is defined as per-aggregate not per-microflow,
> > then this draft should not recommend circuit-breaking. It should
> > recommend flow admission control and flow termination, not
> > circuit-breaking.
> >
> > Cutting off any indiscriminate proportion of the packets without
> > regard to microflows is equivalent to cutting off every microflow
> > within the  pseudowire, because real-time flows typically cannot
> > survive with loss levels above a few %. Cutting off the whole
> > pseudowire in this way is vandalism, and only appropriate if the
> > operator is a lazy good-for-nothing outfit that doesn't deserve any
> > customers.

Thanks,
--David

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 5 Nov 2015 02:11:18 +0000

David,

Yes, I was pointing out that the CB draft is missing all this 
applicability material, which might all be context in your head and 
Gorry's head, and perhaps in the heads of those people citing the CB 
draft. But I realised it's not in the draft.

There is also one material difference between us in how the 
applicability of the draft should be described, I think: I've realised 
that CB of an aggregate ought not to be thought of as a "last resort", 
because specific ones of these other better schemes are sufficient last 
resorts.

CB of an aggregateis only the last resort if two other factors are true:
* when the CB operator is certain that all flows are unresponsive
* when microflows are inaccessible

These ought to be in an applicability statement in the abstract, and in 
the introduction, or near the start.

HTH

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/