1 / 11

Using Jitter As A Predictor Of Congestion

Using Jitter As A Predictor Of Congestion. Logan Kennelly. Motivations. Real-Time Streams Codecs avoid congestion effects Don’t respond to congestion Non-elastic applications Could reduce payload Could reduce overhead. Goals. Detect congestion… “In-band” Utilize data from the media

talon-holloway
Télécharger la présentation

Using Jitter As A Predictor Of Congestion

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. Using Jitter As A Predictor Of Congestion Logan Kennelly

  2. Motivations • Real-Time Streams • Codecs avoid congestion effects • Don’t respond to congestion • Non-elastic applications • Could reduce payload • Could reduce overhead

  3. Goals • Detect congestion… • “In-band” • Utilize data from the media • Before it occurs • Predict congestion before losses

  4. Existing Methodologies • TCP-Like Congestion Control[1] • Responds to losses, assumes elastic application • PathLoad[2]/PathMon[3] • Bandwidth estimation by packet trains • Explicit Congestion Notification[4] • Probably best, but not end-to-end

  5. On The Use Of Jitter • delaytotal = delaytransmission + delayprocessing + delayqueuing • Increased congestion -> increased queuing delay • For fixed-size packets, transmission and processing delays should be fixed • Thus, a change in total delay could be interpreted as congestion

  6. Assumptions • Bandwidth available, only short-term congestion • Fixed route • Varying path characteristics can influence jitter • Fixed-size stream packets

  7. Real-time Transport Protocol[5] • Timestamps every sent packet • Easily calculate jitter: (tri - tri - 1) - (tsi - tsi - 1) • Includes provisions for stream reports • Detect congestion at receiver • Note: Current work doesn’t report back

  8. Methodology • End hosts • Single sender/receiver pair • Data rate is 9.3 kB/s • Comparable to a real-time audio stream including overhead • Sender sends at constant 30 ms intervals • Receiver records the jitter • I process the data after simulation

  9. Methodology • ns-2 Network • Five routers • Competing Pareto-distributed traffic • 500 ms burst intervals • One bottleneck

  10. Preliminary Results • Jitter appears to be merely an acceptable predictor • Measurements for this network appear to be mostly random • Haven’t quantitatively tested for randomness • Brief increase in jitter just before packet loss event • Also increases on non-loss events

  11. References [1] M. Allman, V. Paxson, and W. Stevens. TCP congestion control, April 1999. Status: PROPOSED STANDARD. [2] M. Jain and C. Dovrolis. Pathload: A measurement tool for end-to-end available bandwidth. In 3rd Passive and Active Measurements Workshop, March 2002. [3] D. Kiwior, J. Kingston, and A. Spratt. Pathmon, a methodology for determining available bandwidth over an unknown network. In Advances in Wired and Wireless Communication, pages 27–30, April 2004. [4] K. Ramakrishnan, S. Floyd, and D. Black. RFC 3168: The addition of explicit congestion notification (ECN) to IP, September 2001. Status: PROPOSED STANDARD. [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A transport protocol for real-time applications, July 2003. Status: STANDARD.

More Related