Subject: [tsvwg] Review of draft-ietf-tsvwg-circuit-breaker-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Apr 2015 16:35:27 +0200

Hi,

I have reviewed draft-ietf-tsvwg-circuit-breaker-01 and have some comments.

1. Section 1.1:

   o  Fast-Trip Circuit Breakers: The relatively short timescale used by
      this form of circuit breaker is intended to protect a flow or
      related group of flows.

   o  Slow-Trip Circuit Breakers: This circuit breaker utilises a longer
      timescale and is designed to protect traffic aggregates.

I reacted to the use of "protect" in these bullets. It is after all the
network that is protected. I wonder if you instead should use "operate
on" or something else that actual makes it clear that the CB types works
with different types of network traffics.

2. Section 3.1:

I saw Caitlin's comment on this draft version. This indicates that the
draft may need to make it clearer that the ingress point may actually be
a endpoint, client or server, not just tunnel ingresses. It depends on
the protocol and its application.

3. Section 3.1:

   2.  An Egress meter (at the receiver or tunnel egress) records the
       number/bytes received in each measurement interval.  This
       measures the supported load and may utilise other signals to
       detect the effect of congestion (e.g., loss/marking experienced
       over the path).

I wonder if you already here need a little more discussion of the
implications of marking rather than dropping packets in congestion
situations. The draft comes back to this later with more detail, but I
wonder if this needs special discussion, maybe even its own introduction
sub-section somewhere.

4. Section 4:
      The minimum time must be
      significantly longer than the time that current CC algorithms need
      to reduce their rate following detection of congestion (i.e.  many
      path RTTs).

I think this might need to be reformulated to talk not of the path RTT,
rather the longest RTT present in any flow part of the measured
aggregate as that is what can limit the speed of CC response for an
aggregate.

5. Section 5.1.1:

   The sender monitors reception of RTCP Reception Report (RR or XRR)
   packets that convey reception quality feedback information.

I think you might have to be slightly more correct in this sentence. I
would suggest:

   The sender monitors reception of RTCP Sender/Reception Report (SR/RR)
   packets that convey reception quality feedback information.

The RTCP XR can be skipped as the only RTCP XR used by the RTP CB is the
ECN report, and that is covered in the next sentence.

6. Section 5.1.1:

  1.  An RTP CB triggers on reported lack of progress.

"lack of progress" is a bit unclear in the context of RTP. I wonder if
you should rather say "on reported failure to receive any RTP packets
(Forward Path Timeout)."

7. Section 5.1.1:

    2.  An RTP CB triggers when no receiver reports messages are
       received.

Is okay, possibly to align with previous bullet add "(Return Path Timeout)"

8. Section 5.1.1:

   3.  An RTP CB uses a TFRC-style check and sets a hard upper limit to
       the long-term RTP throughput (over many RTTs).

If I didn't know what this CB is, I think I would fail to understand it
correctly. Because I think it is important to get across that the upper
throughput limit is recalculated on report interval basis and will be
fluctuating based on input. A possible rewrite could be:

  3. An RTP CB is based on TFRC-style throughput estimation, based on
loss event rate and RTT, and trigger if the RTP stream's usage is a
significantly more (10-times) the estimated rate.

9. Section 5.1.1:

I further wonder if one should include a paragraph to discuss the
scaling of the number of RTCP reporting intervals the CB works on. As
RTCP reporting intervals depends on both configured RTCP bandwidth
values as well as the endpoints view of the number of SSRCs in the
session and their roles (Senders or receivers only) this can vary
significantly from less than 1 ms to many seconds.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Apr 2015 16:41:37 +0200

On 2015-04-01 00:50, Caitlin Bestler wrote:
> Why is this draft "standards track"? This strikes me as
> informational.

It is intended to become an BCP. I think that is appropriate. I see this
as an requirements document with IETF consensus. Or if you will with
fangs. One can't simply ignore it, one have to relate to it due to its
status.

As I see it this document is quite similar to the UDP usage guidelines
that also is a BCP.

> 
> In particular, are they circuit-breaking devices deployed or
> contemplated that the authors feel would be out of compliance should
> this be adopted and would therefore be deprecated (or preferably
> deactivated)?
> 
> My sense from the presentations was that the draft sought to
> standardize terminology and improve our ability to talk about circuit
> breaker functionality, rather than to attempt to prescribe what these
> middle-boxes actually do. (Not  that middle-boxes are all that great
> with compliance to begin with).
> 

The requirements in section 4 is what is actually normative.

I also react to that you write middleboxes. The CB document discusses
all types of CBs. Both tunnel ingress to egress, but also CB being done
between any type of sender and receiver, independent if they are server,
clients, middleboxes, endpoint etc. But this should be clarified as I
commented in my review.

Cheers

Magnus Westerlund

---

From: Matt Mathis <[email-masked]>
Date: Thu, 02 Apr 2015 17:09:12 +0000

For CBR applications, the correct answer to "What mandatory congestion
control are you using?" should be "A circuit breaker".  I believe that this
requires standards track.

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Apr 2015 17:50:44 -0700

On 3/31/2015 3:50 PM, Caitlin Bestler wrote:
> Why is this draft "standards track"? This strikes me as informational.

It's intended as BCP, and that seems to be most appropriate for this
kind of recommendation.

Joe