1 / 23

Siemens contribution to „TCP over OBS“ - New Results -

Siemens contribution to „TCP over OBS“ - New Results -. PART 1 - One Client (User), FTP Download – Objective: Comparison with UCL Simulations. Simulation Scenario. " Standard " Values for Simulation Parameters.

lacy-reynolds
Download Presentation

Siemens contribution to „TCP over OBS“ - New Results -

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. Siemens contribution to „TCP over OBS“- New Results - NOBEL WP3 Meeting, Munich, June13-15, 2005

  2. PART 1- One Client (User), FTP Download –Objective: Comparison with UCL Simulations NOBEL WP3 Meeting, Munich, June13-15, 2005

  3. Simulation Scenario NOBEL WP3 Meeting, Munich, June13-15, 2005

  4. "Standard" Values for Simulation Parameters • Equal or similar to UCL simulations:FTP file transfer: - file size 20 MB (greedy application) for obtaining long lasting TCP connection - inter-request time 1000 secondsTCP: TCP Reno with receive buffer of 8760 Bytes (UCL: 82500 Bytes!)Segment Size: 1500 BytesCore bandwidth: OC192 (9.6 Gbit/s)Access bandwidth: DS1 (1.5 Mbit/s) • Different from UCL simulations:Core propagation time: 20 msEdge aggregation time: 100 ms (25 μs is too short, only 1 IP packet per burst!)Receive buffer size (8760 vs. 82500 Bytes) • Loss rates for OBS model: 0%, 1% and 5%Bursts are lost in the model using random selection NOBEL WP3 Meeting, Munich, June13-15, 2005

  5. Throughput Comparison: Lossless OBS Domain vs. OBS Domain with Burst Losses NOTE: Throughput is meant as the average number of bits successfully received or transmitted by the receiver or transmitter channel per unit time, in bits per second. In all slides, the throughput between Edge2 and Mux1 is measured. Blue: no loss Red: 1% loss Green: 5% Loss NOBEL WP3 Meeting, Munich, June13-15, 2005

  6. TCP Congestion Window Sizes no loss 1% loss 5% loss NOBEL WP3 Meeting, Munich, June13-15, 2005

  7. TCP Retransmission Timeout (RTO) Values no loss 1% loss 5% loss NOBEL WP3 Meeting, Munich, June13-15, 2005

  8. FTP Download Response Times NOBEL WP3 Meeting, Munich, June13-15, 2005

  9. TCP Performance in case of Fast Access (OC192) Blue: DS 1 im Access, 1% Loss Rate Red: OC 192 im Access, 1% Loss Rate Mean Download Response Times: DS1 Access: 699.41 sec. OC 192 Access: 652.12 sec. NOBEL WP3 Meeting, Munich, June13-15, 2005

  10. Effect of Propagation Delay (Distance in OBS Core Network) Blue: 20 ms Prop. Delay, 1% Loss Rate Red: no Prop. Delay, 1% Loss Rate Mean Download Response Times: 20 ms Delay: 699.41 sec. No Delay: 620.10 sec. NOBEL WP3 Meeting, Munich, June13-15, 2005

  11. Influence of Fast Retransmit / Fast Recovery (FRFR)(1% Loss Rate Scenario) with FRFR:mean download response time is 699.41 seconds without FRFR:download response time is 690.03 seconds NOBEL WP3 Meeting, Munich, June13-15, 2005

  12. Influence of Delayed Achnowledgement Mechanism (1% Loss Rate Scenario) Clock based mechanism (red line): TCP sends a dataless ACK if no data is sent for a maximum acknowledge-ment delay time interval (0.2 sec.); mean FTP download response time: 699.41 sec. Segment / clock based mechanism (blue line): Generates an ACK every other received segment, or every maximum acknowledgement delay time interval, if two segments are not received within this interval; mean FTP download response time: 1096.03 sec. Standard Setting is „Segment/ clock based“. NOBEL WP3 Meeting, Munich, June13-15, 2005

  13. Influence of Receive Buffer Size (Lossless Scenario) Blue: receive buffer is 8760 Bytes Red: receive buffer is 82500 Bytes (UCL setting) Mean Download Response Times: low receive buffer: 569.04 sec. high receive buffer: 128.36 sec. NOBEL WP3 Meeting, Munich, June13-15, 2005

  14. Influence of Receive Buffer Size (1% Loss Scenario) Blue: receive buffer is 8760 Bytes Red: receive buffer is 82500 Bytes (UCL setting) Mean Download Response Times: low receive buffer: 699.41 sec. high receive buffer: 273.86 sec. NOBEL WP3 Meeting, Munich, June13-15, 2005

  15. Annotations concerning receive buffer size(source: http://www.psc.edu/networking/projects/tcptune/) • The receive buffer is the size of the buffer holding received data before it is forwarded to the higher layers (e.g. application). Note that the advertized receiver window is the amount of space available in the receiver buffer (per TCP connection). • Without the support of TCP enhancement for large windows (RFC 1323), the buffer sizes that can be used by the application is limited to 64K Bytes; this is inadequate for today's high speed WANs. • Typically operating systems limit the amount of memory that can be used by an application for buffering network data. • The "Maximum Buffer Size" mentioned above sets a maximum limit for the buffers. In addition to this, most operating systems have a system-wide "default buffer size". Unless an application explicitly requests a specific buffer size, it gets a buffer of the default size. • If the default buffer size is not large enough, the application must set its send and receive socket buffer sizes (at both ends). NOBEL WP3 Meeting, Munich, June13-15, 2005

  16. PART 2- 300 Clients (Users), Heavy Browsing –Objective: Effects of a large number of multiplexed TCP connections NOBEL WP3 Meeting, Munich, June13-15, 2005

  17. Simulation Scenario Each subnet contains 60 workstations, i.e. traffic sources. NOBEL WP3 Meeting, Munich, June13-15, 2005

  18. "Standard" Values for Simulation Parameters • Application per workstation:Heavy Browsing:- page interarrival time: exponentailly distributed, mean is 60 seconds - page properties: 1 object with size 1000 Bytes, 5 images per pageTraffic of all subnets is multiplexed in Mux1 (no latency, no packet discard in Mux1) • Default Parameter Values:TCP Reno with receive buffer of 8760 BytesSegment Size: 1500 BytesCore bandwidth: OC192 (9.6 Gbit/s)Access bandwidth from subnet to Mux1: OC48 (2.45 Gbit/s)Access bandwidth inside subnet: DS1 (1.5 Mbit/s)Core propagation time: 20 msEdge aggregation time: 100 ms • Loss rates for OBS model: 0%, 1% and 5%Bursts are lost in the model using random selection NOBEL WP3 Meeting, Munich, June13-15, 2005

  19. Throughput Comparison: Lossless OBS Domain vs. OBS Domain with Burst Losses Blue: no loss Red: 1% loss Green: 5% Loss NOBEL WP3 Meeting, Munich, June13-15, 2005

  20. Effect of Propagation Delay (Distance in OBS Core Network) Blue: 20 ms Prop. Delay, 1% Loss Rate Red: no Prop. Delay, 1% Loss Rate NOBEL WP3 Meeting, Munich, June13-15, 2005

  21. Influence of Delayed Achnowledgement Mechanism (1% Loss Rate Scenario) Blue: segment / clock based mechanism Red: clock based mechanism only NOBEL WP3 Meeting, Munich, June13-15, 2005

  22. Influence of Receive Buffer Size (1% Loss Scenario) low receive buffer (8760 Bytes) EXACTLY THE SAME RESULTS!(same is true in case of lossless scenario) Advertized receiver window does not play any role here. TCP Window is controlled by congestion window size. high receive buffer (82500 Bytes) NOBEL WP3 Meeting, Munich, June13-15, 2005

  23. Characteristics of Simulated Browser Traffic Client Side Server Side NOBEL WP3 Meeting, Munich, June13-15, 2005

More Related