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

Agenda Background Thought Process MFRC Basics Next Steps

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

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

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

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

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

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

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?