Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Feb 2013 02:28:54 +0100

I think I spotted two spelling mistakes:

- Section 1: "During a point to point or multipoint call a sender may 
mute his microphone or camera but still continue to send media which may 
be some syntactic media." This makes more sense to me if "syntactic" is 
replaced with "synthetic".

- Section 3: "For the pause request using TMMBR with bit rate "0" will 
make an RTP media sender stop sending an RTP stream if it is used by 
others that have not requested a pause." This makes more sense to me if 
"if it is used" is replaced by "if it is not being used".

If I misunderstood the document, please holler!

Content issues:

- If TMMBR is used as a congestion control signal mechanism, TMMBR=0 
will interact with it. How and where should that interaction be 
described - in particular, after a pause (TMMBR=0), what value should 
the receiver use in the resume (TMMBR=N) message?

- If muted / not rendered is unimportant enough that nobody's offered 
token text to drag in here, perhaps we should remove the sections? 
Conversely, if it is important, can someone suggest text?

            Harald

On 01/24/2013 07:59 PM, Roni Even wrote:
> Hi,
> I resubmitted the draft since I noticed I did not have avtext in the draft name and it appeared as https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/
>
> Roni Even
>
> ________________________________________
> From: [email-masked] [[email-masked]]
> Sent: Thursday, January 24, 2013 8:56 PM
> To: Roni Even
> Subject: New Version Notification for   draft-even-avtext-flow-control-to-zero-00.txt
>
> A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt
> has been successfully submitted by Roni Even and posted to the
> IETF repository.
>
> Filename:        draft-even-avtext-flow-control-to-zero
> Revision:        00
> Title:           Pausing an RTP Media Stream
> Creation date:   2013-01-24
> WG ID:           Individual Submission
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero
> Htmlized:        http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00
>
>
> Abstract:
>     In Real-time multimedia applications using multiple media streams in
>     point to point and multipoint calls can benefit from options that
>     will enable them to pause and resume media streams as well as to
>     indicate a mute state.  This document describes the difference
>     between pause and mute and describes how to provide this required
>     functionality.  This document updates RFC5104.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Bo Burman <[email-masked]>
Date: Mon, 18 Feb 2013 14:13:26 +0000

Hi,

Regarding the anticipated spelling error in section 3, I believe the original text to be correct. This is in fact a potential problem with TMMBR semantics being used as pause, since any sender of TMMBR 0 will unconditionally pause the stream also for other listeners to that stream, if any.

Cheers,
Bo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Sunday, February 03, 2013 2:29 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

- Section 1: "During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media." This makes more sense to me if "syntactic" is replaced with "synthetic".

- Section 3: "For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause." This makes more sense to me if "if it is used" is replaced by "if it is not being used".

Content issues:

- If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will interact with it. How and where should that interaction be described - in particular, after a pause (TMMBR=0), what value should the receiver use in the resume (TMMBR=N) message?

- If muted / not rendered is unimportant enough that nobody's offered token text to drag in here, perhaps we should remove the sections? 
Conversely, if it is important, can someone suggest text?

            Harald

On 01/24/2013 07:59 PM, Roni Even wrote:
> Hi,
> I resubmitted the draft since I noticed I did not have avtext in the 
> draft name and it appeared as 
> https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/
>
> Roni Even
>
> has been successfully submitted by Roni Even and posted to the IETF 
> repository.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Feb 2013 15:43:28 +0100

> Regarding the anticipated spelling error in section 3, I believe the original text to be correct. This is in fact a potential problem with TMMBR semantics being used as pause, since any sender of T…

Thanks - after reading section 3.5.4.2 of RFC 5104, I agree that this 
will be the result.

I believe a better formulation will then be "... will make an RTP media 
sender stop sending an RTP stream. This will happen even if it used by 
others that have not requested a pause."

---

From: "Roni Even" <[email-masked]>
Date: Mon, 18 Feb 2013 17:22:25 +0200

Hi Harald,
I will fix the typo in section 1 and can use your text in section 3.
About " muted / not rendered", H.32x video conferring systems indicate to
the user if they are being currently seen by others. I raised this as part
of the complete application usage and if there will be interest I can add
text.
As for congestion usage of TMMBR, RFC5104 says that TMMBR is not a
congestion control mechanism and it does not discuss the change to higher
rate based on change in the congestion state of the network.
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: 18 February, 2013 4:43 PM
To: Bo Burman
Cc: [email-masked]
Subject: Re: [avtext] FW: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt

On 02/18/2013 03:13 PM, Bo Burman wrote:
> Hi,
>
> Regarding the anticipated spelling error in section 3, I believe the
original text to be correct. This is in fact a potential problem with TMMBR
semantics being used as pause, since any sender of TMMBR 0 will
unconditionally pause the stream also for other listeners to that stream, if
any.

Thanks - after reading section 3.5.4.2 of RFC 5104, I agree that this will
be the result.

> Subject: Re: [avtext] FW: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt
> - Section 1: "During a point to point or multipoint call a sender may mute
his microphone or camera but still continue to send media which may be some
syntactic media." This makes more sense to me if "syntactic" is replaced
with "synthetic".
> - Section 3: "For the pause request using TMMBR with bit rate "0" will
make an RTP media sender stop sending an RTP stream if it is used by others
that have not requested a pause." This makes more sense to me if "if it is
used" is replaced by "if it is not being used".
> - If TMMBR is used as a congestion control signal mechanism, TMMBR=0 will
interact with it. How and where should that interaction be described - in
particular, after a pause (TMMBR=0), what value should the receiver use in
the resume (TMMBR=N) message?
>> Subject: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt
>> URL:
http://www.ietf.org/internet-drafts/draft-even-avtext-flow-control-to-zero-0
0.txt
>> Status:
http://datatracker.ietf.org/doc/draft-even-avtext-flow-control-to-zero
>> Htmlized:
http://tools.ietf.org/html/draft-even-avtext-flow-control-to-zero-00

---

From: "Roni Even" <[email-masked]>
Date: Mon, 18 Feb 2013 17:29:38 +0200

Hi Bo,
My understanding of the initial algorithm in 3.5.4.2 of RFC 5104 is that if
max total BR is 0 in the TMMBR message this is what will happen in point to
point and the centralized multipoint cases
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bo Burman
Sent: 18 February, 2013 4:13 PM
To: Harald Alvestrand; Roni Even
Cc: [email-masked]
Subject: Re: [avtext] FW: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt

Hi,

Cheers,
Bo

-----Original Message-----

- Section 3: "For the pause request using TMMBR with bit rate "0" will make
an RTP media sender stop sending an RTP stream if it is used by others that
have not requested a pause." This makes more sense to me if "if it is used"
is replaced by "if it is not being used".

Content issues:

- If muted / not rendered is unimportant enough that nobody's offered token
text to drag in here, perhaps we should remove the sections? 
Conversely, if it is important, can someone suggest text?

            Harald

---

From: Bo Burman <[email-masked]>
Date: Wed, 20 Feb 2013 13:26:36 +0000

Hi Roni,

Here are a few comments from me:

* I agree that TMMBR 0 can be used as "PAUSE" in the point-to-point
  case, but I would like to see a description of how a media sender
  can know that it is a point-to-point session, alternatively how
  it may learn that it is not and how it should react in that case

* You say that the major reason that TMMBR has a delay on rate
  increase is that it may go above SDP "b" attribute. I don't
  believe this is correct. See for example RFC 5104 section 3.5.4
  "The limit may change to any value between zero and the session
  maximum, as negotiated during session establishment signaling".
  The same section also clearly states the reason for the delay:
  "This delay is introduced to allow other session participants
  to make known their bit rate limit requirements, which may be
  lower", taking into account that the raised value could be too
  high for another media receiver that did not yet send any TMMBR
  because it was happy with the previous one, and the raised value
  would exceed its limit. If this other media receiver is not given
  sufficient time to be pro-active and set an acceptable new limit
  before actually increasing the bitrate, the increased bitrate
  could cause problems until a new TMMBR limit is established

Cheers,
Bo Burman

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Thursday, January 24, 2013 7:59 PM
To: [email-masked]
Subject: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

Hi,

Roni Even

A new version of I-D, draft-even-avtext-flow-control-to-zero-00.txt
has been successfully submitted by Roni Even and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: "Roni Even" <[email-masked]>
Date: Wed, 20 Feb 2013 16:51:14 +0200

Hi Bo,
All these problems are not relevant in point to point and centralized
multipoint. I am not sure what you mean by knowing. If the EP is not in a
broadcast/multicast session. 
In unicast the other side may be an endpoint which is clear from the RTCP
receiver report and the received streams. In the multipoint case this is up
to the central MCU to decide what is the behavior and the MCU knows what is
the connection

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bo Burman
Sent: 20 February, 2013 3:27 PM
To: Roni Even; [email-masked]
Subject: Re: [avtext] FW: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt

Hi Roni,

Cheers,
Bo Burman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Thursday, January 24, 2013 7:59 PM
To: [email-masked]
Subject: [avtext] FW: New Version Notification for
draft-even-avtext-flow-control-to-zero-00.txt

Hi,
I resubmitted the draft since I noticed I did not have avtext in the draft
name and it appeared as
https://datatracker.ietf.org/doc/draft-even-flow-control-to-zero/

Roni Even

Abstract:

The IETF Secretariat

---

From: Bo Burman <[email-masked]>
Date: Wed, 27 Feb 2013 13:31:39 +0000

Hi Roni,

Will it always be entirely clear to an endpoint that it is sending media to only a single receiver, and that an immediate response to TMMBR >0 is thus OK?

I can at least see two different cases where it is not sufficient for the media sender to rely on RTCP reporting only:

1. An RTP Transport Translator is used between the media sender and
   a set of receivers. From an RTCP reporting perspective, the media
   sender cannot distinguish RTCP reports from this set of separate
   receivers (with separate reporting SSRC) from a single receiver
   with several listening and thus reporting SSRC. The media sender
   thus cannot safely assume that it is a point-to-point session.

2. A Source Projecting Mixer is used between the media sender and
   a set of receivers. This is not that different from the above,
   only that the source SSRC seen by the media sender in the RTCP
   reports are the Mixer's own. There are however, to the media
   sender, apparently several receiving SSRC even if the link
   between the media sender and the Source Projecting Mixer is
   in fact point-to-point.

The media sender thus needs some other indication that it is really sending to a single media receiver and that immediate increase of bitrate based on a TMMBR >0 is OK. You do not suggest any such mechanism in your draft.

Cheers,
Bo

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, February 20, 2013 3:51 PM
To: Bo Burman; 'Roni Even'; [email-masked]
Subject: RE: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

Hi Bo,
All these problems are not relevant in point to point and centralized multipoint. I am not sure what you mean by knowing. If the EP is not in a broadcast/multicast session. 
In unicast the other side may be an endpoint which is clear from the RTCP receiver report and the received streams. In the multipoint case this is up to the central MCU to decide what is the behavior and the MCU knows what is the connection

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: 20 February, 2013 3:27 PM
To: Roni Even; [email-masked]
Subject: Re: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

Hi Roni,

Cheers,
Bo Burman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Thursday, January 24, 2013 7:59 PM
To: [email-masked]
Subject: [avtext] FW: New Version Notification for draft-even-avtext-flow-control-to-zero-00.txt

Hi,

Roni Even

Abstract:

The IETF Secretariat