Hi, I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that? I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research. Cheers, Michael
On 17 Apr 2012, at 08:16, Michael Welzl wrote:
I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that?
I had a Masters student look at it a few years ago, who had some problems making TFRC usable in practice: http://csperkins.org/research/thesis-msc-saurin.pdf Also, the TFWC work http://tfwc.hackerslab.eu/ points to various problems with TFRC. Colin
I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/
Dear Colin, we also worked on issues related to Saurin's thesis which can be found in a IEEE ICNP publication: L. De Cicco, S. Mascolo A Mismatch Controller for Implementing High-Speed Rate-based Transport Protocols in Proc of 17th IEEE International Conference on Network Protocols (ICNP '09), Princeton, NJ, USA , Oct. 13-16, 2009 http://c3lab.poliba.it/images/d/d9/Icnp09.pdf Cheers, Luca On Tue, Apr 17, 2012 at 12:07 PM, Colin Perkins <csp@csperkins.org> wrote:
On 17 Apr 2012, at 08:16, Michael Welzl wrote:
I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that?
I had a Masters student look at it a few years ago, who had some problems making TFRC usable in practice: http://csperkins.org/research/thesis-msc-saurin.pdf
Also, the TFWC work http://tfwc.hackerslab.eu/ points to various problems with TFRC.
Colin
I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi Michael, A colleague and I published a paper on bandwidth adaptive video streaming in the ICUMT 2011, where we used TFRC as a bandwidth estimation mechanism. It worked ok, (we simulated it using the ns2 built in implementation, with some minor changes), but getting it to work on top of RTCP/RTP was a lot of work; especially since the internet draft for TFRC over RTP has expired now. That is how I ended up in this mailing list. I have never compared TFRC with other equivalent mechanisms such as TMMBR though. -abheek
On Tue, Apr 17, 2012 at 12:07 PM, Colin Perkins <csp@csperkins.org> wrote:
On 17 Apr 2012, at 08:16, Michael Welzl wrote:
I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that?
On 2012-04-17 12:33, abheek saha wrote:
Hi Michael,
A colleague and I published a paper on bandwidth adaptive video streaming in the ICUMT 2011, where we used TFRC as a bandwidth estimation mechanism. It worked ok, (we simulated it using the ns2 built in implementation, with some minor changes), but getting it to work on top of RTCP/RTP was a lot of work; especially since the internet draft for TFRC over RTP has expired now. That is how I ended up in this mailing list. I have never compared TFRC with other equivalent mechanisms such as TMMBR though.
TMMBR is a mechanism to request a ceiling in the bit-rate from a given RTP sender. TFRC is an algorithm to determine a transmission rate, or actually when it is time to transmit the next packet. TMMBR is only setting the ceiling value and the sender is allowed to chose any under that ceiling. Moreover, the RTP receiver needs algorithm around TMMBR to make it work for rate control. Could you clarify how it would be possible to compared them? BR -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================
Well, I don't know much about TMMBR, so no doubt you are right. The point I was making was that __per se__ TFRC came across as a good predictor of available bandwidth; we never compared it against any other equivalent mechanisms, so I can't say whether it is the best of its class or what its strengths and weaknesses are relative to others of its class. We have started looking at the recent algorithm published by Harald and may have an opportunity to compare it against that of TFRC in our setup -best wishes, Abheek On Tue, Apr 17, 2012 at 6:59 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
TMMBR is a mechanism to request a ceiling in the bit-rate from a given RTP sender. TFRC is an algorithm to determine a transmission rate, or actually when it is time to transmit the next packet. TMMBR is only setting the ceiling value and the sender is allowed to chose any under that ceiling. Moreover, the RTP receiver needs algorithm around TMMBR to make it work for rate control.
Could you clarify how it would be possible to compared them?
BR -- Zahed
============================================ ANM ZAHEDUZZAMAN SARKER
Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================
Hi, We did some experiments comparing TFRC, playout delay reporting, TMMBR in a 3G environment. The experiments were done in ns2 where we implemented a 3G link and an interface to hookup a real encoder to pass video frames to and from ns2. The paper was published in a workshop co-located with INFOCOM. The main metric we used was PSNR. Both endpoints in this case were 3G endpoints and had different throughput in their cells. The link to the paper is: http://www.netlab.tkk.fi/~jo/papers/2009-04-movid-3g-rate-adapt.pdf On Tue, Apr 17, 2012 at 10:16, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,
I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that?
I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Thanks to you and all others who have answered my request! This is all very interesting, and just what I was looking for! Michael On Apr 17, 2012, at 9:31 PM, Varun Singh wrote:
Hi,
We did some experiments comparing TFRC, playout delay reporting, TMMBR in a 3G environment. The experiments were done in ns2 where we implemented a 3G link and an interface to hookup a real encoder to pass video frames to and from ns2. The paper was published in a workshop co-located with INFOCOM. The main metric we used was PSNR. Both endpoints in this case were 3G endpoints and had different throughput in their cells.
The link to the paper is: http://www.netlab.tkk.fi/~jo/papers/2009-04-movid-3g-rate-adapt.pdf
On Tue, Apr 17, 2012 at 10:16, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,
I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that?
I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
participants (6)
-
abheek saha -
Colin Perkins -
Luca De Cicco -
Michael Welzl -
Varun Singh -
Zaheduzzaman Sarker