1 / 19

TCP-LP: A Distributed Algorithm for Low Priority Data Transfer

TCP-LP: A Distributed Algorithm for Low Priority Data Transfer. Aleksandar Kuzmanovic, Edward W. Knightly Department of Electrical and Computer Engineering Rice University. IEEE INFOCOM 2003. Presented by Ryan. Introduction. Service prioritization among different traffic classes

amanda-dominguez
Télécharger la présentation

TCP-LP: A Distributed Algorithm for Low Priority Data Transfer

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. TCP-LP: A Distributed Algorithm for Low Priority Data Transfer Aleksandar Kuzmanovic, Edward W. Knightly Department of Electrical and Computer Engineering Rice University IEEE INFOCOM 2003 Presented by Ryan

  2. Introduction • Service prioritization among different traffic classes • E.g. better than best-effort (real-time service) • Not easy to deploy in the current Internet • TCP-LP (Low Priority) • An end-point protocol achieving two-class service prioritization without any support from the network

  3. Introduction • Objective of TCP-LP • Utilizing available bandwidth in a TCP transparent fashion • Fair sharing the excess bandwidth among multiple TCP-LP flows (TCP-like fair share) • Application of TCP-LP • Background file transfer • Probing available bandwidth

  4. Reference Model • Two class hierarchical scheduling model • High-priority VS Low-priority class • Strict priority service

  5. TCP-LP Protocol • An end-point congestion control algorithm • Early Congestion Indication • Congestion Avoidance Policy

  6. TCP-LPEarly Congestion Indication • One-way packet delays as early indicators • Smoothed one-way delay (weighted moving average) • Early congestion indication condition • d – measured one-way delay, γ- delay smoothing parameter, δ- delay threshold

  7. TCP-LPCongestion Avoidance Policy • Receipt of first early congestion indication •  halving the congestion window •  entering an inference phase • During the inference phase • Without increasing the congestion window • If receiving another indication •  setting the congestion window to 1

  8. TCP-LPCongestion Avoidance Policy • After the expiration of the inference phase •  increasing the congestion window by 1 per RTT (like TCP) Early Congestion Induction

  9. Parameter Settings • Delay Smoothing, γ= 1/8 (typical value for computing the smoothed RTT for TCP) • Delay Threshold, δ= 0.15 • Inference Phase Time-out, itt = 3*RTT

  10. Simulation • Run on NS2 (each run lasts 1000s) • Topology • Bottleneck link – 1.5Mb/s or 10Mb/s with delay 20ms • Other access links – 100Mb/s with delay 2ms

  11. Simulation Results • FTP and Reverse Background Traffic • First Row (excess capacity not available) • 2 simultaneous FTP downloads • Second Row (excess capacity available) • 2 simultaneous FTP downloads • 10 TCP flows in the reverse direction

  12. Simulation Results • Square-wave Background Traffic • 1 TCP/TCP-LP flow

  13. Simulation Results • 10 TCP/TCP-LP flows

  14. Simulation Results • HTTP Background Traffic • Web traffic between Node 0 and 1 • FTP connection in the same direction

  15. Simulation • Multiple Bottlenecks Topology 1 • Links 0-1, 1-2 and 2-3 with capacity of 1.5Mb/s • Others with capacity of 100Mb/s

  16. Simulation Results

  17. Simulation • Multiple Bottleneck Topology 2 • Links capacity – same as Topology 1

  18. Simulation Results

  19. Conclusion • TCP-LP achieves low-priority service without the support of the network • Simulations results support its functions • Experiments on the Internet should be performed to validate its performance

More Related