[MMUSIC] pause/resume in draft-ietf-mmusic-sdp-simulcast

[Matthew Kaufman <[e-mail]>]

Issue 1 - Shouldn't stream pause/resume be required?

If I'm a SFM and you are sending me multiple simulcast streams and I decide that nobody is watching one of them, it is wasteful of bandwidth and power (CPU) for you to continue sending a stream I don't want. Likewise if I'm a client and you're sending me simulcast streams directly. I believe that for this reason, pause/resume should be mandatory in this draft. All of the below issues rely on having pause/resume messaging for their successful resolution.

Furthermore, I believe that we must require that TMMBR 0 NOT be used for pause of simulcast streams, because of the relevant note in section 5.5 of RFC 7728. (See Issue 3 below)

Issue 2 - What to send in the media (or signaling) layer when bitrate adaptation says there's not enough bandwidth to send?

If I'm a SFM and I'm receiving your three streams that you are sending (ex., 180P, 480P, 720P all with temporal scaling) and you decide that you can't send the 720P any more, how can I tell the difference between "sender ran out of bandwidth" and "sender is broken"? In particular, if I have subscribers to your 720P stream, and you ran out of bandwidth, I need to know ASAP to start forwarding them the 480P stream instead. Thus an indication that you have paused, preferably in the media stream itself, would be useful... and furthermore, it would be nice to know why you've chosen to do that.

This can be (largely) solved by requiring senders to use the PAUSED indication for this case, and calling that out explicitly in section 7.1 (or elsewhere) of the draft (though as a receiver, it would be nice to know the difference between the various reasons a sender might have appeared to me to have unilaterally decided to pause)

Issue 3 - What to send when bitrate adaptation says there's not enough bandwidth to send *and* pause has been requested for a lower bandwidth stream?

If I'm a SFM and I'm receiving your three streams (ex., 180P, 480P, and 720P) and I note that my viewers are only watching your 720P it would save bandwidth and CPU to send you a pause for the 180P and 480P streams. Once I request that of you, and these are paused, what are you allowed to do when bandwidth adaptation determines that there isn't sufficient bandwidth to send the 720P? Can you unilaterally un-pause the 480P stream in order to keep sending video, or are you forced to stop the 720P and hope the SFM guesses properly that it needs to request un-pause of the 480P?

Likewise, what if the lower resolution streams were signaled as initially paused? Can the sender unilaterally un-pause one in order to use it instead of a higher-bandwidth choice?

I believe the answer here lies in RFC 7728, where an RTP sender may due to local considerations choose to resume at any time, however because TMMBR 0 prohibits this, TMMBR 0 must not be used to pause simulcast streams that a remote sender may need to begin using in order to bandwidth-adapt.

This required behavior (unilateral unpause if necessary) should be noted in section 7.1 of the draft.


Matthew Kaufman