Subject: [avtext] Pause and Resume CCM extension

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Nov 2011 16:10:10 +0100

Hi,

As individual,

My colleagues and I have put together a proposal for a functionality for
pausing and resuming media streams. This is primarily intended for mixer
scenarios where a mixer would send the pause request to media senders
that currently don't need to send any media for the mixer isn't using
this source. For example video streams when the participant isn't active.

Draft:
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/

It does cover a few other usages but that is primarily to ensure that it
wouldn't break the whole system if introduced into ASM or transport
relay topologies.

This proposal is also based on that the system in general may use
something like the Media Stream Selection (see link below) to include or
exclude media streams they don't want. Thus we have in fact excluded
such usages by not allowing the end-points to use this to manipulate the
CSRC list of media stream that are mixes or selections. This as it would
only provide partial functionality compared to Media Stream Selection.

https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/

Feedback is most appreciated

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 4 Nov 2011 22:24:10 -0500

Magnus,
How does the proposed pause differ from tmmbr=0? Some implementations already use tmmbr=0 to pause peers.

Assuming there is some valuable nuance between pause and tmmbr=0, it may be useful to explicitly allow acks without requests so senders can notify peers when they pause (and resume) themselves autonomously. This is not explicitly prohibited in the current draft, just as autonomous tmmbn (without tmmbr) is not explicitly prohibited in RFC 5104. But it would be good to explicitly allow and describe this use case. Some implementations already use tmmbn=0 to notify peers they have paused themselves autonomously (without receiving any tmmbr). 

Thanks,
Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, November 03, 2011 11:10 AM
To: [email-masked]
Subject: [avtext] Pause and Resume CCM extension

Hi,

As individual,

Draft:

Cheers

Magnus Westerlund

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext

---

From: Roni even <[email-masked]>
Date: Mon, 07 Nov 2011 11:58:09 +0000

Hi,
I agree with Mo, the tmmbr=0 is probably used by video conferencing applications to temporary stop video flows. So why use a new method.

Roni

________________________________________
From: [email-masked] [[email-masked]] on behalf of Mo Zanaty (mzanaty) [[email-masked]]
Sent: Saturday, November 05, 2011 5:24
To: Magnus Westerlund; [email-masked]
Subject: Re: [avtext] Pause and Resume CCM extension

Magnus,

Thanks,
Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, November 03, 2011 11:10 AM
To: [email-masked]
Subject: [avtext] Pause and Resume CCM extension

Hi,

As individual,

Draft:

Cheers

Magnus Westerlund

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 7 Nov 2011 14:38:12 -0600

Perhaps this should be reworked into an Informational RFC on how to use TMMBR/TMMBN for such functionality, since it is not obvious whether or not RFC 5104 allows this. Or, if IETF prefers to focus on standards, then perhaps other forums which focus on interoperability and implementation guidelines (like IMTC, UCIF, etc.) can codify this usage in their recommendations.

Thanks,
Mo

-----Original Message-----
From: Roni even [mailto:[email-masked]] 
Sent: Monday, November 07, 2011 6:58 AM
To: Mo Zanaty (mzanaty); Magnus Westerlund; [email-masked]
Subject: RE: [avtext] Pause and Resume CCM extension

Hi,

Roni

Magnus,

Thanks,
Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, November 03, 2011 11:10 AM
To: [email-masked]
Subject: [avtext] Pause and Resume CCM extension

Hi,

As individual,

Draft:

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Nov 2011 13:50:57 +0100

On 2011-11-07 21:38, Mo Zanaty (mzanaty) wrote:
> Perhaps this should be reworked into an Informational RFC on how to
> use TMMBR/TMMBN for such functionality, since it is not obvious
> whether or not RFC 5104 allows this. Or, if IETF prefers to focus on
> standards, then perhaps other forums which focus on interoperability
> and implementation guidelines (like IMTC, UCIF, etc.) can codify this
> usage in their recommendations.

Hi,

We had considered this but think there are a few issues with using TMMBR=0.

First, the semantics of TMMBR in that it cuts the bit-rate immediately
and only the increase allows other receivers to reconsider the change.
This is problematic in any scenario where you have a shared media, like
ASM or Transport Translators instead of RTP mixer topologies.

If you contrast our the PAUSE proposal with this, it takes the safer but
more complicated way of requiring all known receivers to send pause
before it occurs.

secondly, when resuming the TMMBR semantics is to not increase the
bit-rate until all participants has had the possibility to inject a new
limiation. That is not suitable at all for resume, that needs to happen
immediately.

So we think there is significant semantics issues with TMMBR/TMMBN for
pause and resume.

Cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Tue, 8 Nov 2011 18:03:57 +0200

Hi Magnus,
The document does not discuss the TMMBR (RFC 5104) option and section 1 says
that "No currently existing RTCP feedback message supports pausing and
resuming an incoming data stream." 

The use cases in sections 3.1 and 3.2 can be addressed by TMMBR and this is
what is being used today by shipping products.
Section 4.4 is the only section about multicast and describes the behavior
of a sender in a multicast group saying that it shall not pause until all
the receivers that the sender knows of have requested it to be paused.  I am
not sure that real use cases will cause this to happen.
So the question is why add a new way to do something that is being done
today by TMMBR in the common cases.

Regards
Roni

> Sent: Tuesday, November 08, 2011 2:51 PM
> To: Mo Zanaty (mzanaty)
> Cc: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Nov 2011 10:57:10 +0100

> resuming an incoming data stream."

Yes, we should have discussed TMMBR and its shortcomming. We will
address this in a future revision.

> today by TMMBR in the common cases.

Still the TMMBR semantics do create two issues, even in Point to Point
and RTP Mixer to Media sender use case.

The biggest issue is the resume semantics. TMMBR says the following:

  "If the media sender concludes that it can increase the maximum total
   media bit rate value, it SHALL wait before actually doing so, for a
   period long enough to allow a media receiver to respond to the TMMBN
   if it determines that its tuple belongs in the bounding set.  This
   delay period is estimated by the formula:

      2 * RTT + T_Dither_Max,

   where RTT is the longest round trip time known to the media sender
   and T_Dither_Max is defined in section 3.4 of [RFC4585].  Even in
   point-to-point sessions, a media sender MUST obey the aforementioned
   rule, as it is not guaranteed that a participant is able to determine
   correctly whether all the sources are co-located in a single node,
   and are coordinated."

Based on this a media receiver or mixer sending TMMBR>0 to the media
sender will not get media until two*RTT + T_Dither_Max. That is highly
problematic from our point of view. And if the above behavior should not
be done in the case of TMMBR=0 then it needs to be specified.

In most cases, the session topology a end-point is present in is hard to
determine. For example how does a end-point determine if it is in a
point to point session or a Transport Translator multi-point session
(relay) that currently only has two participants in it. Thus it becomes
hard to determine if it acceptable for the end-point to send a TMMBR=0
as it is the sole receiver, or if other end-points that was interested
of the media still needs it.

If it is a relay based topology a new participant can join at any time.
And if there is an existing TMMBR=0 limitation in place the then the new
participant will not know that this media sender is in fact paused by
another receiver.

So we think these issues with TMMBR semantics that a alternative should
be seriously considered.

Magnus Westerlund

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 11:59:20 +0800

Our products support tmmbr; we would rather not see yet-another-mechanism
for pause/resume.

While perhaps the semantics are not perfect, providing a competing
mechanism will not help interoperability.

Stephen Botzko

On Mon, Nov 7, 2011 at 7:58 PM, Roni even <[email-masked]> wrote:

> Hi,
> I agree with Mo, the tmmbr=0 is probably used by video conferencing
> applications to temporary stop video flows. So why use a new method.
>
> Roni
>
> Assuming there is some valuable nuance between pause and tmmbr=0, it may
> be useful to explicitly allow acks without requests so senders can notify
> peers when they pause (and resume) themselves autonomously. This is not
> explicitly prohibited in the current draft, just as autonomous tmmbn
> (without tmmbr) is not explicitly prohibited in RFC 5104. But it would be
> good to explicitly allow and describe this use case. Some implementations
> already use tmmbn=0 to notify peers they have paused themselves
> autonomously (without receiving any tmmbr).
>
> Thanks,
> Mo
>