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

[Bo Burman <[e-mail]>]

Hi Matthew,

Long overdue and with apologies for not realizing this was unanswered and
therefore not responding earlier, please see my comments inline below

/Bo

(as individual)

 

From: mmusic <[e-mail]> On Behalf Of Matthew Kaufman
Sent: den 10 juli 2019 01:09
To: [e-mail]
Subject: [MMUSIC] pause/resume in draft-ietf-mmusic-sdp-simulcast

 

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.

[BoB] This makes a whole lot of sense to me, but I seem to remember that
this was proposed and discussed before during the development of this draft
and was rejected for some reason that I cannot remember or find any record
of right now. I however also don’t think it would be too hard to require
“simulcast and pause” instead of having “pause” implicitly included in a
“simulcast” requirement.

 

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)

[BoB] Fully agree that RFC 5104 TMMBR 0 is a crippled way of pausing that
not only impacts the device sending TMMBR 0 but also impacts other
conference participants by preventing the media sender from making
intelligent choices that would be possible if RFC 7728 PAUSE was used
instead. IMHO, the only motivation for allowing TMMBR 0 as pause is to
provide a “limited pause service” to devices that implements RFC 5104 but
not RFC 7728. That can be feasible in some cases, e.g. if many devices have
TMMBR 0 support but none has PAUSE support, but in many other cases the
downsides with TMMBR 0 outweighs much of the benefits.

 

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)

[BoB] Agree that it makes a lot of sense that a media sender announces a
unilateral pause, be it in a simulcast case or not, using PAUSED or TMMBN 0
(section 5.6 of RFC 7728 <https://tools.ietf.org/html/rfc7728#section-5.6>
). Section 7.1 already says that the sender “can” pause streams that can no
longer be sent, if the media sender has pause capability. You want this
“can” to be a “MUST” (or a “SHOULD”)? At this very late point in the
publication process, I doubt we can do changes that are not essential
corrections or omissions. Do you consider current text broken?

 

Could you also elaborate on why knowing the reason for an unilateral pause
would matter to the SFM? The sender could be limited in bandwidth, in
processing resources, by a broken codec instance, or from something else. I
may be naïve but if 720P stops arriving for some reason and 480P is still
available, isn’t it just a matter for the SFM of accepting the fact and
forwarding what is available?

 

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,

[BoB] Agree.

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. 

[BoB] If the SFM used TMMBR 0 to pause the lower resolution streams, both
the SFM and the media sender would also know that they cannot be
unilaterally resumed. The SFM would likely also get a hint from the media
stream itself that the 720P stream is in trouble; serious bitrate reduction
from the sender and/or sudden increase of packet loss and/or sudden increase
of packet jitter. The SFM should then be capable to realize that it has the
option to either continue receiving this troublesome 720P, or actively pause
the 720P and choose to resume one of the 480P or 180P instead. Also, what
mandates what is negotiated as a 720P to stay as a 720P in case there’s
serious transport trouble? Couldn’t the media sender decide to decrease the
resolution at some point of the bitrate adaptation process? I agree that
some of the transport adaptation considerations ends up in the SFM when
using TMMBR 0, which would otherwise and probably better (using RFC 7728
PAUSE) remain in the media sender, but it doesn’t seem entirely undoable.

 

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

[BoB] While clearly sensible and desirable behavior, I doubt this can be
seen as more than an optimization / clarification, which may not warrant
text changes at this late point in the publication process. As one of the
authors of -simulcast I’m however open to make such clarifications if the
IESG permits and the WG so decides.

 

 

Matthew Kaufman