Protocol Overview TCP/IP Performance E-Mail HTTP (WWW) Remote Login File Transfer TCP UDP ITL IP ICMP ARP RARP (Auxiliary Services) ATM Ethernet, X.25, HDLC etc. 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 2 Connection Types in TCP/IP Resource Management Transport Layer Network Layer Data Link Layer and Physical Network TCP: Connection Oriented UDP: Connection-less Connection-less Depends on the network Local resources (mainly memory) Data Sender Data Receiver Network Resources Bandwidth usage Router queues the ternet, no explicit feedback from network to hosts (as opposed to Frame Relay, ATM). 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 3 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 4 Router Queues Smooth out traffic bursts Cannot control long-term overload Control Mechanisms Connection-Less traffic Packets representing overload are discarded Retransmissions should not take place Applications should adapt Connection-Oriented traffic Packets representing overload are also discarded Lost packets must be retransmitted Hosts must adjust sending rate\ 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 5 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 6
Sliding Window flow control Sliding Window cont. vented to control flow to slower devices (i.e. end-to-end Almost accidentally provides a cap on data flow rate TCP uses a sliding window mechanism for multiple purposes The window size is dynamically adjusted 1 2 3 M 1 2 3 M One Cycle Idle Time 1 2 3 M 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 7 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 8 Frame Transmission Time Depends on Frame Length Channel Bit Rate Frame Propagation Time Depends on Physical distance between stations Signal propagation speed 2x10 8 to 3x10 8 meters/second 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 9 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 10 Round Trip Time Combination of Frame Transmission times on intermediate links Frame propagation times on all links Queue wait times in all intermediate nodes Window Size and Throughput Maximum throughput is (window size)/rtt Actual throughput may of course be less. Bandwidth-Delay-Product BDP=RTT * (effective bandwidth) Measures the amount of data in the network at any given time. 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 11 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 12
practice UDP Header How is the sliding window mechanism used in TCP What dynamic adjustments are made to the window size What control do we have over performance parameters Starting with a quick TCP review... Source Port Length Destination Port Checksum 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 13 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 14 TCP Header TCP Connection Setup Source Port Destination Port Sequence Number Acknowledgement Number Three-Way Handshake Send SYN packet Wait for peer to return a SYN/ACK packet Acknowledge the SYN/ACK packet misc Flags Checksum Window (flow cntrl) Urgent Options 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 15 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 16 TCP Connection Termination Send a FIN packet Wait to receive acknowledgement of FIN TCP Data Exchange Sequence Numbers - Sliding Window Arbitrary initial setting Labels the first byte of the segment Acknowledgements dicate the next byte the receiver is looking for, all previous bytes have been received. 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 17 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 18
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 Sender Receiver TCP Sliding Window Operation snd.una snd.nxt snd.una +snd.wnd snd.wnd (local to the Sender) rcv.nxt rcv.nxt +rcv.wnd 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 19 rcv.wnd (Must tell the sender this value) 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 20 Slow Start Congestion Control 1 1 1 2 Idle Time Note: recent TCP amendments permit more than 1 initial segment 1 2 Idle Time 1 2 3 4 Window doubles in each cycle 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 21 Congestion Issues Slow Start - New Connection Set send window to n*mss (n <= 4) crease 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 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 22 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-) Congestion Issues cont... Slow Start - After retransmission Exponential slow-start up to 1/2 of the original window size crease the window by MSS for each send window ack ed without loss Linear increase in send window size 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 23 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 24
What can we control Vendors TCP implementation needs to follow most recent guidelines TCP window size is usually configurable; in some case the size auto-tunes. Users Control the TCP window For each application (rare; although some applications are capable of doing this) For the entire workstation (more likely) Additional Slides 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 25 Real Networks clude many different types of circuits Different speeds Some LAN, some Wide-Area connections Rely on routers to connect the different subnetworks Routers are not expected to have detailed knowledge about the traffic flows they are handling Network Knowledge and Lack Thereof 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 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 27 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 28 Network Knowledge and Lack Thereof 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 Routers 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?? 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 29 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 30
Applications 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 the ideal case 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 creases overall complexity Can provide a wide range of services really well 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 31 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 32 The case of the ternet 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 Performance Issues Long term crease 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 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 33 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 34 Application View Network attachment over which I dispatch my packets -- known termediate 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 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 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 35 2/13/06 Hans Kruse & Shawn Ostermann, Ohio University 36