1 / 9

Media Friendly Rate Control (MFRC)

This document presents the draft for Media Friendly Rate Control (MFRC), developed by Tom Phelan from Sonus Networks. It delves into the challenges of existing transmission control protocols like TFRC and proposes a more flexible rate control mechanism for media applications. MFRC encourages smooth rate adjustments based on real-time network conditions, facilitating improved video and audio streaming experiences. The document aims to spark discussions on potential solutions and outlines the basic operational phases of MFRC, including uncongested, congested, and recovery phases, with next steps for collaborative input.

tracen
Télécharger la présentation

Media Friendly Rate Control (MFRC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Media Friendly Rate Control (MFRC) draft-phelan-mfrc-00.txt Tom Phelan – Sonus Networks tphelan@sonusnet.com 6-August-2004 http://www.phelan-4.com/dccp/DCCP-MFRC-SanDiego.ppt

  2. Agenda • Background • Thought Process • MFRC Basics • Next Steps

  3. Background • Mailing list discussions show difficulties with TFRC and interactive media • You can put the square peg in the round hole, but something less brutish would be nice • Draft is a thought-experiment exploration of possible solution areas • Intention is to stimulate discussion • Could be first step on (long) path to solution

  4. Thought Process • TFRC congestion reaction pretty much OK • Smooth rate reduction, cautious rate increase • Biggest problems involve TFRC “congestion avoidance” mechanisms • Slow start, restart, rate variation restrictions • Necessary for file transfer apps

  5. Thought Process • Media apps today have other congestion avoidance mechanisms • Client/server pick max rate based on knowledge of access link speeds • Simple, works most of the time • Most of the time, TFRC congestion avoidance redundant • So, why not let media apps guess at non-congesting rate, then react if the guess is wrong? • That’s MFRC

  6. MFRC Basics • Three operational phases • Uncongested phase: • Connections start here • Free variation of transmit rate up to maximum set at connection start • Yah, issues here  • Exit to congested phase with packet loss

  7. MFRC Basics • Congested phase: • Halve allowed rate for each RTT with packet loss • No allowed rate increases • Exit to recovery phase after congestion dissipates – a number of RTTs with no packet loss

  8. MFRC Basics • Recovery phase: • Allowed rate variations based on TFRC • Return to uncongested phase when TFRC allowed rate equals connection max rate

  9. Next Steps • Mailing list discussion stimulated new ideas • Restart bigger problem than slow start • Byte rate better than packet rate • Better to allow rate variations in all phases • Simulate! – Anyone willing to help? • Where’s the home for this work? • dccp, tsvwg, avt, something else?

More Related