1 / 32

Chapter 12 Transmission Control Protocol (TCP)

Chapter 12 Transmission Control Protocol (TCP). Mi-Jung Choi Dept. of Computer Science and Engineering mjchoi@postech.ac.kr. Contents . 12.1 TCP SERVICES 12.2 TCP FEATURES 12.3 SEGMENT 12.4 A TCP CONNECTION 12.5 STATE TRANSITION DIAGRAM 12.6 FLOW CONTROL 12.7 ERROR CONTROL

taite
Download Presentation

Chapter 12 Transmission Control Protocol (TCP)

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. Chapter 12 Transmission Control Protocol (TCP) Mi-Jung Choi Dept. of Computer Science and Engineering mjchoi@postech.ac.kr

  2. Contents 12.1 TCP SERVICES 12.2 TCP FEATURES 12.3 SEGMENT 12.4 A TCP CONNECTION 12.5STATE TRANSITION DIAGRAM 12.6 FLOW CONTROL 12.7 ERROR CONTROL 12.8 CONGESTION CONTROL 12.9 TCP TIMERS 12.10 OPTIONS 12.12 TCP PACKAGE

  3. Objectives • Be able to name and understand the services offered by TCP • Understand TCP’s flow and error control and congestion control • Be familiar with the fields in a TCP segment • Understand the phases in a connection-oriented connection • Understand the TCP transition state diagram • Be able to name and understand the timers used in TCP • Be familiar with the TCP options

  4. 12.6 Flow Control Flow control regulates the amount of data a source can send before receiving an acknowledgment from the destination. TCP defines a window that is imposed on the buffer of data delivered from the application program. The topics discussed in this section include: Sliding Window Protocol Silly Window Syndrome

  5. 12.6 Flow Control ~ defines the amount of data a source can send before receiving an acknowledge from the destination • Sender does not flood the receiver, but maximizes throughput • Sliding window Protocol • A sliding window is used to make transmission more efficient as well as to control the flow of data so that the destination does not become overwhelmed with data • TCP’s sliding windows arebyte oriented • Window = Set of sequence numbers to send/receive • Sender window • Sender window increases when ack received • Packets in sender window must be buffered at source

  6. Sequence Number • using 32 bit field, sequence numbers in set 0 ~ 232-1, • sending window: seq. numbers of bytes that may be sent • receiving window: seq. numbers that may be accepted into buffers • “TCP” • buffer space at sender and receiver with a credit scheme for flow control • receiver advertises credit to sender ack is “next expected” packet

  7. Sliding Window • rwnd: receiver window • cwnd: congestion window

  8. Example 3 What is the value of the receiver window (rwnd) for host A if the receiver, host B, has a buffer size of 5,000 bytes and 1,000 bytes of received and unprocessed data? SolutionThe value of rwnd = 5,000 − 1,000 = 4,000. Host B can receive only 4,000 bytes of data before overflowing its buffer. Host B advertises this value in its next segment to A.

  9. Example 4 What is the size of the window for host A if the value of rwnd is 3,000 bytes and the value of cwnd is 3,500 bytes? SolutionThe size of the window is the smaller of rwnd and cwnd, which is 3,000 bytes.

  10. Sliding Window Protocol • Send buffer • Receiver window

  11. Sliding Window Protocol • Expanding the sender window • Shrinking the sender window To avoid shrinking the sender window, the receiver must wait until more space is available in its buffer.

  12. Example 5 Figure 12.21 shows an unrealistic example of a sliding window. The sender has sent bytes up to 202. We assume that cwnd is 20 (in reality this value is thousands of bytes). The receiver has sent an acknowledgment number of 200 with an rwnd of 9 bytes (in reality this value is thousands of bytes). The size of the sender window is the minimum of rwnd and cwnd or 9 bytes. Bytes 200 to 202 are sent, but not acknowledged. Bytes 203 to 208 can be sent without worrying about acknowledgment. Bytes 209 and above cannot be sent.

  13. Example 6 In Figure 12.21 the server receives a packet with an acknowledgment value of 202 and an rwnd of 9. The host has already sent bytes 203, 204, and 205. The value of cwnd is still 20. Show the new window. SolutionFigure 12.22 shows the new window. Note that this is a case in which the window closes from the left and opens from the right by an equal number of bytes; the size of the window has not been changed. The acknowledgment value, 202, declares that bytes 200 and 201 have been received and the sender needs not worry about them; the window can slide over them.

  14. Example 7 In Figure 12.22 the sender receives a packet with an acknowledgment value of 206 and an rwnd of 12. The host has not sent any new bytes. The value of cwnd is still 20. Show the new window. SolutionThe value of rwnd is less than cwnd, so the size of the window is 12. Figure 12.23 shows the new window. Note that the window has been opened from the right by 7 and closed from the left by 4; the size of the window has increased.

  15. Example 8 In Figure 12.23 the host receives a packet with an acknowledgment value of 210 and an rwnd of 5. The host has sent bytes 206, 207, 208, and 209. The value of cwnd is still 20. Show the new window. SolutionThe value of rwnd is less than cwnd, so the size of the window is 5. Figure 12.24 shows the situation. Note that this is a case not allowed by most implementations. Although the sender has not sent bytes 215 to 217, the receiver does not know this.

  16. Example 8 (cont.)

  17. Example 9 How can the receiver avoid shrinking the window in the previous example? SolutionThe receiver needs to keep track of the last acknowledgment number and the last rwnd. If we add the acknowledgment number to rwnd we get the byte number following the right wall. If we want to prevent the right wall from moving to the left (shrinking), we must always have the following relationship. new ack + new rwnd ≥ last ack + last rwndornew rwnd ≥ (last ack + last rwnd) − new ack

  18. Note To avoid shrinking the sender window, the receiver must wait until more space is available in its buffer. Window shutdown The receiver can temporarily shut down the window by sending an rwndof 0, if the receiver does not want to receive any data from the sender for a while. The sender does not actually shrink the size of the window, but stops sending data until a new advertisement has arrived. Even when the window is shut down by an order from the receiver, the sender can always send a segment with one byte of data (probing) to prevent a deadlock.

  19. 12.6 FLOW CONTROL (cont.) • In TCP, the sender window size is totally controlled by the receiver window value. However, the actual window size can be smaller if there is congestion in the network. Some Points about TCP’s Sliding Windows: ❏ The size of the window is the lesser of rwnd and cwnd.❏ The source does not have to send a full window’s worth of data.❏ The window can be opened or closed by the receiver, but should not be shrunk.❏ The destination can send an acknowledgment at any time as long as it does not result in a shrinking window.❏ The receiver can temporarily shut down the window; the sender, however, can always send a segment of one byte after the window is shut down.

  20. 12.6 FLOW CONTROL (cont.) • Credit-based Window management • Increase and decrease by receiving TCP

  21. SILLY WINDOW SYNDROME • Silly window syndrome created by sender • if sending TCP is serving an application program that creates data slowly, for example, 1 byte at a time. • 예 : 1 byte data+ 20 bytes TCP header + 20 byte IP header • Nagle’s Solution • To prevent the sending TCP from sending data byte by byte. • TCP must be forced to wait as it collects data to send in a large block • Nagle algorithm: by sender • sending TCP는 단지 한 바이트라도 송신 응용 프로그램으로부터 수신하는 첫 데이터를 세그먼트로 만든 후 전송한다. • 첫번째 세그먼트를 전송한 후에, sending TCP는 receiving TCP로부터 확인응답을 수신하거나, 또는 최대 크기의 세그먼트를 구성할 수 있을 정도로 충분한 데이터가 출력 버퍼에 저장되기 전까지는 데이터를 출력 버퍼에 저장한다. 둘 중의 한 경우가 발생되면, sending TCP는 세그먼트를 전송한다. • 나머지 전송 시간동안 2번째 단계를 반복한다. 즉 세그먼트 2에 대한 확인 응답이 수신되거나 최대 크기의 세그먼트를 채울 수 있을 정도로 충분한 데이터가 정장 되었을 경우에는 세그먼트 3이 전송된다.

  22. SILLY WINDOW SYNDROME • Silly window syndrome created by receiver • if receiving TCP is serving an application program that consumes data slowly, for example, 1 byte at a time. • Clark’s Solution • To send an ACK as soon as the arrives, but to announce a window size of 0 until either there is enough space to accommodate a segment of maximum size or until half of buffer is empty. • 2nd Solution: Delayed Acknowledgement • To delay sending the ACK • The receiver waits until there is decent amount of space in its incoming buffer before acknowledging the arrived segments. • 장점 : 트래픽 감소(각 세그먼트에 대해서 확인응답을 전송할 필요가 없기에) • 단점 : 송신측에서는 확인응답을 받지 못한 세그먼트를 재 전송할 가능성이 있기 때문에 TCP에서는 확인 응답이 0.5초 이상 지연되지 않도록 정의되어 있다.

  23. 12.7 ERROR CONTROL TCP provides reliability using error control, which detects corrupted, lost, out-of-order, and duplicated segments. Error control in TCP is achieved through the use of the checksum, acknowledgment, and time-out. The topics discussed in this section include: • Checksum • Acknowledgment • Acknowledgment Type • Retransmission • Out-of-Order Segments • Some Scenarios

  24. 12.7 ERROR CONTROL • Error types • Corrupted Segments • Lost Segments • Out-of-order Segments • Duplicated Segments • Error detection mechanism • Error detection tools: checksum, acknowledgement, and time-out • Checksum field is used to check for a corrupted segment • Acknowledgement is used to confirm the receipt of those segment uncorrupted • If a segment is not acknowledged before the time-out, it considered to be either corrupted or lost • Error correction mechanism • time-out timer – retransmission

  25. Acknowledgement • ACK segments do not consume sequence numbers and are not acknowledged. • ACK rules • Rule 1: piggybacking • Rule 2: • When the receiver has no data to send and it receives an in-order segment, the receiver delays sending an ACK until another segment arrived or until a period of time (normally 500 ms). • Rule 3: • no more than 2 in-order unacknowledged segments at any time • Rule 4: • When a segment arrives with an out-of-order seg. number, the receiver immediately sends an ACK announcing the next expected seg. number. • Rule 5: • When a missing segment arrives, the receiver immediately sends an ACK. • Rule 6: • If a duplicate segment arrives, the receiver immediately sends an ACK. • Acknowledgement types • Accumulate Acknowledgement (ACK) • Selective Acknowledgement (SACK)

  26. Retransmission • In modern implementations, a retransmission occurs if the retransmission timer expires or three duplicate ACK segments have arrived. • No retransmission timer is set for an ACK segment. • Retransmission after RTO (retransmission timeout) • Retransmission after Three Duplicate ACK segments • Out-of-Order segment • Data may arrive out of order and be temporarily stored by the receiving TCP, but TCP guarantees that no out-of-order segment is delivered to the process.

  27. Normal Operation

  28. Lost segment The receiver TCP delivers only ordered data to the process.

  29. Fast retransmission

  30. Delayed segment • Delayed TCP segment are treated the same way as lost or corrupted segments by the receiver. • The delayed segment may arrive after it has been resent (a duplicate segment) • Duplicate segment • When a segment arrives that contains a sequence number less than the previously acknowledged bytes, it is discarded.

  31. Automatically Corrected Lost Acknowledgment

  32. Lost acknowledgment corrected by resending a segment Lost acknowledgments may create deadlock if they are not properly handled

More Related