analysis of internet transport service analysis of
play

Analysis of Internet Transport Service Analysis of Internet - PowerPoint PPT Presentation

University of Helsinki - Department of Computer Science Analysis of Internet Transport Service Analysis of Internet Transport Service Performance Performance with Active Queue Management with Active Queue Management in a QoS- -enabled


  1. University of Helsinki - Department of Computer Science Analysis of Internet Transport Service Analysis of Internet Transport Service Performance Performance with Active Queue Management with Active Queue Management in a QoS- -enabled Network enabled Network in a QoS Oriana Riva Oriana Riva oriana.riva@cs.Helsinki.FI

  2. Contents Contents TCP Congestion Control in the Internet Router queue management algorithms – Tail Drop discipline – Active Queue Management (AQM) • Goals • Random Early Detection (RED) Test Arrangements – Test Environment – Test Cases Test Results and Analysis Conclusions 12.6.2003 2 University of Helsinki - Department of Computer Science

  3. TCP Congestion Control in the Internet TCP Congestion Control in the Internet Internet has grown and TCP congestion control mechanisms are not sufficient to provide good service in all circumstances – Wired vs. Wireless – The Internet is evolving to support QoS Problem: There is a limit to how much control can be accomplished from the edges of the network A possible solution is an advanced form of router queue management such as Active Queue Management (RFC 2309) Current router algorithm employed in the Internet: Tail Drop 12.6.2003 3 University of Helsinki - Department of Computer Science

  4. Tail Drop buffer Tail Drop buffer Principle: – fix the maximum length for each queue, accept packets for the queue until the maximum length is reached, then drop subsequent incoming packets Advantages – easy to implement Disadvantages – Full Queues • Discriminate against bursty traffic and cause multiple packets to be dropped • Synchronization of sources – Lock-Out: a single connection or few flows manage to monopolize the available queue resources 12.6.2003 4 University of Helsinki - Department of Computer Science

  5. Active Queue Management (AQM) Active Queue Management (AQM) Based on a proactive approach: – drop packets before buffer becomes full – use the average queue length as congestion indicator Can provide the following advantages for responsive flows – Control the average queuing delay and reduce end-to-end latency – Guarantee more equity in resources utilization (fairness) – Reduce the number of packets dropped in routers – Provide greater capacity to absorb bursts without dropping packets – Avoid global synchronization of sources – Avoid Lock-Out behaviour The most famous example of AQM is the Random Early Detection (RED) algorithm 12.6.2003 5 University of Helsinki - Department of Computer Science

  6. RED - - Algorithm Algorithm RED Calculate the average queue size ( avg ) by a low pass filtering with weight w q , 0< w q <1 = − + avg ( 1 w )avg w q + n 1 q n q ist q ist =instantaneous queue length If avg<min th do nothing If avg>max th drop the packet Else drop (or mark) packet with probability: Dropping/Marking Probability, p' = − − p' max (avg min ) /(max min ) p th th th p=1 = − p p'/( 1 count·p') count =number of unmarked packets since the last time a packet was dropped or since avg exceeded min th avg max th min th 12.6.2003 6 University of Helsinki - Department of Computer Science

  7. Test Arrangements Test Arrangements Destination Source Last-hop Intermediate Router Router UDP 10Mbit/s 100Mbit/s 140 kbit/s bottleneck TCP Wireless Network Wired Network Simple scenario ( Simple scenario ( Each scenario is tested with 20 replications) – PC with Linux Operating System (kernel version 2.4.17) – Standard Linux TCP Implementation with SACK option (Timestamps: OFF) – The Intermediate Router employs Tail Drop with a huge buffer size – The Last-hop Router employs Tail Drop or RED without ECN – RED Parameters: buffer size=20kbytes, min th =5kbytes, max th =18kbytes, max p =0.1 – Metrics: Elapsed Time, Num Retx Packets, Fairness, etc.. 12.6.2003 7 University of Helsinki - Department of Computer Science

  8. Test Arrangements - - Test Environment Test Environment Test Arrangements The last-hop router implements a DiffServ (DS) PHB using HTB (Hierarchical Token Bucket) packet scheduler with two service classes Each service class employs Tail Drop or RED Queuing allocates bandwidth and buffer space: – Bandwidth: which packet to serve next (scheduling) – Buffer Space: which packet to drop next (buffer management) Traffic Traffic Classes Sources Tail Drop/RED HTB TCP Class TCP TCP UDP TCP Class Drop UDP UDP UDP Buffer Management Scheduling Buffer Management Scheduling 12.6.2003 8 University of Helsinki - Department of Computer Science

  9. Test Arrangements - - Test Case 1 Test Case 1 Test Arrangements Workload: 3 competing TCP flows 1 service class – bottleneck bandwidth =140kbit/s 2 TCP connections start simultaneously (data traffic sent=292kbytes) The third connection starts with a delay varying from 0 up to 7 seconds (data traffic sent= 46.7kbytes) TCP 1 TCP 1 bottleneck R R TCP 2 TCP 2 TCP 3 140kbit/s TCP 3 data sent = 292kbytes data sent= 46.7kbytes 12.6.2003 9 University of Helsinki - Department of Computer Science

  10. Test Arrangements - - Test Case 2 Test Case 2 Test Arrangements Workload: TCP and UDP traffic with DiffServ The UDP traffic starts later and has different duration 1. The UDP traffic lasts for the entire duration of the TCP transfer 2. The UDP traffic ends before the TCP connection ends Effects derived from the introduction of service differentiation: 1. Unique service class for TCP and UDP traffic (available bandwidth=140kbit/s) 2. Separate service classes for TCP traffic and higher-priority UDP traffic (class bandwidth=70kbit/s) bottleneck (140kbit/s) 70/140kbit/s TCP TCP R R UDP DS UDP 70/100kbit/s 12.6.2003 10 University of Helsinki - Department of Computer Science

  11. Results – – Test Case 1 Test Case 1 Results 3 competing TCP connections Results of the third connection for different starting points Elapsed Time Three-way Handshake Phase 25 5 Elaps.Time (sec) Hand.phase (sec) 23 RED RED 4 21 Tail Drop Tail Drop 19 3 17 15 2 13 11 1 9 7 0 0 2 4 5 5,5 0 2 4 5 5,5 starting time of the third flow (sec) starting time of the third flow (sec) Stable results and improved performance when RED is employed Tail Drop – Scenario after 2 seconds : the elapsed time doubles the RED’s one! 12.6.2003 11 University of Helsinki - Department of Computer Science

  12. Results – – Test Case 1 Test Case 1 Results 3 competing TCP connections – Elapsed Time of the 3rd flow Tail Drop RED Min 25% Percentile Min 25% Percentile Median 75% Percentile Median 75% Percentile Max Max Elapsed Time (sec) 45 45 Elapsed Time (sec) 40 40 35 35 30 30 25 25 20 20 1 5 15 1 0 10 5 5 0 0 0 2 4 5 5,5 0 2 4 5 5,5 starting time of the third flow(sec) starting time of the third flow (sec) Wide variation range Limited variation range 12.6.2003 12 University of Helsinki - Department of Computer Science

  13. Test Case 1 - - Lock Lock- -Out of Tail Drop Out of Tail Drop Test Case 1 Tail Drop: example from the scenario after 2 seconds The initial flows monopolize most of the bandwidth (phenomenon of Lock-Out) The exponential retransmit back-off rule doubles the retransmit timer when a retransmitted packet is lost 12.6.2003 13 University of Helsinki - Department of Computer Science

  14. Results - - Test Case 1 Test Case 1 Results 3 competing TCP flows Third flow’s data load is 4/25 of the initial flows’ data load RED Tail Drop - Elapsed Time RED - Elapsed Time guarantees to fastest flow slowest flow 3rd flow fastest flow slowest flow 3rd flow the third flow Elaps.Time(sec) Elaps. Time (sec) 40 40 30 30 improved and 20 20 stable 10 10 performance 0 0 0 2 4 5 5,5 0 2 4 5 5,5 starting time of the third flow (sec) RED drops starting time of the third flow (sec) RED - Retx Packets Tail Drop - Retx Packets packets in fastest flow slowest flow 3rd flow fastest flow slowest flow 3rd flow 15 proportion to 1 5 Num Retx Pkts Num Retx Pkts the amount of 10 1 0 bandwidth the 5 5 flow uses on 0 0 0 2 4 5 5,5 0 2 4 5 5,5 starting time of the third flow (sec) starting time of the third flow (sec) the output link 12.6.2003 14 University of Helsinki - Department of Computer Science

  15. Results - - Test Case 2 Test Case 2 Results Single TCP flow competing with UDP traffic lasting 5sec Num of Received UDP Pkts Elapsed Time of the TCP flow Tail Drop RED Tail Drop RED Tail Drop + DS RED + DS Tail Drop + DS RED + DS 300 26 Num of Recv Pkts 25,5 El.Time (sec) 250 25 200 24,5 150 24 100 23,5 50 23 0 2 7 1 2 16 18 0 2 7 1 2 1 6 18 starting time of the UDP flow (sec) starting time of the UDP flow (sec) 1 service class : – Tail Drop: unstable results for both TCP and UDP traffic – RED: performance close to the results with 2 service classes 2 service classes (Higher priority UDP traffic) – Tail Drop and RED achieve the same performance 12.6.2003 15 University of Helsinki - Department of Computer Science

  16. Test Case 2 - - Unfairness of Tail Drop Unfairness of Tail Drop Test Case 2 TCP traffic competing with UDP traffic of equal priority The performance changes by varying the starting point of the UDP traffic TCP El. Time=24.5s TCP El. Time=23.7s TCP El. Time=25.5s UDP Rec Pkts=127 UDP Rec Pkts=224 UDP Rec Pkts=181 UDP flow starts 12.6.2003 16 University of Helsinki - Department of Computer Science

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend