Subject: [AVT] On the use of TMMBR

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 28 Jul 2010 13:40:05 +0200

Hi

I am looking for some guidance as regards to the use of TMMBR as described in RFC5104.

My personal interpreation is that TMMBR is used to signal an upper limit of the bitrate to the sender. The actual sender bitrate is however determined by the sender based on info in the received RTCP reports (Reveiver report blocks, ECN feedback etc.) I call this "alternative 1".

One may however make a more liberal interpretation. One such is to use TMMBR as a means to send rate requests as a reaction to e.g ECN-CE marks (or packet loss). I call this "alternative 2". As an example a video service is run at 400kbps, an ECN-CE mark is received and as a reation to this an RTCP TMMBR is sent to the sender with the value 300kbps. I believe that this is a bit unorthodox. Question is however.. does this cause any potential interoperability issues (for instance if receiver acts according to alt 2 and sender acts according to alt 1). I can magine some issues but I would appreciate input from others on this matter.

Regards
Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 29 Jul 2010 07:59:39 -0700

Hi Ingemar,

I had assumed the latter interpretation. I would expect the upper limit is specified by the signaling protocol (i.e. SIP), and tmmbr is used to express temporary changes (hence the name Temporary Maximum Media Stream Bit Rate Request) that do not exceed the maximum specified in the signaling protocol.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
> Sent: Wednesday, July 28, 2010 4:40 AM
> To: [email-masked]
> Subject: [AVT] On the use of TMMBR
> 
> Hi
> 
> My personal interpreation is that TMMBR is used to signal an upper limit of the bitrate to the sender.
> The actual sender bitrate is however determined by the sender based on info in the received RTCP
> reports (Reveiver report blocks, ECN feedback etc.) I call this "alternative 1".
> 
> One may however make a more liberal interpretation. One such is to use TMMBR as a means to send rate
> requests as a reaction to e.g ECN-CE marks (or packet loss). I call this "alternative 2". As an
> example a video service is run at 400kbps, an ECN-CE mark is received and as a reation to this an RTCP
> TMMBR is sent to the sender with the value 300kbps. I believe that this is a bit unorthodox. Question
> is however.. does this cause any potential interoperability issues (for instance if receiver acts
> according to alt 2 and sender acts according to alt 1). I can magine some issues but I would
> appreciate input from others on this matter.
> 
> Regards
> Ingemar
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 29 Jul 2010 18:56:08 +0200

My interpretation of TMMBR is in line with Ingemar's "alternative 2"
too. Browsing through RFC5104 once more to assure didn't change that!
The upper limit of the bitrate is established by some sort of
signalling and TMMBR is used for temporary lowering the wanted max Rx
bitrate.

Of course, the bitrate reported by RTCP receiver reports and similar
mechanisms should stay below the min of "signalling rate" and the
"active TMMBR rate" - given the sender behaves as intended.

-- Tom

-- 
# TANDBERG, now part of Cisco
## http://www.tandberg.com
### http://folk.uio.no/tomkri/

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 29 Jul 2010 22:59:18 -0500

I think in practice both alternatives will always be used simultaneously, i.e. senders act according to 1 and receivers act according to 2, if TMMBR is supported. TMMBR is simply another feedback tool in the receiver's feedback toolset, and does not replace all other feedback (RR, NACK, ECN, etc.). A receiver which signals TMMBR does so thinking that it knows a better ceiling than the sender, or in case the sender does not adapt its send rate based on other feedback. But it seems extremely unlikely any sender would only adapt based on TMMBR but not any other feedback. It is much more likely all senders ultimately make all actual bitrate decisions taking into account all receiver feedback including TMMBR, RR, NACK, ECN, etc. I see no interoperability issues with this, other than having such a multiplicity of feedback mechanisms reduces the chances of both sides having compatible ones.

Regards,
Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Kristensen
Sent: Thursday, July 29, 2010 12:56 PM
To: Charles Eckel (eckelcu)
Cc: Ingemar Johansson S; Tom Kristensen; [email-masked]
Subject: Re: [AVT] On the use of TMMBR

-- Tom

On 29 July 2010 16:59, Charles Eckel (eckelcu) <[email-masked]:
Hi Ingemar,

Cheers,
Charles

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Wednesday, July 28, 2010 4:40 AM
To: [email-masked]
Subject: [AVT] On the use of TMMBR

Hi

Regards
Ingemar

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289