1 / 55

CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2

CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2. Instructor: Joe McCarthy (based on Prof. Fukuda’s slides). Overview. Utilize host-to-host packet delivery service (network layer) to provide a process-to-process communication channel (transport layer). segments. packets. frames. bits.

brennan-chase
Télécharger la présentation

CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2

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. CSS432 End-to-End ProtocolsTextbook Ch5.1 – 5.2 Instructor: Joe McCarthy(based on Prof. Fukuda’s slides) CSS432: End-to-End Protocols

  2. Overview Utilize host-to-host packet delivery service (network layer) to provide a process-to-process communication channel (transport layer) segments packets frames bits CSS432: Internetworking

  3. http://www.tcpipguide.com/free/t_TCPDataHandlingandProcessingStreamsSegmentsandSequ-2.htmhttp://www.tcpipguide.com/free/t_TCPDataHandlingandProcessingStreamsSegmentsandSequ-2.htm CSS432: Internetworking

  4. M5, M5, M3 IP Protocol • Underlying “best-effort” network • May drop messages • May re-order messages • May deliver duplicate copies of a given message • May deliver messages after an arbitrarily long delay • Limits messages to a finite size • IP addresses (globally unique) Request a retransmission of M3 and M5 M5, and M3 M5 M2, M1, M4 M5, M4, M3, M2, M1 M5, M2, M1 M4 M4, M3 M3 CSS432: End-to-End Protocols

  5. End-to-End Protocols • Common end-to-end services • support multiple application processes on each host • guarantee message delivery • deliver messages in FIFO order • deliver at most one copy of each message • support arbitrarily large messages • support synchronization • allow the receiver to flow control the sender P1 P2 P3 P4 M5, M4, M3, M2, M1 Network m5, m4, m3, m2, m1 CSS432: End-to-End Protocols

  6. Simple Demultiplexor (UDP) • User Datagram Protocol • Adds multiplexing • Unreliable & unordered • No flow control • Endpoints identified by ports • servers have well-known ports • see /etc/services on Unix • Optional checksum • UDP header + data +pseudoheader(Src & Dst IP addrs, protocol #) CSS432: End-to-End Protocols

  7. TCP Overview • Full duplex • Flow control: keep sender from overrunning receiver • Congestion control: keep sender from overrunning network • Connection-oriented • Byte-stream • app writes bytes • TCP assembles & sends segments • app reads bytes CSS432: End-to-End Protocols

  8. Transport vs. Data Link Layer CSS432: End-to-End Protocols

  9. Transport vs. Data Link Layer • Potentially connects many different hosts • need explicit connection establishment and termination • Potentially long delay in network • need to be prepared for arrival of very old packets • need to set MSL (Maximum Segment Lifetime) • Potentially high variation in RTT (Round Trip Time) • need adaptive timeout mechanism • Potentially different capacity at destination • need to accommodate different node capacity • Potentially different network capacities • need to be prepared for network congestion CSS432: End-to-End Protocols

  10. Data (SequenceNum) Sender Receiver Acknowledgment + AdvertisedWindow TCP Segment Format • Each connection identified with 4-tuple: • (SrcPort, SrcIPAddr, DstPort, DstIPAddr) • Sliding window + flow control • Acknowledgment, SequenceNum, AdvertisedWinow • Flags • SYN: Establish a connection • FIN: terminate a connection • RESET: Confused, terminate • PUSH: Section 5.2.7 • URG: Sending urgent data • ACK: Validating acknowledgment field • SequenceNum is incremented in all cases other than ACK. CSS432: End-to-End Protocols

  11. TCP Connection Establishment • 3-Way Handshake • Client • Initiate a connection to a server with SeqNum=x • Set a timer and retransmit the request upon an expiration • Server • Acknowledge the client request with ACK=x+1 • Initiate a reverse connection with SeqNum=y • Set a timer and retransmit the request upon an expiration • Client • Acknowledge the server request with ACK=y+1 • x and y are chosen at random • Protect against two incarnations of the same connection using the same sequence number. CSS432: End-to-End Protocols

  12. TCP Connection Tear-Down • 3-Way Handshake • Initiator: FIN • Receiver: ACK/FIN • Initiator: ACK • “Half-open” connection • Receiver (of FIN) may still have data to send • Acknowledges FIN • Keeps sending data • Sends its own FIN • Receiver acknowledges http://en.wikipedia.org/wiki/Transmission_Control_Protocol CSS432: End-to-End Protocols

  13. CLOSED Active open /SYN Passive open Close Close LISTEN SYN/SYN + ACK Send/ SYN SYN/SYN + ACK SYN_RCVD SYN_SENT ACK SYN + ACK/ACK Close /FIN ESTABLISHED Close /FIN FIN/ACK FIN_WAIT_1 CLOSE_WAIT FIN/ACK ACK Close /FIN ACK + FIN/ACK FIN_WAIT_2 CLOSING LAST_ACK Timeout after two ACK ACK segment lifetimes (2 * MSL) FIN/ACK TIME_WAIT CLOSED State Transition Diagram • Open • Active open • A client • connect() • Passive open • A server • listen() • Can change active • Close • Active close • A client or a server • First close() • Both side can be active • Passive close • A client or server • close() in response to the first close() CSS432: End-to-End Protocols

  14. Timing Chart Client Server ( connect( ) ) SYN_SENT LISTEN ( listen( ) ) SYN seq=x SYN_RCVD Establishment SYN seq=y, ACK=x + 1 ESTABLISHED ACK=y + 1 ESTABLISHED ( write( ) ) seq=x+1 ACK=y + 1 ( read( ) ) Data Transfer ACK x + 2 ( close( ) ) FIN_WAIT_1 FIN seq=x+2 ACK=y + 1 CLOSE_WAIT ACK x + 3 Termination FIN seq = y + 1 FIN_WAIT_2 LAST_ACK( close( ) ) TIME_WAIT ACK=y + 2 You may see this with tcpdump in assignment 3. CSS432: End-to-End Protocols

  15. CSS432: Internetworking

  16. http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htmhttp://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm CSS432: Internetworking

  17. http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htmhttp://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm CSS432: Internetworking

  18. http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htmhttp://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm CSS432: Internetworking

  19. http://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htmhttp://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htm CSS432: Internetworking

  20. http://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htmhttp://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htm CSS432: Internetworking

  21. Sending application Receiving application TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteSent NextByteExpected LastByteRcvd Sliding Window Revisited • Sending side • LastByteAcked ≤LastByteSent≤LastByteWritten • buffer bytes between [LastByteAcked, LastByteWritten] • Receiving side • LastByteRead < NextByteExpected≤LastByteRcvd + 1 • buffer bytes between [LastByteRead, LastByteRcvd] CSS432: End-to-End Protocols

  22. http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htmhttp://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htm CSS432: Internetworking

  23. Flow Control Receiving application Sending application TCP TCP LastByteWritten LastByteRead y LastByteSent NextByteExpected LastByteRcvd LastByteAcked LastByteRcvd – LastByteRead ≤ MaxRcvbuffer LastByteSent – LastByteAcked ≤ AdvertisedWindow AdvertisedWindow = MaxRcvBuffer – ( (NextByteExpected – 1) – LastByteRead ) EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) • Send ACK with an advertise window • in response to arriving data segments • as long as all the preceding bytes have • also arrived and • until the advertised window reaches 0. • (ACK returned at the first time when it reaches 0) LastByteWritten – LastByteAcked ≤ MaxSendBuffer block sender if (LastByteWritten - LastByteAcked) + y > MaxSendBuffer CSS432: End-to-End Protocols

  24. y y Flow Control with a Slower Receiver Receiving application Sending application Read slow. TCP TCP LastByteWritten LastByteRead LastByteSent LastByteRcvd = LastByteAcked NextByteExpected - 1 LastByteSent – LastByteAcked LastByteRcvd – LastByteRead ≤ MaxRcvbuffer AdvertisedWindow = MaxRcvBuffer – ( (NextByteExpected – 1) – LastByteRead ) = 0 0 EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) LastByteWritten – LastByteAcked ≤ MaxSendBuffer CSS432: End-to-End Protocols No more send, no more ack, thus it stays In the same value

  25. Flow Control • AdvertisedWindow = 0: sender won’t send any more data. • Receiver only responds to sender • Will not initiate update when AdvertisedWindow > 0 • How can the sender find out when the receiver can receive more data? CSS432: End-to-End Protocols

  26. Flow Control • AdvertisedWindow = 0: sender won’t send any more data. • Receiver only responds to sender • Will not initiate update when AdvertisedWindow > 0 • How can the sender find out when the receiver can receive more data? • Periodically send a byte • “Smart sender / dumb receiver” CSS432: End-to-End Protocols

  27. Wraparound • 32-bit SequenceNum • Maximum Segment Lifetime(MSL) = 120 seconds • SequenceNum should not wrap around within MSL time period Bandwidth Time Until Wrap Around T1 (1.5 Mbps) 6.4 hours Ethernet (10 Mbps) 57 minutes T3 (45 Mbps) 13 minutes FDDI (100 Mbps) 6 minutes STS-3 (155 Mbps) 4 minutes STS-12 (622 Mbps) 55 seconds STS-24 (1.2 Gbps) 28 seconds CSS432: End-to-End Protocols

  28. Keeping the Pipe Full • 16-bit AdvertisedWindow = 64KB • Assuming that RTT = 100msec, the advertised window’s capacity x Network bandwidth Bandwidth RTT(100msec) x Bandwidth Product T1 (1.5 Mbps) 18KB Ethernet (10 Mbps) 122KB T3 (45 Mbps) 549KB FDDI (100 Mbps) 1.2MB STS-3 (155 Mbps) 1.8MB STS-12 (622 Mbps) 7.4MB STS-24 (1.2 Gbps) 14.8MB CSS432: End-to-End Protocols

  29. Segment Transmission Segments are buffered until send triggered: • Buffer reaches Maximum Segment Size (MSS) = Maximum Transfer Unit (MTU) – ( TCP header size + IP header size ) • TCP invokes a push operation that flushes the unsent data • When a timer expires • May precipitate silly window syndrome CSS432: End-to-End Protocols

  30. Silly Window Syndrome small MMS 2 Sender MMS 1 Receiver • Sender aggressively takes advantage of any available window, • The receiver empties every window regardless of its size and thus small windows will never disappear. • The problem occurs only when • Sender transmits a small segment • Receiver opens the AdvertisedWindow a small amount • What should be done? And who should do it? Ad Window Ad Window CSS432: End-to-End Protocols

  31. Silly Window Syndrome small MMS 2 Sender MMS 1 Receiver • Sender aggressively takes advantage of any available window, • The receiver empties every window regardless of its size and thus small windows will never disappear. • The problem occurs only when • Sender transmits a small segment • Receiver opens the AdvertisedWindow a small amount • The receiver could delay ACKs to make a larger window • How long does it wait? • The sender should make a decision (“smart sender/dumb receiver”) • Nagle’s Algorithm (Programming assignment 3) Ad Window Ad Window CSS432: End-to-End Protocols

  32. http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htmhttp://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm CSS432: Internetworking

  33. http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htmhttp://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm The client's send window is 360, and it has lots of data to send. It immediately sends a 360 byte segment to the server. This uses up its entire send window. When the server gets this segment it acknowledges it. However, it can only remove 120 bytes so the server reduces the window size from 360 to 120. It sends this in the Window field of the acknowledgment. The client receives an acknowledgment of 360 bytes, and sees that the window size has been reduced to 120. It wants to send its data as soon as possible, so it sends off a 120 byte segment. The server has removed 40 more bytes from the buffer by the time the 120-byte segment arrives. The buffer thus contains 200 bytes (240 from the first segment, less the 40 removed). The server is able to immediately process one-third of those 120 bytes, or 40 bytes. This means 80 bytes are added to the 200 that already remain in the buffer, so 280 bytes are used up. The server must reduce the window size to 80 bytes. The client will see this reduced window size and send an 80-byte segment. The server started with 280 bytes and removed 40 to yield 240 bytes left. It receives 80 bytes from the client, removes one third, so 53 are added to the buffer, which becomes 293 bytes. It reduces the window size to 67 bytes (360-293). CSS432: Internetworking

  34. Nagle’s Algorithm When the application produces new data to send if both the new data & available window ≥ MSS send a full segment // send MSS bytes right now else if there is unAcked data in transit buffer new data until an ACK arrives // wait for empty MSS segment else send all the new data now // Can’t avoid silly window syndrome • Ack works as a timer to fire a new segment transmission. • The algorithm may not respond to interactive or real-time applications • TCP_NODELAY Option: Transmit data as soon as possible • setsockopt(sockfd, SOL_TCP, TCP_NODELAY, &intFlag, sizeof(intFlag)) CSS432: End-to-End Protocols

  35. Timeouts • Why timeout? CSS432: End-to-End Protocols

  36. Timeouts & Retransmissions • Timeout required for reliable transmission • Retransmit a lost packet • Detect congestion / invoke congestion control • But: RTT can vary widely • When to timeout (how long to wait)? CSS432: End-to-End Protocols

  37. Adaptive Retransmission • Timeout required for reliable transmission • Retransmit a lost packet • Detect congestion / invoke congestion control • But: RTT can vary widely • Timeout using RTT estimation algorithms • Original Algorithm • Karn/Partridge Algorithm • Jacobson/Karels Algorithm CSS432: End-to-End Protocols

  38. Original Algorithm • Measure SampleRTT for each segment / ACK pair CSS432: End-to-End Protocols

  39. Original Algorithm • Measure SampleRTT for each segment / ACK pair • Compute weighted average of RTT • EstRTT = ax EstRTT + b x SampleRTT • where a+b = 1 • a between 0.8 and 0.9 (smoothing function) • b between 0.1 and 0.2 CSS432: End-to-End Protocols

  40. Original Algorithm • Measure SampleRTT for each segment / ACK pair • Compute weighted average of RTT • EstRTT = ax EstRTT + b x SampleRTT • where a+b = 1 • a between 0.8 and 0.9 (smoothing function) • b between 0.1 and 0.2 • Set timeout based on EstRTT • TimeOut=2 x EstRTT • Conservative: EstRTT cannot respond quickly to deviations in SampleRTT CSS432: End-to-End Protocols

  41. Karn / Partridge Algorithm (1987) CSS432: End-to-End Protocols

  42. Karn / Partridge Algorithm (1987) • Do not sample RTT when retransmitting • Can’t figure out which transmission the latest ACK corresponds to. • Double timeout (vs. EstRTT) after each retransmission • Exponential backoff • Congestion most likely cause of lost segments CSS432: End-to-End Protocols

  43. Jacobson / Karels Algorithm (1988) • Original Algorithm • EstRTT = ax EstRTT + b x SampleRTT 0.8 and 0.9 0.1 and 0.2 • TimeOut = EstRTT * 2 • New Algorithm that takes into accountlarge variations among SampleRTTs • EstRTT = EstRTT + d(SampleRTT – EstRTT) 0.125Diff • Dev = Dev + d(|SampleRTT – EstRTT| – Dev) Diff • TimeOut = m x EstRTT + f x Dev 14 CSS432: End-to-End Protocols

  44. Reviews • UDP • TCP: three-way handshake and state transition • Sliding window and flow control • Segment transmission: silly window syndrome and Nagle’s algorithm • Adaptive retransmission: original, Karn/Partridge, and Jacobson/Karels • Exercises in Chapter 5 • Ex. 5, 14, 22, and 39 (TCP state transition) • Ex. 9(a) (Sliding window) • Ex. 20 (Nagle’s algorithm) CSS432: End-to-End Protocols

  45. Exercise 5 When closing a TCP connection, why is the two-segment lifetime timeout not necessary on the transition from LAST_ACK to CLOSED? CSS432: Internetworking

  46. Exercise 14 If host A receives two SYN packets from the same port from remote host B, the second may be either a retransmission of the original or, if B has crashed and rebooted, an entirely new connection request. (a) Describe the difference as seen by host A between these two cases. (b) Give an algorithmic description of what the TCP layer needs to do upon receiving a SYN packet. Consider the duplicate/new cases above and the possibility that nothing is listening to the destination port CSS432: Internetworking

  47. Exercise 9(a) You are hired to design a reliable byte-stream protocol that uses a sliding window (like TCP). This protocol will run over a 1-Gbps network. The RTT of the network is 100 ms, and the maximum segment lifetime is 30 seconds. (a) How many bits would you include in the AdvertisedWindow and SequenceNum fields of your protocol header? CSS432: Internetworking

  48. Exercise 20 The Nagle algorithm, built into most TCP implementations, requires the sender to hold a partial segment’s worth of data (even if PUSHed) until either a full segment accumulates or the most recent outstanding ACK arrives. (a) Suppose the letters abcdefghi are sent, one per second, over a TCP connection with an RTT of 4.1 seconds. Draw a timeline indicating when each packet is sent and what it contains. (b) If the above were typed over a full-duplex Telnet connection, what would the user see? (c) Suppose that mouse position changes are being sent over the connection. Assuming that multiple position changes are sent each RTT, how would a user perceive the mouse motion with and without the Nagle algorithm? CSS432: Internetworking

  49. Exercise 22 Explain why TIME_WAIT is a somewhat more serious problem if the server initiates the close than if the client does. Describe a situation in which this might reasonably happen. CSS432: Internetworking

  50. Exercise 39 When TCP sends a SYN, SequenceNum = x or FIN, SequenceNum = x, the consequent ACK has Acknowledgement = x + 1, i.e., SYNs and FINs each take up one unit in sequence number space. Is this necessary? If so give an example of an ambiguity that would arise if the corresponding Acknowledgement were x instead of x + 1; if not, explain why. CSS432: Internetworking

More Related