1 / 56

Transport Layer ECE544: Communication Networks-II, Spring 2013

Transport Layer ECE544: Communication Networks-II, Spring 2013. Tam Vu WINLAB, Dept. of Computer Science Rutgers University. Includes teaching materials from, L. Peterson, Sumathi Gopal and Sumit Rangwala, D. Raychaudhuri, Mike Freedman. IP Protocol Stack: Key Abstractions. Application.

regina-best
Download Presentation

Transport Layer ECE544: Communication Networks-II, Spring 2013

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. Transport Layer ECE544: Communication Networks-II, Spring 2013 Tam Vu WINLAB, Dept. of Computer Science Rutgers University Includes teaching materials from, L. Peterson, Sumathi Gopal and Sumit Rangwala, D. Raychaudhuri, Mike Freedman

  2. IP Protocol Stack: Key Abstractions Application • Problem: Network Layer (IP) provides only best-effort communication services Transport Network Link Applications Messages Reliable streams Best-effort global packet delivery Best-effort local packet delivery

  3. Applications requirements vs. IP layer limitations • Guarantee message delivery • Network may drop messages. • Deliver messages in the same order they are sent • Messages may be reordered in networks and incurs a long delay. • Delivers at most one copy of each message • Messages may duplicate in networks. • Support arbitrarily large message • Network may limit message size. • Support synchronization between sender and receiver • Allows the receiver to apply flow control to the sender • Support multiple application processes on each host • Network only support communication between hosts • Many more

  4. IP Protocol Stack: Key Abstractions Application • Transport layer: • Provide applications with good abstractions • Without support or feedback from the network • Is the lowest layer in the network stack that is an end-to-end protocol Transport Network Link Applications Messages Reliable streams Best-effort global packet delivery Best-effort local packet delivery

  5. Transport Protocols • Logical communication between processes • Sender divides a message into segments • Receiver reassembles segments into message • Transport services • (De)multiplexing packets • Detecting corrupted data • Optionally: reliable delivery, flow control, …

  6. Two Basic Transport Features • Demultiplexing: port numbers • Error detection: checksums Server host 128.2.194.242 Client host Web server (port 80) Service request for 128.2.194.242:80 (i.e., the Web server) OS Client Echo server (port 7) IP payload detect corruption 6

  7. Most Popular Transport Protocols • User Datagram Protocol (UDP) • Support multiple applications processes on each host • Option to check messages for correctness with CRC check • Transmission Control Protocol (TCP) • Ensures reliable delivery of packets between source and destination processes • Ensures in-order delivery of packets to destination process • Other services • Real Time Protocol (RTP) • Serves real-time multimedia applications • Moves decision making to the applications • Runs over UDP

  8. User Datagram Protocol (UDP) • Service: Support for multiple processes on each host to communicate • Issue: IP only provides communication between hosts (IP addresses) • Solution • Add port number and associate a process with a port number • 4-Tuple Unique Connection Identifier: [SrcPort, SrcIPAddr, DestPort, DestIPAddr ] • Lightweight communication between processes • Send and receive messages • Avoid overhead of ordered, reliable delivery • No connection setup delay, in-kernel connection state • Used by popular apps • Query/response for DNS • Real-time data in VoIP 0 16 31

  9. User Datagram Protocol (UDP): Error Detection • Service: Ensure message correctness • Issue: Packet corruption in transit • Solution • Use Checksum. • Includes UDP header, payload, pseudo header • Pseudo header • Protocol number, source IP address, destination IP address, and UDP length 0 16 31

  10. Transmitting a stream of bytes ? • Stream-of-bytes service • Sends and receives a stream of bytes • Reliable, in-order delivery • Corruption: checksums • Detect loss/reordering: sequence numbers • Reliable delivery: acknowledgments and retransmissions • Connection oriented • Explicit set-up and tear-down of TCP connection • Flow control • Prevent overflow of the receiver’s buffer space • Congestion control • Adapt to network congestion for the greater good

  11. Transmission Control Protocol (TCP) • First proposed by Vinton Cerf and Robert Kahn, 1974 • TCP/IP enabled computers of all sizes, from different vendors, different OSs, to communicate with each other. • Used by 80% of all traffic on the Internet • Reliable, in-order delivery, connection-oriented, bye-stream service

  12. Starting and Ending a Connection:TCP Handshakes

  13. Establishing a TCP Connection B A SYN • Three-way handshake to establish connection • Host A sends a SYN (open) to the host B • Host B returns a SYN acknowledgment (SYN ACK) • Host A sends anACK to acknowledge the SYN ACK Each host tells its Initial Sequence Number (ISN) to the other host. SYN ACK ACK Data Data

  14. TCP Header Source port Destination port Sequence number Flags: SYN FIN RST PSH URG ACK Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  15. Step 1: A’s Initial SYN Packet A’s port B’s port A’s Initial Sequence Number Flags: SYN FIN RST PSH URG ACK Acknowledgment Advertised window 20 Flags 0 Checksum Urgent pointer Options (variable) A tells B it wants to open a connection…

  16. Step 2: B’s SYN-ACK Packet B’s port A’s port B’s Initial Sequence Number Flags: SYN FIN RST PSH URG ACK A’s ISN plus 1 Advertised window 20 Flags 0 Checksum Urgent pointer Options (variable) B tells A it accepts, and is ready to hear the next byte… … upon receiving this packet, A can start sending data 17

  17. Step 3: A’s ACK of the SYN-ACK A’s port B’s port Sequence number Flags: SYN FIN RST PSH URG ACK B’s ISN plus 1 Advertised window 20 Flags 0 Checksum Urgent pointer Options (variable) A tells B it is okay to start sending … upon receiving this packet, B can start sending data 18

  18. SYN Loss and Web Downloads • Upon sending SYN, sender sets a timer • If SYN lost, timer expires before SYN-ACK received • Sender retransmits SYN • How should the TCP sender set the timer? • No idea how far away the receiver is • Some TCPs use default of 3 or 6 seconds • Implications for web download • User gets impatient and hits reload • … Users aborts connection, initiates new socket • Essentially, forces a fast send of a new SYN! 19

  19. Tearing Down the Connection • Closing (each end of) the connection • Finish (FIN) to close and receive remaining bytes • And other host sends a FIN ACK to acknowledge • Reset (RST) to close and not receive remaining bytes B ACK ACK ACK FIN FIN SYN ACK SYN ACK Data A time 20

  20. Sending a FIN: close() Process is done sending data via socket Process invokes “close()” Once TCP has sent all the outstanding bytes… … then TCP sends a FIN Receiving a FIN: EOF Process is reading data from socket Eventually, read call returns an EOF Sending/Receiving the FIN Packet 21

  21. Data transmission

  22. TCP: Byte-stream • Service: Byte-stream • Application reads or writes a stream of bytes to the transport • Issue: IP is packet-oriented • Solution: TCP maintains a local buffer • Chop the stream into packets and transmit (sender) • Coalesce data from packets to form a stream (receiver)

  23. TCP “Stream of Bytes” Service Host A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 Host B Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 24

  24. …Emulated Using TCP “Segments” Host A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 • Segment sent when: • Segment full (Max Segment Size), • Not full, but times out, or • “Pushed” by application TCP Data TCP Data Host B Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 25

  25. TCP Segment IP Data • IP packet • No bigger than Maximum Transmission Unit (MTU) • E.g., up to 1500 bytes on an Ethernet link • TCP packet • IP packet with a TCP header and data inside • TCP header is typically 20 bytes long • TCP segment • No more than Maximum Segment Size (MSS) bytes • E.g., up to 1460 consecutive bytes from the stream IP Hdr TCP Data (segment) TCP Hdr 26

  26. Sequence Number Host A ISN (initial sequence number) Byte 81 Sequence number = 1st byte TCP Data TCP Data Host B 27

  27. Reliable Delivery on a Lossy Channel With Bit Errors

  28. Challenges of Reliable Data Transfer • Over a perfectly reliable channel: Done • Over a channel with bit errors • Receiver detects errors and requests retransmission • Over a lossy channel with bit errors • Some data missing, others corrupted • Receiver cannot easily detect loss • Over a channel that may reorder packets • Receiver cannot easily distinguish loss vs. out-of-order 30

  29. An Analogy • Alice and Bob are talking • What if Alice couldn’t understand Bob? • Bob asks Alice to repeat what she said • What if Bob hasn’t heard Alice for a while? • Is Alice just being quiet? Has she lost reception? • How long should Bob just keep on talking? • Maybe Alice should periodically say “uh huh” • … or Bob should ask “Can you hear me now?” 31

  30. Take-Aways from the Example • Acknowledgments from receiver • Positive: “okay” or “uh huh” or “ACK” • Negative: “please repeat that” or “NACK” • Retransmission by the sender • After not receiving an “ACK” • After receiving a “NACK” • Timeout by the sender (“stop and wait”) • Don’t wait forever without some acknowledgment 32

  31. TCP Support for Reliable Delivery • Detect bit errors: checksum • Used to detect corrupted data at the receiver • …leading the receiver to drop the packet • Detect missing data: sequence number • Used to detect a gap in the stream of bytes • ... and for putting the data back in order • Recover from lost data: retransmission • Sender retransmits lost or corrupted data • Two main ways to detect lost packets 33

  32. TCP Acknowledgments Host A ISN (initial sequence number) Sequence number = 1st byte TCP Data ACK sequence number = next expected byte TCP Data Host B 34

  33. Packet ACK Automatic Repeat reQuest (ARQ) Sender Receiver Timeout Time • ACK and timeouts • Receiver sends ACK when it receives packet • Sender waits for ACK and times out • Simplest ARQ protocol • Stop and wait • Send a packet, stop and wait until ACK arrives

  34. Quick TCP Math • Initial Seq No = 501. Sender sends 4500 bytes successfully acknowledged. Next sequence number to send is: (A) 4501 (B) 5000 (C) 5001 (D) 5002 • Next 1000 byte TCP segment received. Receiver acknowledges with ACK number: (A) 5001 (B) 6000 (C) 6001

  35. Flow Control:TCP Sliding Window

  36. Sliding Window: Motivation • Stop-and-wait is inefficient • Only one TCP segment is “in flight” at a time • Consider: 1.5 Mbps link with 50 ms round-trip-time (RTT) • Assume segment size of 1 KB (8 Kbits) • 8 Kbits/segment at 50 msec/segment  160 Kbps • That’s 11% of the capacity of 1.5 Mbps link 39

  37. Sliding Window • Allow a larger amount of data “in flight” • Allow sender to get ahead of the receiver • … though not too far ahead Sending process Receiving process TCP TCP Last byte read Last byte written Next byte expected Last byte ACKed Last byte received Last byte sent 40

  38. Receiver Buffering • Receive window size • Amount that can be sent without acknowledgment • Receiver must be able to store this amount of data • Receiver tells the sender the window • Tells the sender the amount of free space left Window Size Data ACK’d Outstanding Un-ack’d data Data OK to send Data not OK to send yet 41

  39. TCP: Flow Control • Flow Control • “Prevent sender from overrunning the capacity (buffer) of the receiver” • Solution: Use adaptive receiver window size • Goal is to keep (C) – (A)<MaxRcvBuffer • Every packet carries ACK and AdvertisedWindow Receiving Appl Sending Appl LastByteRead (A) (I)LastByteWritten TCP TCP (B) NextByteExpected (C) LastByteRcvd LastByteAcked(J) (K)LastByteSent LastByteSent (K) – LastByteAcked (J) <= AdvertisedWindow EffWin = AdvertisedWin - (LastByteSent-LastByteAcked) AdvertisedWindow = MaxRcvBuffer- ((NextByteExp-1)-LastByteRead) LastByteWritten – LastByteAcked <= MaxSendBuffer

  40. Optimizing Retransmissions

  41. Packet Packet Packet Packet Packet ACK ACK ACK ACK ACK Reasons for Retransmission Timeout Timeout Timeout Packet Timeout Timeout Timeout ACK lost DUPLICATE PACKET Early timeout DUPLICATEPACKETS Packet lost

  42. How Long Should Sender Wait? • Sender sets a timeout to wait for an ACK • Too short: wasted retransmissions • Too long: excessive delays when packet lost • TCP sets timeout as a function of the RTT • Expect ACK to arrive after an “round-trip time” • … plus a fudge factor to account for queuing • But, how does the sender know the RTT? • Running average of delay to receive an ACK 45

  43. TCP Timeout • Issue: RTT in a wide area network varies substantially • Solution: Adaptive Timeout • Original Algorithm: • EstimatedRTT = a x EstimatedRTT + (1-a) x SampleRTT • Timeout = β x EstimatedRTT (β = 2) • Problem • Does not distinguish whether the ACK is for original transmission or retransmission • Constant β is not good. • Assumes constant variance

  44. TCP Timeout • Karn/Partridge Algorithm • Whenever TCP retransmits a segment, it stops taking samples of the RTT • Only measure SampleRTT for segments that have been sent only once • Each time TCP retransmits, set the next timeout to be twice the last timeout • Relieves congestion • Jacobson/Karels Algorithm: Adaptive variance (uses mean variance) Difference = SampleRTT - EstimatedRTT EstimatedRTT = EstimatedRTT + (d x Difference) → (same as in original) Deviation = Deviation + d(|Difference|- Deviation) Timeout = m x EstimatedRTT + f x Deviation (default: set m = 1 and f= 4 )

  45. TCP Deadlock • TCP Deadlock • receiver advertises a window size of 0, the sender stops sending data • the window size update from the receiver is lost • To solve it: • the sender starts the persist timer when AdvertisedWindow = 0 • When the persist timer expires, the sender sends a small packet

  46. Triggering Transmission • When to transmit a segment: • small segments subject to large overhead • Reach max segment size (MSS): the size of the largest segment TCP can send without causing the local IP to fragment • MSS = local MTU – IP & TCP header • The sending process explicitly ask the TCP to transmit, “push”

  47. Source 1 Source 2 Source 3 Dest 2 Dest 1 Congestion • When the network cannot support the sender’s rate • Queues at the network elements overflow Even with flow control packets might not reach the destination

  48. Congestion Control vs. Flow Control • Congestion Control • Mechanism to prevent sender from overrunning the capacity of the network • When network is the bottleneck • Flow Control • Mechanism to prevent sender from overrunning the capacity of the receiver • When receiver is the bottleneck

  49. Congestion Control: Design Approach • Maintain another window at the sender called CongestionWindow (cwnd) • CongestionWindow is the max number of packets allowed in the network • Number of unACKed packets at the sender. • Key: How to calculate congestion window (cwnd) • Various approaches possible • TCP estimates it based on observed packet losses • Assumes packet loss as indication of congestion • Since we don’t know whether the network or the receiver is the bottleneck • MaxWindow = MIN(CongestionWindow, AdvertisedWindow) • EffectiveWin = MaxWindow – (LastByteSent – LastByteAcked)

  50. Congestion Avoidance: (AIMD) • If no congestion in the network (increase conservatively) • Increase the congestion window additively every RTT • If congestion in the network (decrease aggressively) • Decrease the congestion window multiplicatively, immediately • How is congestion detected? • Estimated (more later) Every ACK reception cwnd = cwnd + MSS*(MSS/cwnd) cwnd in bytes Every ACK reception w = w + 1/w w = cwnd in segments Every RTT w = w + 1 w = cwnd in segments cwnd = cwnd/2 cwnd in bytes

More Related