1 / 7

Faster Restart for TCP Friendly Rate Control (TFRC)

Faster Restart for TCP Friendly Rate Control (TFRC). draft-ietf-dccp-tfrc-faster-restart-06.txt E. Kohler, S. Floyd, and A. Sathiaseelan Nov 2008, DCCP Working Group. Faster Restart for TFRC. After an idle period of at least NFT (no feedback):

winifred-foster
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-06.txt E. Kohler, S. Floyd, and A. Sathiaseelan Nov 2008, DCCP Working Group

  2. Faster Restart for TFRC • After an idle period of at least NFT (no feedback): • The allowed sending rate is not reduced below *twice* the initial sending rate; • Quadruple sending rate each RTT up to old rate (decayed over time);

  3. Issues • RFC3448 had inherent problems with bursty applications in idle and data-limited periods. • Faster Restart was hence proposed for idle periods • Showed very good performance improvements during idle periods. • Simultaneously, RFC3448 was reopened. • More for data-limited periods. • RFC5348 mitigated the data-limited problem. • Good result of the Faster Restart study.

  4. Application Issues • Faster Restart no effect for continuous bulk applications: • e.g. Streaming media. • Thought to be useful for conversational class: • VoIP • Videoconferencing • Any other applications? • VoIP traffic is more data-limited, than idle (in low congestion). • VoIP traffic model: Exponential distribution, mean burst = 0.352s, mean idle = 0.65s. • Sriram & Whitt, Globecomm 1985. • Simulations show Faster Restart offers slight improvements compared RFC5348 for these parameters.

  5. Application Issues (contd.) • Simulations for a range of burst, idle parameters. • e.g. (1.0,1.5), (3.0,3.5), (5,5.5) • Results showed Faster Restart improved performance. • Do they represent any appropriate applications? • So, is Faster Restart really useful? • Need to explore other applications to see benefits • e.g. models for videoconferencing, motion compensation required.

  6. Network Issues • Results examining path change from high to low capacity: • Worst case scenario – where all flows reached encoding rates, went idle, path changes and then restarted. • e.g. 100 Mbps, 100 ms link, eight 512 kbps flows, went idle for 5 seconds, during that time the link changed to 1 Mbps. Flows then restart randomly. Packet droprate at router measured for 5 seconds. • 36% packet droprates for RFC5348 and 38% packet droprates for Faster Restart!! • But, is this bad?

  7. Status • Extensive simulations have been performed. • No changes have been made to the draft. • More work needs to be done: • Better application models required.

More Related