1 / 42

TCP/IP Performance

TCP/IP Performance. COMT 429. Protocol Overview. E-Mail HTTP (WWW) Remote Login File Transfer. TCP UDP. IP ICMP ARP RARP (Auxiliary Services). ATM. Ethernet, X.25, HDLC etc. Connection Types in TCP/IP.

Download Presentation

TCP/IP Performance

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/IP Performance COMT 429

  2. Protocol Overview E-Mail HTTP (WWW) Remote Login File Transfer TCP UDP IP ICMP ARP RARP (Auxiliary Services) ATM Ethernet, X.25, HDLC etc.

  3. Connection Types in TCP/IP Transport Layer TCP: Connection Oriented UDP: Connection-less Connection-less Network Layer Data Link Layer and Physical Network Depends on the network

  4. Include many different types of circuits Different speeds Some LAN, some Wide-Area connections Rely on routers to connect the different sub-networks Routers are not expected to have detailed knowledge about the traffic flows they are handling Real Networks

  5. End Systems Know the applications they are running Often know the network capacity they would like to have Do not know the actual network capacity available Do not know the “competition”, i.e. other network users’ traffic Network Knowledge and Lack Thereof

  6. Routers Know the capacity of the links they are attached to Do not know much about the network farther away from them Do not know the complete path taken by the packets handled in the router Do not know (from the network traffic itself) what the applications’ needs are Network Knowledge and Lack Thereof

  7. Must cope with packet flows that may exceed the available capacity on their outbound route Short-term this indicates randomness in the traffic and we need to deal with it If the overload persists long-term we call it congestion, and we would like for it to go away Routers use queues to handle the short-term variations Long-term overload?? Routers

  8. Should and often can adapt to the available capacity Should be fair in their use of resources, or Should identify themselves as high-capacity users (and compensate the network operator accordingly) Need information about the network and the capacity is can deliver Applications

  9. Use a control protocol to communicate this information between applications and “the network” Standard procedure in circuit switched and virtual circuit networks Telephone network Frame Relay and ATM Increases overall complexity Can provide a wide range of services really well In the ideal case

  10. Successful because a transparent network encourages application development and deployment Because the network elements are simple Reasonably low complexity Great flexibility Not much capability to communicate network information to applications The case of the Internet

  11. Long term Increase complexity and add QoS protocol layers Throw capacity at the network faster than applications require it (good luck...) Short term Implicit communication of congestion in the TCP protocol Network performs many different functions, some better than others Performance Issues

  12. Network attachment over which I dispatch my packets -- known Intermediate network Contains many links and queues Application sees an overall “latency”, or delay between packet dispatch and receipt More precisely, applications can discover Round Trip Times Application View

  13. Sliding Window … 1 2 3 M … … 1 2 3 M 1 2 3 M Idle Time One “Cycle”

  14. In practice • How is the sliding window mechanism used in TCP • What control do we have over performance parameters • Starting with a quick TCP review...

  15. UDP Header Source Port Destination Port Checksum Length

  16. TCP Header Source Port Destination Port Sequence Number Acknowledgement Number misc Flags Window (flow cntrl) Checksum Urgent Options

  17. TCP Connection Setup • “Three-Way Handshake” • Send SYN packet • Wait for peer to return a SYN/ACK packet • Acknowledge the SYN/ACK packet

  18. TCP Connection Termination • Send a FIN packet • Wait to receive acknowledgement of FIN

  19. TCP Data Exchange • Sequence Numbers - Sliding Window • Arbitrary initial setting • Labels the first byte of the segment • Acknowledgements • Indicate the next byte the receiver is looking for, all previous bytes have been received.

  20. TCP Segment Size • Originally Unlimited • IP fragments segments that are too large • Turned out to be very inefficient • SYN packet can carry the MSS (Maximum Segment Size) option • Must be approved in the SYN/ACK • Default used if the option is not present

  21. TCP Sliding Window Operation Sender snd.una +snd.wnd snd.una snd.nxt snd.wnd (local to the Sender) Receiver rcv.nxt +rcv.wnd rcv.nxt rcv.wnd (Must tell the sender this value)

  22. Slow Start Congestion Control 1 1 2 1 1 2 1 2 3 4 Idle Time Idle Time Window doubles in each “cycle” Note: recent TCP amendments permit more than 1 initial segment

  23. The Congestion Collapse Problem • Original TCP specs used the window for flow control, and retransmission after 2 round trip times • Congestion of a link causes the timers to “go off” before an ack can be returned • The network goes into steady state congestion where every segment is transmitted about three times

  24. Congestion Issues • Slow Start - New Connection • Set send window to n*MSS (n <= 4) • Increase the window by MSS for each ack received • Exponential increase in send window size • What is the limit? • Window size reached before full utilization • Path is overloaded and an intermediate router discards one or more packets

  25. Congestion Issues cont... • Packet loss • may occur due to actual errors or congestion • TCP equates loss with congestion • Congestion Avoidance, Timer Back-Off • Reduce send window to 1/2 of previous size for each retransmit (exponential back-off) • After a segment is retransmitted, set the new RTO timer for that segment to 2*RTO, up to a hard upper bound (2*MSL, Maximum Segment Life)(RTO = Retransmit Time-Out)

  26. Congestion Issues cont... • Slow Start - After retransmission • Exponential slow-start up to 1/2 of the original window size • Increase the window by MSS for each send window ack’ed without loss • Linear increase in send window size

  27. What can we control • Vendors • TCP implementation needs to follow most recent guidelines • TCP window size should be configurable • Users • Control the TCP window • For each application (rare) • For the entire workstation (more likely)

  28. In In In In Out Out Out Out Tuning, cont. • Network Administrator • Router Queues

  29. Optional Slides on TCP window operation

  30. Example ... Sender 5001 1001 2001 2501 Available window for further sends Next segment to send Sent but no ack received yet Receiver 5001 1001 1501 Available receive window space Received and acked; not yet picked up by client

  31. Segment Dispatch • Dispatch segment to IP • Set RTO (Retransmit Time Out) timer • Proportional to the Round Trip Time (RTT) Sender 5001 1001 2001 2501 Available window for further sends Next segment to send Sent but no ack received yet

  32. Segment Receipt withPickup Receiver • Send Ack segment with Ack=2001 • Window = 4000 5001 6001 1001 1501 2001 Available receive window space Received and picked up by client

  33. Segment Receipt w/oPickup Receiver • Send Ack packet with Ack = 2001 • Window = 3500 5001 5501 1001 1501 2001 Available receive window space Received but not picked up by client Received and picked up by client

  34. Acknowledgement Receipt • Seg received with Ack=2001, Win=3500 • Left window edge to 2001 • Right window edge to 5501 Sender before 5001 1001 2001 2501 after 5001 5501 2001 2501

  35. Segment Receipt AfterSegment Loss Receiver • Send a “duplicate” acknowledgement • Send Ack packet with Ack = 2001 • Window = 3500 5001 5501 1001 1501 2001 Last segment received Missing segment Received but not picked up by client Received and picked up by client

  36. Retransmission • Highest Ack Number received is 2001 • Duplicate Ack=2001 may have been received • RTO timer for segment 2001 expires and 2001 is retransmitted • Trigger congestion avoidance algorithm • We really want to avoid this because RTO is large Sender 5001 5501 2001 2501

  37. Retransmit Timing andWindow Size - Single Error • BDP (Bandwidth Delay Product) • Ethernet: 1ms * 10Mbps = 1250 bytes • Satcom T1: 500ms * 1.5Mbps = 94 kbytes • Assume window size = BDP • RTO > 2*RTT • “Recovery Ack” after retransmit needs 1 RTT • Channel idles for length of RTO (“drained pipe”) 5000 5501 2001 2501

  38. Retransmission TimerImplementation • Running estimate (based on Acks) of • Average RTT • RTT variance factor • Exclude retransmissions • Set RTO to RTT times RTT variance factor (with a hard upper bound) • Around 2 RTT for lightly loaded links • As high as 16 RTT for congested links

  39. Window Scaling • 16 bit window field in the TCP header allows a maximum of 64 kbytes for the window. • RFC 1323 defines the window scaling option: • Syn segment suggests a “scaling” factor • Ack/Syn approves • All window advertisements are scaled by that factor prior to use in TCP

  40. Window Scaling cont... • Large windows cause an adjunct problem: sequence number reuse • RFC 1323 limits the window to about 1Gbyte to fit within the sequence number space • OC-12 will use all sequence numbers in about 28 sec. • Segements can “live” in the network for 120 sec

  41. Fast Retransmit Sender • Duplicate Ack=2001 have been received • Re-send segment 2001 before RTO expires • “Guess” that 2001 was lost • Wait for >=3 dup acks (segements could just have arrived out-of-order) • Enter congestion avoidance with allowance for duplicate acks 2001 2501 5000 5501

  42. Selective Acknowledgement Receiver • Enabled during Syn and Syn/Ack • Receiver send segment with • Ack = 2001, Window = 3500 • SACK option: block start=2501, end=2600 5000 5501 1001 1501 2001 2501 2601 Last segment received Missing Segment

More Related