Re: [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt

[[e-mail]]

Thank you for sending your comments, I have tried to make changes that
incorporate comments from the various area reviews, and expect to shortly
release an ID revision (12) that has these improvements. Details of the
points addressed are below.

Gorry

---

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Major Issues:

No major issues found.

Minor Issues:

Page 3, first paragraph: There are no citations to the claim that
non-congestion-controlled traffic "can form a significant proportion of the
total traffic traversing a link". Sure, video is a major part of Internet
traffic these days, but much Internet video is dynamically adaptive. One or
more citations would be useful.
-GF: Understood, but I want to consult on the most suitable reference.

Section 4: There are so many issues that they should be numbered, so that
they can be referred to individually (from another document, for example).
-GF: Numbered.

Page 11: In my opinion, the second and third requirements on this page
should be "MUST"s rather than "SHOULD"s.
-GF: Changed: A Circuit Breaker MUST be constructed so that it does not
trigger under light or intermittent congestion.
-GF: I did not change: “The default response to a trigger SHOULD disable
all traffic that contributed to congestion.” - I query if it really
important to dictate the “default” MUST?

Page 12, discussion of "In-Band" near the bottom of the page: This
paragraph implies that an in-band control method will always provide
fate-sharing of the control and regular traffic. It may provide
fate-sharing, but that is by no means assured. For example, the network may
be using ECMP, or traffic tunnels for data but not control traffic.
-GF: Added: “This fate-sharing property is weaker when some or all of the
measured traffic is sent using a path that differs from the path taken by
the control traffic (e.g., where traffic follows a different path de to
use of equal-cost multipath routing, traffic engineering, or tunnels for
specific types of traffic). ”

Section 5: I'm not sure why Section 5 is a separate section, and not
integrated into Section 3 as new subsections, which I think would be an
improvement.
-GF: I had contemplated this move, and have no preference. In the new
revision I moved the text to section 3.

Page 13, first paragraph: "presented in figure 2" -> "presented in figures
1 and 2”.
-GF: done.

Page 19, fourth paragraph: This paragraph states that "IP-based traffic is
generally assumed to be congestion-controlled". This is true for TCP-based
traffic, but I would not make such an assumption for all IP-based traffic.
- GF: Rephrased a little, although the present protocol assumption is that
UDP-based traffic needs to provide some form of congestion response, the
reality is that this is not always the case.

Nits:

The abbreviation "CB" is defined early in the document, but is hardly if
ever used thereafter, rather "Circuit Breaker" is almost always spelled
out. It may be useful to actually use the abbreviation.
-GF: done within the normative section, where the term is used a lot.

Page 3, first paragraph, fifth line, "connection" -> "connections".
-GF: done.

Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes
one space to the right.
-GF: Thanks for spotting, done.

Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a
CB MAY combine".
-GF: done.

Page 11, fifth paragraph: "needs to be" -> "MUST"
-GF: done.

Page 12, second paragraph: There are two separate references to Section 8.
One combined reference should be sufficient.
-GF: done.

Page 12, second to last paragraph: "in-Band" should have the "i"
capitalized.
-GF: done.

Page 15, last paragraph: "tranport" -> "transport"
-GF: done.

Page 17, fifth paragraph: "Pseudo Wire" -> "PW"
-GF: done.

Regards,
Andy