1 / 66

TCP and UDP

TCP and UDP. The Internet Transport Layer. Two transport layer protocols supported by the Internet: Reliable: The Transport Control Protocol (TCP) Unreliable The Unreliable Datagram Protocol (UDP). UDP. UDP is an unreliable transport protocol that can be used in the Internet

scarlet-webster
Télécharger la présentation

TCP and UDP

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 and UDP

  2. The Internet Transport Layer • Two transport layer protocols supported by the Internet: • Reliable: • The Transport Control Protocol (TCP) • Unreliable • The Unreliable Datagram Protocol (UDP)

  3. UDP • UDP is an unreliable transport protocol that can be used in the Internet • UDP does not provide: • connection management • flow or error control • guaranteed in-order packet delivery • UDP is almost a “null” transport layer

  4. Why UDP? • No connection needs to be set up • Throughput may be higher because UDP packets are easier to process, especially at the source • The user doesn’t care if the data is transmitted reliably • The user wants to implement his or her own transport protocol

  5. UDP Frame Format 32 bits Source Port Destination Port UDP length UDP checksum (optional) Data

  6. Sender: treat segment contents as sequence of 16-bit integers checksum: 1’s complement of (1’s complement sum of segment contents) sender puts checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later …. UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment

  7. Internet Checksum Example • Note • When adding numbers, a carryout from the most significant bit needs to be added to the result • Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Wraparound the carry sum Checksum (complement)

  8. TCP • TCP provides the end-to-end reliable connection that IP alone cannot support • The protocol • Frame format • Connection management • Retransmission • Flow control • Congestion control

  9. TCP Frame Format 32 bits Source Port Destination Port Sequence Number Acknowledgement number HL U R G A C K P S H R S T S Y N F I N Window Size Checksum Urgent Pointer Options (0 or more 32-bit words) Data

  10. TCP Frame Fields • Source & Destination Ports • 16 bit port identifiers for each packet • Sequence number • The packet’s unique sequence ID • Acknowledgement number • The sequence number of the next packet expected by the receiver

  11. TCP Frame Fields (cont’d) • Window size • Specifies how many bytes may be sent after the first acknowledged byte • Checksum • Checksums the TCP header and IP address fields • Urgent Pointer • Points to urgent data in the TCP data field

  12. TCP Frame Fields (cont’d) • Header bits • URG = Urgent pointer field in use • ACK = Indicates whether frame contains acknowledgement • PSH = Data has been “pushed”. It should be delivered to higher layers right away. • RST = Indicates that the connection should be reset • SYN = Used to establish connections • FIN = Used to release a connection

  13. TCP Connection Establishment • Three-way Handshake Host A Host B SYN (seq=x) SYN (seq=y, ACK=x+1) SYN (seq=x+1, ACK=y+1)

  14. TCP Connection Tear-down • Two double handshakes: Host A Host B FIN (seq=x) ACK (ACK=x+1) A->B torn down FIN (seq=y) ACK (ACK=y+1) B->A torn down

  15. TCP Retransmission • When a packet remains unacknowledged for a period of time, TCP assumes it is lost and retransmits it • TCP tries to calculate the round trip time (RTT) for a packet and its acknowledgement • From the RTT, TCP can guess how long it should wait before timing out

  16. Round Trip Time (RTT) Time for data to arrive Network Time for ACK to return RTT = Time for packet to arrive at destination + Time for ACK to return from destination

  17. 2K SEQ=0 RTT Calculation Sender Receiver 0.9 sec RTT ACK = 2048 2.2 sec RTT = 2.2 sec - 0.9 sec. = 1.3 sec

  18. Smoothing the RTT measurement • First, we must smooth the round trip time due to variations in delay within the network: SRTT = a SRTT + (1-a) RTTarriving ACK • The smoothed round trip time (SRTT) weights previously received RTTs by the a parameter • a is typically equal to 0.875

  19. Retransmission Timeout Interval (RTO) • The timeout value is then calculated by multiplying the smoothed RTT by some factor (greater than 1) called b Timeout = b* SRTT • This coefficient of b is included to allow for some variation in the round trip times.

  20. Example Initial SRTT = 1.50 a = 0.875, b = 4.0 RTT Meas. SRTT Timeout 1.5 s = 1.50 = b´1.50 = 6.00 1.0 s = 1.50´a + 1.0´(1- a) = 1.44 = b´1.44 = 5.76 2.2 s = 1.44´a + 2.2´(1- a) = 1.54 = b´1.54 = 6.16 1.0 s = 1.54´a + 1.0´(1- a) = 1.47 = b´1.47 = 5.88 0.8 s = 1.47´a + 0.8´(1- a) = 1.39 = b´1.39 = 5.56 3.1 s 2.0 s

  21. 2K 2K SEQ=0 SEQ=0 Problem with RTT Calculation Sender Receiver Sender Timeout RTT? ACK = 2048 RTT?

  22. Karn’s Algorithm • Retransmission ambiguity • Measure RTT from original data segment • Measure RTT from most recent segment • Either way there is a problem in RTT estimate • One solution • Never update RTT measurements based on acknowledgements from retransmitted packets • Problem: Sudden change in RTT can cause system never to update RTT • Primary path failure leads to a slower secondary path

  23. Karn’s algorithm • Use back-off as part of RTT computation • Whenever packet loss, RTO is increased by a factor • Use this increased RTO as RTO estimate for the next segment (not from SRTT) • Only after an acknowledgment received for a successful transmission is the timer set to new RTT obtained from SRTT

  24. Another Problem with RTT Calculation • RTT measurements can sometimes fluctuate severely • smoothed RTT (SRTT) is not a good reflection of round-trip time in these cases • Solution: Use Jacobson/Karels algorithm: Error =RTT - SRTT SRTT ==SRTT +(a ´ Error) Dev ==Dev + h(|Error| - Dev) Timeout = SRTT+ (b ´ Dev)

  25. Jacobson/Karels AlgorithmExample Error = RTT - SRTT SRTT = SRTT + (a ´ Error) Dev = Dev + [d ´ (|Error| - Dev)] Timeout = SRTT + (b ´ Dev) Initial SRTT = 1.50, Dev = 0 a = 0.125, d = 0.25, b = 4.0 RTT Meas. Error SRTT Dev. Timeout 1.5 s =0.0 =1.50 = 0.00 = 1.50 1.0 s =-0.50 =1.44 =0.13 =1.94 2.2 s = +0.76 = 1.54 = 0.28 = 2.67 1.0 s = -0.54 = 1.47 = 0.35 = 2.85 0.8 s = -0.67 = 1.39 = 0.43 = 3.09 3.1 s 2.0 s

  26. Example RTT computation

  27. TCP Flow Control • TCP uses a modified version of the sliding window • In acknowledgements, TCP uses the “Window size” field to tell the sender how many bytes it may transmit • TCP uses bytes, not packets, as sequence numbers

  28. TCP Flow Control (cont’d) Important information in TCP/IP packet headers Number of bytes in packet (N) Sequence number of first data byte in packet (SEQ) N SEQ Send ACK bit set Sequence number of next expected byte (ACK) Window size at the receiver (WIN) ACK WIN Recv Contained in TCP header Contained in IP header

  29. Example TCP session (1)remus:$ tcpdump -S host scullyKernel filter, protocol ALL, datagram packet sockettcpdump: listening on all devices 15:15:22.152339 eth0 > remus.4706 > scully.echo: S 1264296504:1264296504(0) win 32120 <mss 1460,sack OK,timestamp 71253512 0,nop,wscale 0> 15:15:22.153865 eth0 < scully.echo > remus.4706: S 875676030:875676030(0) ack 1264296505 win 8760 <mss 1460>15:15:22.153912 eth0 > remus.4706 > scully.echo: . 1264296505:1264296505(0) ack 875676031 win 32120 remus: telnet scully 7 A <return> A

  30. Example TCP session Timestamp Source IP/port Dest IP/port Packet 1: 15:15:22.152339 eth0 > remus.4706 > scully.echo: S 1264296504:1264296504(0) win 32120 <mss 1460,sackOK,timestamp 71253512 0,nop,wscale 0> (DF) Flags Packet 2: 15:15:22.153865 eth0 < scully.echo > remus.4706: S 875676030:875676030(0) ack 1264296505 win 8760 <mss 1460) Options Packet 3: 15:15:22.153912 eth0 > remus.4706 > scully.echo: . 1264296505:1264296505(0) ack 875676031 win 32120 Window Start Sequence Number End Sequence Number Acknowledgement Number

  31. TCP data transfer Packet 4:15:15:28.591716 eth0 > remus.4706 > scully.echo: P 1264296505:1264296508(3) ack 875676031 win 32120 data Packet 5:15:15:28.593255 eth0 < scully.echo > remus.4706: P 875676031:875676034(3) ack 1264296508 win 8760 # bytes

  32. 2K SEQ=0 2K 2K SEQ=2048 1K SEQ=4096 2K 1K 2K TCP Flow Control (cont’d) Sender Receiver Receiver’s buffer Application does a 2K write 0 4K Empty ACK = 2048 WIN = 2048 Application does a 3K write Full Sender is blocked Application reads 2K ACK = 4096 WIN = 0 ACK = 4096 WIN = 2048 Sender may send up to 2K

  33. TCP Flow Control (cont’d) Piggybacking: Allows more efficient bidirectional communication Data from A to B ACK for data from B to A N SEQ ACK WIN A B N SEQ ACK WIN Data from B to A ACK for data from A to B

  34. TCP Congestion Control • Recall: Network layer is responsible for congestion control • However, TCP/IP blurs the distinction • In TCP/IP: • the network layer (IP) simply handles routing and packet forwarding • congestion control is done end-to-end by TCP

  35. Self-Clocking Model Bottleneck link Pr Fast link Pb 1. Send Burst 2. Receive data packet 5. Send a data packet Data Receiver Sender Acks 4. Receive Acknowledgement 3. Send Acknowledgement Ab Ar Ar Given: Pb = Pr = Ar =Ab =Ar (in units of time) Sending a packet on each ACK keeps the bottleneck link busy

  36. one router, finite buffers sender retransmission of lost packet Changing bottleneck bandwidth Host A lout lin : original data l'in : original data, plus retransmitted data Host B finite shared output link buffers

  37. TCP Congestion Control • Goal: achieve self-clocking state • Even if don’t know bandwidth of bottleneck • Bottleneck may change over time • Two phases to keep bottleneck busy: • Slow-start ramps up to the bottleneck limit • Packet loss signals we passed bandwidth of bottleneck • Congestion Avoidance tries to maintain self clocking mode once established

  38. TCP Congestion Window • TCP introduces a second window, called the “congestion window” • This window maintains TCP’s best estimate of amount of outstanding data to allow in the network to achieve self-clocking

  39. TCP Congestion Window • To determine how many bytes it may send, the sender takes the minimum of the receiver window and the congestion window • Example: • If the receiver window says the sender can transmit 8K, but the congestion window is only 4K, then the sender may only transmit 4K • If the congestion window is 8K but the receiver window says the sender can transmit 4K, then the sender may only transmit 4K

  40. TCP Slow Start Phase • TCP defines the “maximum segment size” as the maximum size a TCP packet can be (including header) • TCP Slow Start: • Congestion window starts small, at 1 segment size • Each time a transmitted segment is acknowledged, the congestion window is increased by one maximum segment size • On each ack, cwnd=cwnd +1

  41. TCP Slow Start (cont’d) Congestion Window Size Event 1K A sends 1 segment to B B ACKs the segment 2K A sends 2 segments to B B ACKs both segments 4K A sends 4 segments to B B ACKs all four segments 8K A sends 8 segments to B B ACKs all eight segments 16K … and so on

  42. TCP Slow Start (cont’d) • Congestion window size grows exponentially (i.e. it keeps on doubling) • Packet losses indicate congestion • Packet losses are determined by using timers at the sender • When a timeout occurs, the congestion window is reduced to one maximum segment size and everything starts over

  43. When connection begins, increase rate exponentially until first loss event: double CongWin every RTT done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast time TCP Slow Start Host A Host B one segment RTT two segments four segments

  44. TCP Slow Start (cont’d) Timed out Transmissions Congestion window Transmission Number 1 Maximum Segment Size

  45. TCP Slow Start (cont’d) • TCP Slow Start by itself is inefficient • Although the congestion window builds exponentially, it drops to 1 segment size every time a packet times out • This leads to low throughput

  46. TCP Linear Increase Threshold • Establish a threshold at which the rate increase is linear instead of exponential to improve efficiency • Algorithm: • Start the threshold at 64K (ssthresh) • Slow start • Once the threshold is passed, only increase the congestion window size by 1 segment size for each congestion window of data transmitted • For each ack received, cwnd = cwnd + (mss*mss)/cwnd • If a timeout occurs, reset the congestion window size to 1 segment and set threshold to max(2*mss,1/2 of MIN(sliding window, congestion window))

  47. TCP Linear Increase Threshold Phase Example: Maximum segment size = 1K Assume SSthresh=32K Timeout occurs when MIN(sliding window, congestion window) = 40K Congestion window Thresholds 40K 32K 20K 1K Transmission Number

  48. TCP Fast Retransmit • Another enhancement to TCP congestion control • Idea: When sender sees 3 duplicate ACKs, it assumes something went wrong • The packet is immediately retransmitted instead of waiting for it to timeout • Why? • Note that acks sent by the receiver when it receives a packet • Dup ack implies something is getting through • Better than time out

  49. 1K 1K 1K 1K 1K 1K SEQ=5120 SEQ=6144 SEQ=2048 SEQ=3072 SEQ=2048 SEQ=4096 TCP Fast RetransmitExample Sender Receiver MSS = 1K ACK of new data ACK = 2048 WIN = 31K Duplicate ACK #1 ACK = 2048 WIN = 30K Duplicate ACK #2 ACK = 2048 WIN = 29K Fast Retransmit occurs (2nd packet is now retransmitted w/o waiting for it to timeout) Duplicate ACK #3 ACK = 2048 WIN = 28K ACK = 2048 WIN = 27K ACK = 7168 WIN = 26K

  50. TCP Fast Recovery • Yet another enhancement to TCP congestion control • Idea: Don’t do a slow start after a fast retransmit • Instead, use this algorithm: • Drop threshold to max(2*mss,1/2 of MIN(sliding window, congestion window)) • Set congestion window to threshold + 3 * MSS • For each duplicate ACK (after the fast retransmit), increment congestion window by MSS • When next non-duplicate ACK arrives, set congestion window equal to the threshold

More Related