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

[Alissa Cooper <[e-mail]>]

> On May 2, 2016, at 3:28 PM, Colin Perkins <[e-mail]> wrote:
> 
> Hi,
> 
>> On 2 May 2016, at 22:49, Alissa Cooper <[e-mail]> wrote:
>> 
>> 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).
> 
> It’s fine if the human user tries to restart the media straight-away: if it keeps failing, they’ll eventually give up. The goal is to avoid an automatic restart that never gives up if it keep failing.

Fair enough, although in this particular case it doesn’t seem to make a lot of sense to leave it up to the user.

> 
>> 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.
> 
> Right - if the flows are bundled together, then the circuit breaker applies to the entire bundle. If they’re sent on separate paths, then it applies to each flow individually. If that’s not clear, I agree that we should fix the text to make it so.
> 
>> 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.
> 
> This is in §4.5? I can rephrase, if it’s clearer.

Yes, this is all in 4.5

> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> (1) Did the WG discuss BCP status for this rather than PS?
> 
> Not that I recall. Standards track seems more appropriate to me, but BCP would be fine also.

I could see arguments either way. I asked since draft-ietf-tsvwg-circuit-breaker is approved for BCP.

> 
>> (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.
> 
> Sure.
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>