Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02

From: Emil Ivov <[email-masked]>
Date: Fri, 17 Oct 2014 20:46:19 +0200

I went quickly over the draft and have one question.

I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0.

A sender may single-sidedly decide to drop a high quality simulcast or 
an SST-MS SVC layer for congestion control reasons. TMMBN=0 would come 
very handy in that case as it would allow a receiving SFU to quickly 
switch to a lower quality layer.

Wouldn't it be a good idea to cover this?

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Oct 2014 08:17:08 -0700

Yes, in the current draft it seems that TMMBNs are unacknowledged.   That is also true of codec-specificmessages such as SEI Layer Drop, but those are sent in the RTP stream so they have a sequence numberthat makes it clear exactly when the layer in question stopped being sent, and also are therefore subjectto loss indications (such as NACK).  
I suppose that the sender could send multiple TMMBN=0 messages to improve the chances for delivery, but still it represents an imperfect substitute if the intent is for future SST-MS implementations to forgo codec-specific layer drop messages.

---

From: Bo Burman <[email-masked]>
Date: Tue, 21 Oct 2014 14:45:07 +0000

Emil, I assume unsolicited TMMBN 0 is  what you mean with "acknowledging TMMBN", not that the TMMBN (being a type of ACK to TMMBR) in itself needs an ACK?

It seems to me that you, Bernard, instead discuss the possible need for acknowledging TMMBN 0 ("PAUSED"), meaning asking the media receiver's consent before a media sender, without being asked to and based on some local decisions, pauses an RTP stream. Correct? That's a different issue and not currently in the intended scope of the draft. Should it be?

Please note that the draft was already updated as a result of previous discussions on this list since IETF90.
Latest version is now -04: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-04
Diff here (-03 was just missing a copyright boilerplate change): https://www.ietf.org/rfcdiff?url1=draft-ietf-avtext-rtp-stream-pause-02&difftype=--html&submit=Go%21&url2=draft-ietf-avtext-rtp-stream-pause-04

Many of those changes are related to the use of unsolicited TMMBN 0, just as I think Emil suggests below. I think that it was already pretty clear in the draft that the new PAUSED message could be sent unsolicited by the media sender as a result of "local considerations", and that TMMBN 0 could be semantically the same as PAUSED. I however agree that the combination of those was somewhat opaque and have added what I hope to be clarifying text for it in several places.

Assuming that the original question was related to unsolicited TMMBN 0, please review the changes in -04 and see if they meet your needs.

Cheers,
/Bo

From: avtext [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: den 19 oktober 2014 17:17
To: Emil Ivov; DRAGE, Keith Keith; [email-masked]
Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02

Yes, in the current draft it seems that TMMBNs are unacknowledged.   That is also true of codec-specific
messages such as SEI Layer Drop, but those are sent in the RTP stream so they have a sequence number
that makes it clear exactly when the layer in question stopped being sent, and also are therefore subject
to loss indications (such as NACK).

I suppose that the sender could send multiple TMMBN=0 messages to improve the chances for delivery,
but still it represents an imperfect substitute if the intent is for future SST-MS implementations to
forgo codec-specific layer drop messages.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 Oct 2014 22:08:18 +0200

Hey Bo,

On 21.10.14, 16:45, Bo Burman wrote:
> Emil, I assume unsolicited TMMBN 0 is  what you mean with “acknowledging
> TMMBN”,

Yes.

> not that the TMMBN (being a type of ACK to TMMBR) in itself
> needs an ACK?

Correct!

> Many of those changes are related to the use of unsolicited TMMBN 0,
> just as I think Emil suggests below. I think that it was already pretty
> clear in the draft that the new PAUSED message could be sent unsolicited
> by the media sender as a result of "local considerations", and that
> TMMBN 0 could be semantically the same as PAUSED.

Yes, it was indeed, but I think clarifying it was nice, thanks! (still 
not done though).

> I however agree that
> the combination of those was somewhat opaque and have added what I hope
> to be clarifying text for it in several places.
>
> Assuming that the original question was related to unsolicited TMMBN 0,
> please review the changes in -04 and see if they meet your needs.

Unfortunately no. It still says nothing about acknowledging unsolicited 
TMMBNs. There is even the following part you added in there:

    There is no reply to a PAUSED indication; it is simply an explicit	
    indication of the fact that an RTP stream is paused.  This can be	
    helpful for the RTP stream receiver, for example to understand that	
    transmission is deliberately and temporarily suspended and no	
    specific corrective action is needed.

I don't think the part of "no specific action needed" would always be true.

Imagine for example, that at first (time t0) sender "S" is simulcasting 
*two* SSRCs to receiver "R". SSRC 1 is a low res video stream (LQ) and 
SSRC2 is a high res version of the same stream (HQ).

Then, at time t1, due to local conditions, S decides that it no longer 
wishes to stream the HQ layer and stops doing that. S continues to 
stream the LQ layer though. At that point S would send an unsolicited 
TMMBN=0.

Now imagine that R is actually an SFU and that at t0 it was relaying S's 
HQ stream to a number of other receivers. So this SFU (R) needs to learn 
about the layer drop, as quickly as possible, in order to switch to 
relaying S's LQ stream to all the other receivers it was servicing.

This is where the delivery of a TMMBN=0 would be crucial. Without it, R 
(the SFU) would have a hard time distinguishing between loss bursts and 
an actual layer drop.

We are currently experimenting with this and this is a real problem that 
we are often experiencing. We are forced to rely on detecting starvation 
for a specific SSRC and that is either inconveniently slow, or it 
triggers too many false positives.

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Oct 2014 09:29:46 +0300

Hi Emil,
The unsolicited PAUSED or TMMBN=0 are an indication that the sender stopped
sending the stream, I am not sure it needs to be acknowledged, the procedure
is to repeat the message and send it when a new party joins the RTP session.
The sender does not need any respond from the receiver for this indication
Roni

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: 17 October, 2014 9:46 PM
> To: DRAGE, Keith (Keith); [email-masked]
> A sender may single-sidedly decide to drop a high quality simulcast or an
SST-
> MS SVC layer for congestion control reasons. TMMBN=0 would come very
> handy in that case as it would allow a receiving SFU to quickly switch to
a lower
> quality layer.
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Emil Ivov <[email-masked]>
Date: Wed, 22 Oct 2014 19:00:50 +0200

Hey Roni,

On 22.10.14, 08:29, Roni Even wrote:
> sending the stream,

Yes, it is.

> I am not sure it needs to be acknowledged, the procedure

I am not sure I follow you here. The point is that an SFU may want to 
rely on unsolicited PAUSED/TMMBNs in order to switch from one simulcast 
stream to another, or to potentially drop a sender from the SSRCs that 
it is sending to a receiver and replace it with another sender. This 
would be the case in large conferences where only receiver is only 
getting a subset of the participants.

In order to rely on receiving TMMBNs, the SFU would need to know that 
they are reliable though.

So in other words: Yes! The sender does not need a response for its 
indication. It is the receiver that needs to know that it can rely on 
receiving the indication.

Cheers,
Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Oct 2014 11:49:59 +0300

Hi Emil,
I am not sure what is the case you describe.
My view is that an SFU ( I assume it is a conferencing bridge?) may use
TMMBR/PAUSE to stop unused video streams, these are acknowledged messages by
the sender.

Another example is that for some reason a current sender will Pause a stream
(I would think that it will be a stream not used currently) even though it
did not get a TMMBR/PAUSE by learning somehow that the stream is unused.
This will be unsolicited.

If I understand you have another case where a sender will pause, for some
reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED for this
stream. Are you asking for a method by which the SFU will know if the sender
supports TMMBN=0/PAUSED and will always send it when pausing a stream in
use? I am not sure what is Acknowledge by the SFU to the media sender is and
when is it sent, for this case?

Roni 

> From: Emil Ivov [mailto:[email-masked]]
> Sent: 22 October, 2014 8:01 PM
> To: Roni Even; [email-masked]
> > The unsolicited PAUSED or TMMBN=0 are an indication that the sender
> > stopped sending the stream,
> 
> Yes, it is.
> 
> > I am not sure it needs to be acknowledged, the procedure is to repeat
> > the message and send it when a new party joins the RTP session.
> 
> I am not sure I follow you here. The point is that an SFU may want to rely
on
> unsolicited PAUSED/TMMBNs in order to switch from one simulcast stream to
> another, or to potentially drop a sender from the SSRCs that it is sending
to a
> receiver and replace it with another sender. This would be the case in
large
> conferences where only receiver is only getting a subset of the
participants.
> 
> In order to rely on receiving TMMBNs, the SFU would need to know that they
> are reliable though.
> 
indication.
> It is the receiver that needs to know that it can rely on receiving the
indication.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 Oct 2014 12:04:48 +0200

Hey Roni,

Correct!

> This will be unsolicited.

Learning that a stream is unused is not the only reason why a Sender can 
stop streaming something. The sender can also drop a stream because it 
detected congestion.

> when is it sent, for this case?

An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can be lost. 
If that happens the Receiver/SFU would not know that an in-use stream is 
being intentionally dropped. That unsolicited TMMBN=0 would need to be 
retransmitted by the Sender until it is eventually received by the 
Receiver.

That's what I am asking for and that's what I am calling "making it 
reliable".

Is this clearer now?

Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Oct 2014 14:08:28 +0300

Hi Emil,
OK, now I got it. I agree that we need some text addressing reliability of
the unsolicited TMMBN and PAUSED.  I think I got confused by the work
acknowledging and it seems to me that Bo had the same problem. 
But still since RTCP is runs over UDP there is still no guarantee that the
RTCP packet will arrive even if we sent it with every scheduled RTCP packet.

I agree that it will be good to add text about the unreliability of these
indications and propose to repeat them based on implementation decision.

Roni

> Sent: 23 October, 2014 1:05 PM
> > My view is that an SFU ( I assume it is a conferencing bridge?) may
> > use TMMBR/PAUSE to stop unused video streams, these are acknowledged
> > messages by the sender.
> 
> Correct!
> 
> > Another example is that for some reason a current sender will Pause a
> > stream (I would think that it will be a stream not used currently)
> > even though it did not get a TMMBR/PAUSE by learning somehow that the
> stream is unused.
stop
> streaming something. The sender can also drop a stream because it detected
> congestion.
> 
> > If I understand you have another case  where a sender will pause, for
> > some reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED
> > for this stream. Are you asking for a method by which the SFU will
> > know if the sender supports TMMBN=0/PAUSED and will always send it
> > when pausing a stream in use? I am not sure what is Acknowledge by the
> > SFU to the media sender is and when is it sent, for this case?
> 
being
> intentionally dropped. That unsolicited TMMBN=0 would need to be
Receiver.
reliable".
> >>> I am not sure it needs to be acknowledged, the procedure is to
> >>> repeat the message and send it when a new party joins the RTP session.
> >>
> >> rely
> >> unsolicited PAUSED/TMMBNs in order to switch from one simulcast
> >> stream to another, or to potentially drop a sender from the SSRCs
> >> that it is sending
> > to a
> >>>> MS SVC layer for congestion control reasons. TMMBN=0 would come
> >>>> very handy in that case as it would allow a receiving SFU to
> >>>> quickly switch to
> >>> a lower
> >>>> quality layer.
> >>>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 Oct 2014 23:41:07 +0200

Hey Roni,

> indications and propose to repeat them based on implementation decision.

I wonder if we could come up with an easy way to ACK the TMMBN=0 ... how 
about resending the same TMMBN=0 (with the same SSRCs) in the opposite 
direction?

Emil

-- 
https://jitsi.org

---

From: Bo Burman <[email-masked]>
Date: Fri, 24 Oct 2014 15:42:25 +0000

> I wonder if we could come up with an easy way to ACK the TMMBN=0 ... how about resending the same TMMBN=0 (with
> the same SSRCs) in the opposite direction?

Would certainly be possible, but a bit un-orthodox maybe... That TMMBN-ACK, or PAUSED-ACK, could also be lost, right?

I think that the least we should do is to describe (definitely in 4.6 and 8.5, and maybe also in 6.4) that the timing and message re-transmission for any unsolicited PAUSED or TMMBN=0 should be the same as is currently specified for TMMBR>0 (RESUME) in the draft. This, because the importance of an unsolicited TMMBN=0 (PAUSED) can be just as high as for a TMMBR>0 (RESUME).

Have a look at the text for RESUME and see if you think it is appropriate!

I don't know if this is sufficient. The major difference between PAUSED and RESUME is that PAUSED has no implicit ACK through RTP transmission state changes (as RESUME has), and that has to be handled somehow.

Assuming that we agree that unsolicited PAUSED (same for TMMBN=0, of course) must be sent in a way that tries to mitigate loss to the largest extent possible, given existing RTCP bandwidth, I think the question then becomes for how long and how often should PAUSED be repeated until considered received. Could we suggest to use regular RTCP loss reporting to make an estimate on how many times it has to be repeated? For example, if there is 20% loss, it takes 5 repetitions to get down to 0.032% loss probability for the PAUSED (given random loss). The overhead for that is really nothing compared to the media stream itself (that was just paused). Specifying even more repetitions should not be a problem, just being limited by the available RTCP bandwidth and timing!

Do we need a new use case (section 3) and design consideration (section 4) for timing of unsolicited PAUSED? I think that might be appropriate!

> Sent: den 23 oktober 2014 23:41
> > OK, now I got it. I agree that we need some text addressing
> > reliability of the unsolicited TMMBN and PAUSED.  I think I got
> > confused by the work acknowledging and it seems to me that Bo had the same problem.
> > But still since RTCP is runs over UDP there is still no guarantee that
> > the RTCP packet will arrive even if we sent it with every scheduled RTCP packet.
> >
> > I agree that it will be good to add text about the unreliability of
> > these indications and propose to repeat them based on implementation decision.
> 
> I wonder if we could come up with an easy way to ACK the TMMBN=0 ... how about resending the same TMMBN=0 (with
> the same SSRCs) in the opposite direction?
> 
> Emil
> 
> 
> >
> > Roni
> >
> >>> Another example is that for some reason a current sender will Pause
> >>> a stream (I would think that it will be a stream not used currently)
> >> streaming something. The sender can also drop a stream because it
> >> detected congestion.
> >>
> >>> If I understand you have another case  where a sender will pause,
> >>> for some reason, a stream in use by the SFU and may send a
> >>> TMMBN=0/PAUSED for this stream. Are you asking for a method by which
> >>> the SFU will know if the sender supports TMMBN=0/PAUSED and will
> >>> always send it when pausing a stream in use? I am not sure what is
> >>> Acknowledge by the SFU to the media sender is and when is it sent, for this case?
> >>
> >>>>> The unsolicited PAUSED or TMMBN=0 are an indication that the
> >>>>> sender stopped sending the stream,
> >>>>
> >>>> Yes, it is.
> >>>>
> >>>> In order to rely on receiving TMMBNs, the SFU would need to know
> >>>> that they are reliable though.
> >>>>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 26 Oct 2014 01:18:48 +0200

Hey Bo,

On 24.10.14, 17:42, Bo Burman wrote:
>> I wonder if we could come up with an easy way to ACK the TMMBN=0
>> ... how about resending the same TMMBN=0 (with the same SSRCs) in
>> the opposite direction?
>
> Would certainly be possible, but a bit un-orthodox maybe... That
> TMMBN-ACK, or PAUSED-ACK, could also be lost, right?

I am not sure I get the question. If you mean that new ACK message that 
we could add, then yes of course ... and obviously the idea would be to 
resend the TMMBN=0 until the ACK is received.

I guess I must have misunderstood though, so could you please clarify 
what you meant?

> I think that the least we should do is to describe (definitely in 4.6
> and 8.5, and maybe also in 6.4) that the timing and message
> re-transmission for any unsolicited PAUSED or TMMBN=0 should be the
> same as is currently specified for TMMBR>0 (RESUME) in the draft.
> This, because the importance of an unsolicited TMMBN=0 (PAUSED) can
> be just as high as for a TMMBR>0 (RESUME).
>

I am not sure which section you are referring to. 8.3 maybe? I didn't 
see anything there that talks about reliability or retransmissions. Did 
I miss something?

> I don't know if this is sufficient. The major difference between
> PAUSED and RESUME is that PAUSED has no implicit ACK through RTP
> transmission state changes (as RESUME has), and that has to be
> handled somehow.

Right!

> Assuming that we agree that unsolicited PAUSED (same for TMMBN=0, of
> course) must be sent in a way that tries to mitigate loss to the
> largest extent possible, given existing RTCP bandwidth, I think the
> question then becomes for how long and how often should PAUSED be
> repeated until considered received. Could we suggest to use regular
> RTCP loss reporting to make an estimate on how many times it has to
> be repeated? For example, if there is 20% loss, it takes 5
> repetitions to get down to 0.032% loss probability for the PAUSED
> (given random loss). The overhead for that is really nothing compared
> to the media stream itself (that was just paused). Specifying even
> more repetitions should not be a problem, just being limited by the
> available RTCP bandwidth and timing!

I think this is a good idea. Just to be clear, are you intentionally 
avoiding the possibility for using a retransmit-until-acked mechanism?

Are you thinking that having to wait for an ACK may incur so much 
latency that the receiver could have a good guess that transmission has 
stopped?

> Do we need a new use case (section 3) and design consideration
> (section 4) for timing of unsolicited PAUSED? I think that might be
> appropriate!

If you decide that's necessary I can try to send some text next week.

Emil

>> -----Original Message----- From: avtext
>> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: den
>> 23 oktober 2014 23:41 To: Roni Even; [email-masked] Subject: Re:
>> [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02
>>
>> Hey Roni,
>>
>>> Hi Emil, OK, now I got it. I agree that we need some text
>>> addressing reliability of the unsolicited TMMBN and PAUSED.  I
>>> think I got confused by the work acknowledging and it seems to me
>>> that Bo had the same problem. But still since RTCP is runs over
>>> UDP there is still no guarantee that the RTCP packet will arrive
>>> even if we sent it with every scheduled RTCP packet.
>>>
>>> I agree that it will be good to add text about the unreliability
>>> of these indications and propose to repeat them based on
>>> implementation decision.
>>
>> I wonder if we could come up with an easy way to ACK the TMMBN=0
>> ... how about resending the same TMMBN=0 (with the same SSRCs) in
>> the opposite direction?
>>
>> Emil
>>
>>
>>>
>>> Roni
>>>
>>>> -----Original Message----- From: Emil Ivov
>>>> [mailto:[email-masked]] Sent: 23 October, 2014 1:05 PM To:
>>>> Roni Even; [email-masked] Subject: Re: [avtext] WGLC for
>>>> draft-ietf-avtext-rtp-stream-pause-02
>>>>
>>>> Hey Roni,
>>>>
>>>>> Hi Emil, I am not sure what is the case you describe. My view
>>>>> is that an SFU ( I assume it is a conferencing bridge?) may
>>>>> use TMMBR/PAUSE to stop unused video streams, these are
>>>>> acknowledged messages by the sender.
>>>>
>>>> Correct!
>>>>
>>>>> Another example is that for some reason a current sender will
>>>>> Pause a stream (I would think that it will be a stream not
>>>>> used currently) even though it did not get a TMMBR/PAUSE by
>>>>> learning somehow that the
>>>> stream is unused.
>>>> streaming something. The sender can also drop a stream because
>>>> it detected congestion.
>>>>
>>>>> If I understand you have another case  where a sender will
>>>>> pause, for some reason, a stream in use by the SFU and may
>>>>> send a TMMBN=0/PAUSED for this stream. Are you asking for a
>>>>> method by which the SFU will know if the sender supports
>>>>> TMMBN=0/PAUSED and will always send it when pausing a stream
>>>>> in use? I am not sure what is Acknowledge by the SFU to the
>>>>> media sender is and when is it sent, for this case?
>>>>
>>>> An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can
>>>> be lost. If that happens the Receiver/SFU would not know that
>>>> an in-use stream is
>>> being
>>>> intentionally dropped. That unsolicited TMMBN=0 would need to
>>>> be retransmitted by the Sender until it is eventually received
>>>> by the
>>> Receiver.
>>>>
>>>>>> -----Original Message----- From: Emil Ivov
>>>>>> [mailto:[email-masked]] Sent: 22 October, 2014 8:01 PM To:
>>>>>> Roni Even; [email-masked] Subject: Re: [avtext] WGLC for
>>>>>> draft-ietf-avtext-rtp-stream-pause-02
>>>>>>
>>>>>> Hey Roni,
>>>>>>
>>>>>>> Hi Emil, The unsolicited PAUSED or TMMBN=0 are an
>>>>>>> indication that the sender stopped sending the stream,
>>>>>>
>>>>>> Yes, it is.
>>>>>>
>>>>>> unsolicited PAUSED/TMMBNs in order to switch from one
>>>>>> simulcast stream to another, or to potentially drop a
>>>>>> sender from the SSRCs that it is sending
>>>>> to a
>>>>>> In order to rely on receiving TMMBNs, the SFU would need to
>>>>>> know that they are reliable though.
>>>>>>
>>>>>> Cheers, Emil
>>>>>>>> -----Original Message----- From: avtext
>>>>>>>> [mailto:[email-masked]] On Behalf Of Emil
>>>>>>>> Ivov Sent: 17 October, 2014 9:46 PM To: DRAGE, Keith
>>>>>>>> (Keith); [email-masked] Subject: Re: [avtext] WGLC
>>>>>>>> for draft-ietf-avtext-rtp-stream-pause-02
>>>>>>>>
>>>>>>>> I didn't see anything about acknowledging TMMBNs.
>>>>>>>> Specifically
>>>> TMMBN=0.
>>>>>>>>
>>>>>>>> MS SVC layer for congestion control reasons. TMMBN=0
>>>>>>>> would come very handy in that case as it would allow a
>>>>>>>> receiving SFU to quickly switch to
>>>>>>> a lower
>>>>>>>> quality layer.
>>>>>>>>
>>>>>>>> -- https://jitsi.org
>>>>>>>> _______________________________________________ avtext
>>>>>>>> mailing list [email-masked]
>>>>>> -- https://jitsi.org
>>>> -- https://jitsi.org
>> -- https://jitsi.org
>> _______________________________________________ avtext mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/avtext
>

-- 
https://jitsi.org

---

From: Bo Burman <[email-masked]>
Date: Mon, 27 Oct 2014 16:58:48 +0000

Hi Emil, inline.

> Sent: den 26 oktober 2014 01:19
> To: Bo Burman; Roni Even; [email-masked]
> >> I wonder if we could come up with an easy way to ACK the TMMBN=0 ...
> >> how about resending the same TMMBN=0 (with the same SSRCs) in the
> >> opposite direction?
> >
> I am not sure I get the question. If you mean that new ACK message that we could add, then yes of course ... and
> obviously the idea would be to resend the TMMBN=0 until the ACK is received.
> 
> I guess I must have misunderstood though, so could you please clarify what you meant?
[BoB] Apologies for being unclear, again. I really meant to say that if you anyway specify TMMBN=0 (PAUSED) to be re-sent multiple times (similar to RESUME, as I suggest below), ACK can be seen as a kind of optimization that stops such repetition as soon as possible. When the (new) ACK is lost, the repetition of PAUSED continues for a while longer, and since ACK may get lost it is not guaranteed that message repetition is stopped as soon as PAUSED is received. ACK is thus not required to get the functionality I (now finally; thank you Roni for helping out) understand you want.

> > This, because the importance of an unsolicited TMMBN=0 (PAUSED) can be
> > just as high as for a TMMBR>0 (RESUME).
> >
> I am not sure which section you are referring to. 8.3 maybe? I didn't see anything there that talks about reliability or
> retransmissions. Did I miss something?
[BoB] I meant to point to the following parts of the document:
Section 4.6 Request Retransmission says (for resume):

   When it comes to resume requests that are more time critical, the
   best resume performance may be achieved by repeating the request as
   often as possible until a sufficient number have been sent to reach a
   high probability of request delivery, or the stream gets delivered.

I propose to amend this paragraph to something like: 

   When it comes to resume requests or paused indications that are more time critical, the
   best performance may be achieved by repeating the message as
   often as possible until a sufficient number have been sent to reach a
   high probability of message delivery, or at an explicit indication that the
   message was delivered. For resume requests, such indication can be
   that the requested stream gets delivered. For paused indications
   <...text to be inserted, reflecting upcoming agreement from this discussion...>

Section 6.4 Local Paused State:

   This state can be entered at any time, based on local decision from
   the RTP stream sender.  As for Paused State (Section 6.3), the RTP
   stream sender SHALL send a PAUSED indication to all known RTP stream
   receivers, when entering the state, and repeat it in the next two
   regular RTCP reports, unless the stream was already in paused state
   (Section 6.3).

I suggest to amend this to something like:

   This state can be entered at any time, based on local decision from
   the RTP stream sender.  As for Paused State (Section 6.3), the RTP
   stream sender SHALL send a PAUSED indication to all known RTP stream
   receivers, when entering the state, and repeat it until <...condition to
   be defined...>, unless the stream was already in paused state
   (Section 6.3).

Section 8.5 Transmission Rules:

   o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.

   o  RESUME SHOULD always use Immediate or Early timing.

I suggest to change this to:

   o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing. Unsolicited
      PAUSED SHOULD always use Immediate or Early timing, until
      PAUSED for that PauseID is considered delivered at least once by
      all receivers of the paused RTP stream, after which it SHOULD use
      Regular timing.
      <...text about when "considered delivered" is true...>

   o  RESUME SHOULD always use Immediate or Early timing.

> > transmission state changes (as RESUME has), and that has to be handled
> > somehow.
> 
> Right!
> 
> > RTCP loss reporting to make an estimate on how many times it has to be
> > repeated? For example, if there is 20% loss, it takes 5 repetitions to
> > get down to 0.032% loss probability for the PAUSED (given random
> > loss). The overhead for that is really nothing compared to the media
> > stream itself (that was just paused). Specifying even more repetitions
> > should not be a problem, just being limited by the available RTCP
> > bandwidth and timing!
> 
> I think this is a good idea. Just to be clear, are you intentionally avoiding the possibility for using a retransmit-until-acked
> mechanism?
[BoB] I am trying to understand if this can work sufficiently well without it, yes.

If we decide that we indeed need a PAUSED-ACK, do you think that PAUSE will do (from the new messages in this draft, if using those) as confirmation? The semantics of PAUSE is "OK, I don't need this stream right now", and is thus not in any way mandating to pause the (in this case already paused) stream. This should be fully consistent with the RTP stream receiver being able to send a RESUME (TMMBR > 0) at a later point in time to try to resume the stream, even if the RTP stream sender has the last say for a locally paused stream as long as the "local consideration" still applies. If this use of PAUSE is not clear enough, we may need to consider defining a new message.

Even if (new message from this draft) PAUSE semantics is OK as PAUSED ACK, and even if PAUSE is "normally" equivalent to TMMBR=0, it would obviously not always be appropriate to use TMMBR=0 as TMMBN=0 confirmation, since the RTP stream sender then cannot resume the RTP stream unless the stream receiver explicitly allows it by sending a TMMBR>0.

Regardless if we use PAUSE or some new message as PAUSED-ACK for the new messages defined in this draft, I agree with your proposal that for "TMMBR/TMMBN-mode" it would likely work to use TMMBN=0 with the same SSRC as in the ACK'ed TMMBN=0. This, since the SSRC in the TMMBN FCI expresses the owner of the tuple and is semantically correct regardless of which way it is sent. SSRC of packet sender must of course be set correctly to the source of the notification, which will be different in the two directions (for TMMBN=0 and TMMBN=0-ACK).

> 
> Are you thinking that having to wait for an ACK may incur so much latency that the receiver could have a good guess that
> transmission has stopped?
[BoB] That is a possibility I would like to explore, yes.

> If you decide that's necessary I can try to send some text next week.
[BoB] I think it will at least help make the motivations for choosing this strict PAUSED timing more clear to future readers. Text proposals are welcome.

> >>> Hi Emil, OK, now I got it. I agree that we need some text addressing
> >>> confused by the work acknowledging and it seems to me that Bo had
> >>> the same problem. But still since RTCP is runs over UDP there is
> >>> still no guarantee that the RTCP packet will arrive even if we sent
> >>> it with every scheduled RTCP packet.
> >>>
> >> I wonder if we could come up with an easy way to ACK the TMMBN=0 ...
> >> how about resending the same TMMBN=0 (with the same SSRCs) in the
> >> opposite direction?
> >>
> >> Emil
> >>
> >>
> >>>
> >>> Roni
> >>>
> >>>> -----Original Message----- From: Emil Ivov [mailto:[email-masked]]
> >>>> Sent: 23 October, 2014 1:05 PM To:
> >>>>> Hi Emil, I am not sure what is the case you describe. My view is
> >>>>> that an SFU ( I assume it is a conferencing bridge?) may use
> >>>>> TMMBR/PAUSE to stop unused video streams, these are acknowledged
> >>>>> messages by the sender.
> >>>>
> >>>> Correct!
> >>>>
> >>>>> Pause a stream (I would think that it will be a stream not used
> >>>>> currently) even though it did not get a TMMBR/PAUSE by learning
> >>>>> somehow that the
> >>>> stream is unused.
> >>>>> TMMBN=0/PAUSED for this stream. Are you asking for a method by
> >>>>> which the SFU will know if the sender supports TMMBN=0/PAUSED and
> >>>>> will always send it when pausing a stream in use? I am not sure
> >>>>> what is Acknowledge by the SFU to the media sender is and when is
> >>>>> it sent, for this case?
> >>>>
> >>>> An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can be
> >>>> lost. If that happens the Receiver/SFU would not know that an
> >>>> in-use stream is
> >>> being