1 / 6

Faster Restart for TCP Friendly Rate Control (TFRC)

Faster Restart for TCP Friendly Rate Control (TFRC). draft-ietf-dccp-tfrc-faster-restart-00.txt Slides: http://www.icir.org/floyd/talks/ Eddie Kohler, Sally Floyd IETF, August 2005 (Faster Restart used to be in: draft-ietf-dccp-tfrc-voip.). The Goal of Faster Restart:.

eatonl
Download Presentation

Faster Restart for TCP Friendly Rate Control (TFRC)

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. Faster Restart for TCP Friendly Rate Control (TFRC) draft-ietf-dccp-tfrc-faster-restart-00.txt Slides: http://www.icir.org/floyd/talks/ Eddie Kohler, Sally Floyd IETF, August 2005 (Faster Restart used to be in: draft-ietf-dccp-tfrc-voip.)

  2. The Goal of Faster Restart: • Current response to idle periods conservative: • Cut allowed rate in half every four idle RTTs. • Then slow-start. • Safe for network, bad for some applications: • Voice traffic with silence suppression. • Slow-start glitches every time new person talks? • Faster Restart insight: Path already validated. • More aggressive response than slow start OK after short idle periods.

  3. Initial Design: • Remember sustained rate (X_active_recv) recently supported by path. • After an idle period, "faster-start" up to X_active_recv. • Quadruple rate every RTT up to X_active_recv • If slow start took $n$ RTTs to recover X_active_recv, this takes $n/2$ RTTs • For long idle periods (>= 30 minutes), no faster restart; • for medium idle periods (10-30 minutes), faster restart to a fraction of X_active_recv

  4. Problems (from Sara Landstrom) • What about extremely short idle periods? • What about application-limited traffic? (Immediately before idle period, was sending slower than application allowed) • What about faster-restarting from an application-limited, but non-idle, state?

  5. Changes to Faster Restart: • Remember high sustained rate (X_active_recv) recently supported by path: • Move X_active_recv up on higher sustained rates. • Move X_active_recv down on congestion feedback. • Reduce effective X_active_recv as information becomes stale. • Always allow faster-restart up to X_active_recv.

  6. Comments from:draft-burness-dccp-interactive-apps-00.txt: • “In [6] fast restart is allowed inside 10 minutes at the prior rate, reducing to the normal 4 packets minimum by 30 minutes. We consider this time is too long for two reasons.” • Mobility. • Video, or audio on low capacity links. • “We propose a similar solution, but with a different timescale.”

More Related