Subject: Re: [AVT] On the use of TMMBR

From: Colin Perkins <[email-masked]>
Date: Mon, 2 Aug 2010 17:41:26 +0100

Hi,

Your "alternative 1" is closer to how I envisaged TMMBR being used.  
TMMBR provides an upper bound on the sending rate, based on some  
estimate of the link capacity, and a congestion control algorithm  
should be run to estimate the actual bandwidth available, which will  
be somewhere below the TMMBR rate.

The issue with your "alternative 2" is that it leads to senders  
blindly following the TMMBR rate, even though the TMMBR rate isn't  
guaranteed to match the available bandwidth (for example, if a  
receiver sets the TMMBR rate based on its edge link, but the  
bottleneck is in the core network). Also, TMMBR doesn't safely allow  
rate increases.

Colin

On 28 Jul 2010, at 12:40, Ingemar Johansson S wrote:
> 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 !
> =================================
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 3 Aug 2010 14:08:10 +0200

Hi

Thanks all for the responses. I must admit that originally I found alternative 2 more attractive some 2 years ago but after some time looking at the ECN for RTP draft and also trying to to understand in general how TMMBR is supposed to co-work with other feedback from the receiver I have come to the conclusion that alternative 1 is the most clean cut.

I am not in the position to forbid others from alternative  2 below but I would really recommend people who prefer this alternative to consider possible future interoperability issues. TMMBR will likely be used in services specified in other non-IETF organization such as 3GPP. It is quite likely that these services will need to interoperate with equipment outside these walled gardens in the future. One evidence of this trend is the proposed work around Telepresence in DISPATCH and ITU-T. TMMBR is a very small piece here but possible interop issues here will have direct impact in terms of more complex gateway implementations.

Just my 5 tokens of any applicable currency.

/Ingemar

________________________________________
Från: Colin Perkins [[email-masked]]
Skickat: den 2 augusti 2010 18:41
Till: Ingemar Johansson S
Kopia: [email-masked]
Ämne: Re: [AVT] On the use of TMMBR

Hi,

Colin

--
Colin Perkins
http://csperkins.org/

---

From: Roni Even <[email-masked]>
Date: Tue, 03 Aug 2010 16:24:00 +0300

Hi Ingemar,
My view now and in the design phase was what you call alternative 1. When
the solution was designed it was to supply similar functionality to H.245
flow control command. We did not have an end to end message that will allow
temporary change of bit rate, this is specified in the text for TMMBR as use
case 6 from section 3.1. Before having this functionality the only way to
achieve this was to use the signaling path with a new b= parameter, for
example using SIP UPDATE method. The TMMBR request from the receiver cannot
be higher than the maximum bit rate from the negotiated b= parameter from
the signaling. This is a receiver request for maximum bit rate.
Now the sender need to take into account the congestion conditions and can
send at a lower rate as long as it does not send at an average rate higher
than the TMMBR value.

Also note that the requester is mostly interested in the media bit rate and
not the RTP or UDP bit rate and this is the reason for the tuple to allow
the sender to know the actual media rate that the receivers wants. So the
design was made with the application in mind and not any other reason

As for alternative 2, did you mean that the receiver will ask for a specific
rate and not a maximum rate. 

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ingemar Johansson S
> Sent: Tuesday, August 03, 2010 3:08 PM
> To: Colin Perkins
> Cc: [email-masked]
> Subject: Re: [AVT] On the use of TMMBR
> 
> Hi
> 
> Thanks all for the responses. I must admit that originally I found
> alternative 2 more attractive some 2 years ago but after some time
> looking at the ECN for RTP draft and also trying to to understand in
> general how TMMBR is supposed to co-work with other feedback from the
> receiver I have come to the conclusion that alternative 1 is the most
> clean cut.
> 
> I am not in the position to forbid others from alternative  2 below but
> I would really recommend people who prefer this alternative to consider
> possible future interoperability issues. TMMBR will likely be used in
> services specified in other non-IETF organization such as 3GPP. It is
> quite likely that these services will need to interoperate with
> equipment outside these walled gardens in the future. One evidence of
> this trend is the proposed work around Telepresence in DISPATCH and
> ITU-T. TMMBR is a very small piece here but possible interop issues
> here will have direct impact in terms of more complex gateway
> implementations.
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 6 Aug 2010 10:53:05 +0200

Hi

Thanks for the historical lookback, makes it easier to nail down what TMMBR is meant for and yes.. Alternative 2 is basically that the receiver use TMMBR to ask for a specific bitrate.

It seems though like this working group has slightly different opinions on this matter. On the one side we have people being involved in the design of TMMBR who are in favour of using TMMBR to signal a maximum bitrate and let the sender base its sender rate based on congestion conditions with TMMBR as highest possible bitrate. On the other hand we have people who may consider to let the receiver use TMMBR to request a specific bitrate.

I do really believe that everyone would benefit if we could agree on one alternative (my preference is what I refer to as alternative 1). It will cause less headache in the long run when issues like interoperability becomes more important.

So my questions.. 
1) Is this a matter important enough to warrant a clarification from the WG?.
2) Should other standards bodies with interest in RFC5104 be informed?
3) What should the message be?.

Regards
Ingemar

________________________________________
Från: Roni Even [[email-masked]]
Skickat: den 3 augusti 2010 15:24
Till: Ingemar Johansson S; 'Colin Perkins'
Kopia: [email-masked]
Ämne: RE: [AVT] On the use of TMMBR

Hi Ingemar,

Roni

---

From: Roni Even <[email-masked]>
Date: Fri, 06 Aug 2010 11:59:34 +0300

Ingemar,
For the video use case it is not easy to ask for a specific bit rate, we
usually talk about an average bit rate since it depends on the information
in the frame. I can see a use case for constant bit rate audio codec that
may use this request for specific rate but this was not part of the design
goals. 
Anyhow regardless if it is request for a specific rate or maximum rate and
since it is a receiver request still the sender need to behave under
congestion and reduce the transmit rate. This is easier for variable bit
rate codecs and mostly for video. 
To summarize, I will not count on a video sender to send an exact rate but
more likely having it as average maximum rate.
Roni

> Sent: Friday, August 06, 2010 11:53 AM
> To: Roni Even; 'Colin Perkins'
> Cc: Ingemar Johansson S; [email-masked]; [email-masked]
> Thanks for the historical lookback, makes it easier to nail down what
> TMMBR is meant for and yes.. Alternative 2 is basically that the
> receiver use TMMBR to ask for a specific bitrate.
> 
> It seems though like this working group has slightly different opinions
> on this matter. On the one side we have people being involved in the
> design of TMMBR who are in favour of using TMMBR to signal a maximum
> bitrate and let the sender base its sender rate based on congestion
> conditions with TMMBR as highest possible bitrate. On the other hand we
> have people who may consider to let the receiver use TMMBR to request a
> specific bitrate.
> 
> I do really believe that everyone would benefit if we could agree on
> one alternative (my preference is what I refer to as alternative 1). It
> will cause less headache in the long run when issues like
> interoperability becomes more important.
> 
> So my questions..

---

From: Roni Even <[email-masked]>
Date: Fri, 06 Aug 2010 12:02:46 +0300

Ingemar,
As for your question

1. I think that the text is very clear in 3.5.4

" A receiver, translator, or mixer uses the Temporary Maximum Media
   Stream Bit Rate Request (TMMBR, "timber") to request a sender to
   limit the maximum bit rate for a media stream (see section 2.2) to,
   or below, the provided value.  "

2 and 3. If there are issues in other bodies refer them to section 3.5.4

Roni

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 10 Aug 2010 14:02:26 +0200

OK

I believe that the message in RFC5104 is quite clear.

/Ingemar
________________________________________
Från: Roni Even [[email-masked]]
Skickat: den 6 augusti 2010 11:02
Till: Ingemar Johansson S; 'Colin Perkins'
Kopia: [email-masked]; [email-masked]
Ämne: RE: [AVT] On the use of TMMBR

Ingemar,
As for your question

Roni