Skip to main content

Last Call Review of draft-ietf-avtcore-rtp-circuit-breakers-13
review-ietf-avtcore-rtp-circuit-breakers-13-opsdir-lc-bradner-2016-03-15-00

Request Review of draft-ietf-avtcore-rtp-circuit-breakers
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-03-09
Requested 2016-02-27
Authors Colin Perkins , Varun Singh
I-D last updated 2016-03-15
Completed reviews Genart Early review of -11 by Meral Shirazipour (diff)
Genart Last Call review of -13 by Meral Shirazipour (diff)
Genart Last Call review of -14 by Meral Shirazipour (diff)
Secdir Last Call review of -13 by Magnus Nyström (diff)
Opsdir Last Call review of -13 by Scott O. Bradner (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-ietf-avtcore-rtp-circuit-breakers by Ops Directorate Assigned
Reviewed revision 13 (document currently at 18)
Result Has issues
Completed 2016-03-15
review-ietf-avtcore-rtp-circuit-breakers-13-opsdir-lc-bradner-2016-03-15-00
I did an ops-dir review of draft-ietf-avtcore-rtp-circuit-breakers-13.

I find this to be a very well written and informative document - in places it is almost a tutorial 
on how RTCP is supposed to work - a good thing to have in a RFC imo

The general idea of triggering a shutdown of a stream from a streaming source when traffic 
from that source is negatively impacting the network or when the data, as received by the 
destination, is not useful for the intended purpose is a good thing when looked at though the 
eyes of a network operator - anything that selectively removes useless or marginally useful
traffic from a congested network makes the operator's job easier - particularly if the 
operator does not have to be involved.

I do wonder though about the user experience - sessions just stop with no notice.  

I wonder if there would be some way that a client could figure out that the session 
was wandering into circuit breaker territory so if the session stopped the client might 
be able to provide the user with some feedback - the lack of feedback might cause 
some users to assume the network operator is at fault and cause them to contact
the operator - which would cause a negative impact on the operator

At first blush it would seem that the client could figure things out in at least some cases.

Maybe this is already being worked on in the WG and I do not know about 
it but if not it would seem like something to explore 

Scott