[AVTCORE] Alissa Cooper's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-avtcore-rtp-circuit-breakers-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Many thanks for this work. I expect to ballot YES once we discuss and
resolve the issue below.

In Section 4.5, I understand the need to base the re-start of the media
flow on a human user intervention, but I find it puzzling that this is
framed in terms of "restarting the call" rather than "restarting the
flow." The recommendation in Section 8 is that senders MUST treat each
session independently, but ending/restarting "the call" seems to assume
that multiple flows will be treated together.

One situation I'm thinking of is one where my audio and video traffic are
in separate RTP flows and are routed along different paths for whatever
reason. Some network problem is encountered in the video path, triggering
a circuit breaker. The "call" doesn't necessarily need to be terminated
and re-started, because my audio can continue just fine. This is another
case where the application may not want to rely on a human user re-start
(if you leave it up to me whether to re-start my video, I'll certainly
try to re-start it right away). I think the text in this section needs to
be re-phrased to separate the case where a circuit breaker triggering on
a single 3-tuple causes a whole call to end (either because the call
consisted of a single flow or because all of the flows were encountering
congestion and it takes just one circuit breaker to trigger the end of
it) from cases where it causes only that flow to be suspended, and
reference Section 8 to make it clear that the unit of operation for
"ceasing" and "re-starting" is a single flow unless the sender chooses to
group flows.

Furthermore (and this is not a DISCUSS point but I leave it here since it
follows from the points above), the normative recommendation in the first
paragraph here doesn't really follow from the discussion of restarting
the call. The recommendation is not to automatically re-start until
indications are received that congestion has improved, which is different
from waiting until a human user re-starts. I think this would be clearer
if the normative recommendation came first and the human user case was
discussed afterward.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Did the WG discuss BCP status for this rather than PS?

(2) Section 4.3:

   "If such a reduction in
   sending rate resolves the congestion problem, the sender MAY
   gradually increase the rate at which it sends data after a reasonable
   amount of time has passed, provided it takes care not to cause the
   problem to recur ("reasonable" is intentionally not defined here)."

In later sections you explain that thresholds are not specified because
they are application-dependent. I think that would be useful to note here
too as the reason for not defining "reasonable," assuming that is the
reason.