TCP.

Contents TCP TCP connection TCP flow control TCP congestion control
TCP timer UDP

Transport layer protocol
End-to-end data transfer (cf) DLP(data link protocol) data transfer between adjacent nodes DLP DLP DLP DLP DLP Host Host Transport layer protocol

Transport Layer services
Addressing the application process and delivering data between processes What else should the transport layer do for application? AP1 AP2 AP3 AP1 AP2 AP3 end-to-end Transport transport end-to-end reliable 서비스의 필요성 지금까지의 IP 서비스는 네트워크의 각 노드에서 이루어지는 네트워크 계층 서비스이다. IP 서비스는 unreliable network service를 제공해 주고 있다. no error control no congestion control duplicate packet delivery out-of-order packet delivery 따라서 응응 프로그램이 네트워크를 통해 전달된 데이터를 신뢰하고 처리하기 위해서는 transport 계층에서 신뢰성 있는 서비스를 제공해 주어야 한다. 인터넷에서는 양 종단의 TCP에서 이러한 신뢰성 서비스를 제공해 주고 있다. IP IP IP network access 1 network network access1 access2 network Access 2 subnet 1 subnet 2

What the transport layer should do in the Internet(1)
IP provides unreliable services to the upper layers. no error control IP does merely the header checksum, but do not send ACKs nor retransmit. no flow control/no congestion control IP doesn’t have any function to control the transmission rate depending on the states of receivers or networks. duplicate packet discovery When packets are not delivered within the predefined time limit to the receiver because of network congestion or taking detour, even though those packets are not lost on the way, the sender retransmits the same packets. Also, the ACK packets are not delivered to the sender within the predefined time limit, the sender times out and retransmits the same packets. The IP of receiver cannot detect those duplicate packets and delivers the packets to the upper layers. out-of-order packet delivery Because IP use the datagram mode, packets can take different paths, consequently they might arrive out of order.

What the transport layer should do in the Internet(2)
The application data that are delivered by IP might be lost due to error or congestion, or arrive at the destination out of order, or be duplicated at the destination. Thus, the transport layer protocol in the Internet should provide the reliable services to the application layers if the application requires reliable service. Otherwise all dirty work should be done by application itself. There are two transport protocols in the Internet. TCP – provide reliable services. UDP - simple, streamlined delivery services to the application layers which do not need reliable service.

Internet transport layer protocols
TCP(Transmission Control Protocol) provide reliable services to the application layers. Multiplexing (addressing the application services) error control (error detection and retransmission) flow control congestion control Guarantee no out-of-sequence of the packet order UDP(User Datagram Protocol) Provide unreliable services UDP does very simple function compared to TCP. Error detection (optional)

TCP service characteristics
End-to-end reliable service guarantee the reliable data transfer between application processes No error, no loss, no out-of-sequence connection-oriented service Consists of three steps: connection setup, data transfer, connection release full duplex transmission TCP connection setup enables two-way connections. stream-oriented transmission TCP views messages from application processes as continuous byte stream, not as separate packets. Graceful connection release When the connection terminates, TCP releases the connection after data transfer is completed.

How to provide reliable services(1)
Transmission unit is segment. The data sent to TCP from application processes are fragmented to have the size proper for transmission. Each fragmented data is called a segment. So the segment is the transmission unit when TCP sends application process data. On the contrary, UDP does not fragment the application data, instead send the data as it was given from application processes. Management of the segment sequence Each segment is given a sequence number (viewed as byte streams), so receiver TCP can recognize any loss of segments and the out-of-sequence of arriving segments. ACK transmission When TCP receives correct segments, it always replies with ACK segment. For enhancing performance, it uses the accumulative ACK. Timer management When TCP sends segments, it starts a timer. When the ACK for the segments sent does not arrive until the timer times out, it resends the same segment.

Error control (checksum) TCP checks any error on the segments it received using the checksum field in the header. If it finds any error, it discards the segment. Also using the sequence number on the segment, it checks any loss of segments or out-of-sequence of the segments. Order control The receiver stores the packets it receives in the buffer, and after keeping the order of segments, it delivers them to application processes. Detection and discard of duplicate segments When the same segments arrives, the receiver discard the segment.

Clear connection management Clear connection setup using 3 way handshake Also, clear connection release using 3 way handshake When one end station happens to reboot, the station will setup another TCP connection in addition to the current TCP connection. In this case, TCP can distinguish the segments of the previous connection and the newly established connection. Flow control TCP uses a buffer, and notifies the other TCP on the connection of the available space in the buffer for receiving. So the other TCP can send only the amount of segments and stop. Congestion control TCP controls transmission rate depending on congestion state in the network.

TCP Header IP datagram TCP segment IP header TCP header TCP data
20 octets 20 octets

TCP Header 16-bit source port number 16-bit destination port number
32-bit sequence number TCP header 32-bit acknowledgement number 4bit hdr length Reserved (6 bits) U R G A C K P S H R S T S Y N F I N 16-bit window size 16-bit TCP checksum 16-bit urgent pointer Options (if any) Padding(if any) Data (if any)

TCP Segment Format(code Bits)
Bit position Name function URG urgent pointer field valid ACK acknowledgment field valid PSH deliver data on receipt of this segment RST reset the sequence/acknowledgment numbers SYN synchronization FIN end of byte stream from sender

Port number: addressing application
A connection is identified uniquely by 5 elements. (sender IP address, receiver IP address, protocol number, sender application process port number, receiver application process port number) The combination of an IP address and a port number is sometimes called socket. AP AP Port AP AP TCP connection TCP UDP TCP UDP protocol TCP user TCP가 서비스를 제공하는 응용 프로그램을 의미한다. 달리 표현하면 인터넷 상에서 서비스를 제공하는 서버를 의미한다. TCP 종점 주소 두 가지 level로 나타내어 진다. 네트워크 접속점 주소 TCP 사용자 주소 네트워크 접속점 주소는 IP 호스트 주소가 된다. 이 주소는 글로벌 인터넷에서 유일한 접속점을 나타낸다. TCP 연결 identifier <송신측 TCP 종점 주소, 수신측 TCP 종점 주소> 즉 <송신측 IP 주소, 송신측 TCP 사용자 주소, 수신측 IP 주소, 수신측 TCP 사용자 주소> IP addr IP IP IP H/W addr Network access Network access Network access subnet subnet

Connection Identification addresses
IP address identifies a specific host in the Internet. has 1:1 mapping to the subnet physical address that the host is connected to. Protocol number identifies an upper layer protocol to which IP in the destination host should send data. Port number identifies an application process to which the receiver IP should deliver data . well-known port numbers the port numbers that were already decided by ICANN for their uses such as FTP server is 21, Telnet server is TCP 23, etc. Ephemeral number port numbers that is assigned temporarily for application processes established presently.

Well Known TCP Ports(/etc/services)
Keyword UNIX keyword Description Reserved 1 TCPMUX - TCP Multiplexor 5 RJE - Remote Job Entry 7 ECHO echo Echo 9 DISCARD discard Discard 11 USERS systat Active Users 13 DAYTIME daytime Daytime netstat Network status program 17 QUOTE qotd Quote of the day 19 CHARGEN chargen Character Generator 20 FTP-DATA ftp-data File Transfer Protocol 21 FTP ftp File Transfer Protocol 23 TELNET telnet Terminal Connection 25 SMTP smtp Simple Mail Transport Protocol 37 TIME time Time 42 NAMESERVER name Host Name Server 43 NICNAME whois Who Is 53 DOMAIN nameserver Domain Name Server rje any private RJE service 79 FINGER finger Finger 93 DCP - Device Control Protocol 95 SUPDUP supdup SUPDUP Protocol

Sequence Number TCP user TCP
Segment number identifies the byte in the stream of data from the sending TCP to the receiving TCP, It represents the first byte of data in the segment. The unit is not segments, but bytes.. The size is 232 large enough to detect duplicate segments. TCP user TCP SEND (200 byte data) [seq=300, data] SEND (150 byte data) [seq=500, data] SEND (100 byte data) [seq=650, data]

Acknowledge Number Accumulative ACK Sender TCP Receiver TCP
By convention, the ACK number is the byte number of the segment that the receiver expects to receive next time. Sender TCP Receiver TCP [seq=1000, 100 byte data] [seq=1100, 200 byte data] [seq=1300, 100 byte data] [ACK=1400]

Duplicate segments in the same connection
Transport Entity A Transport Entity B SN0 SN1 SN2 A times out and retransmits SN0 SN0 A times out and retransmits SN1 SN1 ACK3 SN3 ACK3 SN4 ACK4 Solution: sequence number space should be large enough 위의 그림과 같은 문제점을 해결하기 위해서는 순서공간이 충분히 커야 함. SN5 ACK5 assumption: - seq. number: mod 8 - use the accumulative ACK SN6 ACK6 SN7 ACK7 ACK0 SN0 Obsolete SN0 arrives New SN0 arrives

Duplicate segments in different connections(1)
Transport entity A Transport entity B SN 2 Old connection closed SYN SYN New connection opened SN 0 SN 1 Obsolete segment SN = 2 is accepted; SN 2 valid segment SN = 2 is discarded as duplicate

Duplicate segments in different connections(2)
Global numbering If the sequence number of the last segment of the previous connection is N, new connection use the first sequence number that is distant from N. TCP should remember the sequence number that was used in the last segment. 2 MSL Timer When TCP connection closes, new TCP connection is not allowed to open immediately. New connection can open after the amount of time has passed. TCP implementation choose a value for the maximum segment life time(MSL). It is the max. amount of time any segment can exit in the network before being discarded. TCP connection can be reused after 2MSL wait is over.

Window Field This field is used for TCP flow control (often called “Credit technique”). It is used for a receiver to notify a sender of the size of empty space in the receiver TCP buffer. The unit is bytes. If the buffer size is larger than 216, it can be extended using the option field. Its use is independent of the use of the acknowledge number field that denotes the success of failure of segment transmission.

PUSH Background PSH flag
Normally, when the sending TCP receives data from the sending application process, TCP does not send the data immediately. Instead it stores the data in the its buffer, waiting for additional data arrive for the prevention of Silly Window Syindrom. In the interactive application, however, the sending TCP is required to send data immediately. PSH flag The sending application process tells its TCP when to set the PUSH flag. It is a notification to the sending TCP that the sending application process don’t want the data to hang around in the TCP buffer, waiting for additional data to fill the buffer. When the receiver TCP receives the segment with the PSUH flag, it pass data to the receiver application process, telling not to wait until any additional data The Socket API don’t provide a way for the application to tell its TCPto set the PUSH flag. Setting this flag is up to the TCP implementation. BSD implementations ignores a received PUSH flag because they normally never delay the delivery of received data to the application.

URGENT Bit & Urgent Pointer
Urgent mode The sending TCP tell the other TCP that urgent data of some form has been placed into the normal stream of data. The receiving TCP notifies the receiving application of the arrival of urgent data. The application process will decide what to do on its own way. The URG bit is turned on and the urgent pointer is set to a positive offset that must be added to the sequence number field in the TCP header to obtain the sequence number of the last byte of urgent data. In the socket API, sending application process can set this bit using SO OOB. What is urgent mode used for? The two most common uses are Telnet and Rlogin when interactive uses type the interrupt key(etc, ^C). Another is FTP, when interactive users abort a file transfer.

TCP Option Fields MSS (Maximum Segment Size) option
The maximum size of the data transmitted When a connections established, each end can announce the MSS it expects to receive. An MSS option can only appear in a SYN segment. If one end does not receive an MSS option form the other end, a default of 536 bytes is assumed. 576 (IP datagram default size) - 40 (IP/TCP header fixed size) In general, the larger the MSS the better, until fragmentation occurs. Window Scale Option It increase the window size. It means the maximum window size can be 216x216=232. New window size = window size defined in the header x 2window scale factor The window size factor can be determined only during the connection setup phase. Time stamp option The sender fills the time stamp value when the segment leaves. When the receiver sends an ACK for this segment, it enters the time stamp value that it receives from the sender. When the sender receives the ACK, it can calculate the round trip time for this segment.

Destination IP address
Checksum The checksum applies to three parts: pseudo-header, TCP header, and the data coming form the application process) Checking the pseudo-header prevent packets from being delivered to wrong hosts due to the corruption of the IP header. Divide the total bits into 16-bit words. Add all 16-bit sections, using one’s complement arithmetic. 16 31 Source IP address Pseudo-header Destination IP address Checksum scope zero Protocol id Segment length TCP header TCP segment User Data

TCP summary Connection establishment Connection termination
3 way handshake Connection termination support graceful close using the 3 way handshake. also support abrupt close using ABORT primitive. Data transfer Each segment is assigned a sequence number with the unit of byte. Error control by retransmission: selective repeat Flow control by credit allocation PUSH URGENT POINTER Reset service RST

TCP Primitives primitive type Client/ Server Parameters
UNSPECIFIED_PASSIVE_OPEN FULL_PASSIVE_OPEN ACTIVE_OPEN ACTIVE_OPEN_WITH_DATA OPEN_ID OPEN_SUCCESS OPEN_FAILURE SEND DELIVER ALLOCATE CLOSE CLOSING TERMINATE ABORT STATUS STATUS_RESPONSE ERROR type Request Request Local response Confirm Indication Response Indicator Client/ Server S C C/S Parameters Source port, timeout, timeout-action, precedence, security range Source port, destination port, destination address, timeout, timeout-action, precedence, security range Source port, destination port, destination address, data, data length, push flag, urgent flag, timeout, timeout-action, precedence, security range Local connection name, source port, destination port, destination address Local connection name Local connection name, data, data length, push flag, urgent flag, timeout, timeout-action Local connection name, data, data length, push flag, urgent flag Local connection name, data length Local connection name, reason code Local connection name, source port, source address, destination address, connection state, receive window, send window, waiting ack, waiting accept, urgent, precedence, security, timeout

Usage of TCP Service Primitives
Client-IP-server Initiating(client)protocol Responding(server)protocol UNSPECIFIED_PASSIVE_OPEN ACTIVE_OPEN + ACTIVE_OPEN_WITH_DATA FULL_PASSIVE_OPEN + Connection establishment OPEN_ID OPEN_RECEIVED + OPEN_SUCCESS + OPEN_FAILURE SEND + + DELIVER Data transfer + + SEND DELIVER ALLOCATE ALLOCATE + + STATUS STATUS + Status/error reporting + STATUS_REPORT STATUS_REPORT + + ERROR ERROR CLOSE + + CLOSING + CLOSE + TERMINATE Connection clearing + TERMINATE ABORT + + TERMINATE

TCP timer UDP

TCP Connection setup and release
client server SYN SYN, ACK ACK Application close FIN Deliver EOF to application ACK Application close FIN ACK

TCP Connection Setup : 3 Way Handshake
Client-Server model Client TCP TCP Server ACTIVE_OPEN PASSIVE_OPEN Send SYN SYN=1, Seq=X Send SYN SYN=1, ACK=1, Seq=Y, ack=X=1 OPEN_RECEIVED Send ACK OPEN_SUCCESS ACK=1, Ack=Y+1

TCP Connection Setup : 3 Way Handshake
Simultaneous open ACTIVE_OPEN ACTIVE_OPEN SYN=1, Seq=Y Send SYN Send SYN SYN=1, Seq=X Send ACK Send ACK ACK=1, Ack=Y+1 ACK=1, Ack=X+1 OPEN_SUCCESS OPEN_SUCCESS

Robustness of 3 Way Handshake
SYN k, ACK p SYN i SYN j, ACK i RST, ACK j Obsolete SYN arrives B accept and acknowledges A rejects B’s connection (a) Delayed SYN SYN i A initiates a connection. Old SYN arrives at A; A rejects RST, ACK k B accepts and acknowledge SYN j, ACK i ACK j A acknowledges and begins transmission SN i+1 (b) Delayed (SYN, ACK)

TCP Half-Close: Graceful Disconnection
client server Application shutdown FIN Deliver EOF to application ACK of FIN Application write data Application read ACK of data Application close FIN Deliver EOF to application ACK of FIN

TCP Connection Release: 3 Way Handshake
Client side Server side (a) Client TCP TCP Server ---- CLOSE FIN = 1, seq = X Send FIN Send ACK ACK = 1, ack = X+1 CLOSING Send FIN FIN=1,seq=Y CLOSE Send ACK TERMINATE ACK=1,ack=Y+1 연결 해제 전송을 끝 낸 응용 프로그램은 연결 종료를 시도한다. 이 때 TCP는 FIN bit를 on하여 보낸다. Two-army 문제를 피하기 위해서 timer를 사용한다. FIN에 대한 응답이 주어진 시간 안에 도착하지 않으면 FIN을 보낸 TCP는 자동적으로 연결을 해제한다. Active close를 수행한 TCP는 2 MSL(Maximum segment lifetime) 동안 TCP 연결을 유지한다. 그 이유는 아직 전송 중인 세그먼트가 존재할 수 있기 때문이며 그래서 TCP 연결 identifier를 일정 시간 동안 그대로 유지하여 다른 사용자가 사용할 수 없도록 한다. ---- TERMINATE (b) ABORT Send RST RST = 1 TERMINATE

Connection Release: 3 Way Handshake
Graceful disconnection – 3 way handshake Since the TCP connection is full-duplex, when one end request termination, one way connection is terminate. But the other way connection can be maintained while the other end keeps sending data. Abrupt disconnection One-sided termination because of network failure, etc. In this case data can be lost.

Connection Release: 3 Way Handshake
Graceful disconnection – 3 way handshake Problem due to out-of-sequence The one end sends FIN after sending the last segment. But the FIN segment arrives ahead of the last segment. In this case, if the receiver TCP terminates as soon as it receives the FIN, the receiver loses the segment that arrives after connection closure. To prevent this kind of loss, TCP assigns the sequence number to FIN segment, which have the number incremented from the sequence number of the last segment.. When the other end is not cooperative to the termination request, The requesting end terminates the connection when the timer times out.

Crash & Connection Release
The half-open can happen when any end of the connection breaks down, since the other end cannot know the other end’s failure. In the half-open, the other end keeps retransmitting segments allowed. If no reply arrives until the keepalive timer expires, it terminates the connection. The TCP end that has broken down can terminate using RST segment after rebooting. Since the rebooting TCP has lost all state information, it should send RST segments for all segment it received, and the other end that received RST segments must terminate the connection immediately.

TCP Entity State Diagram
Unspecified Passive Open or Fully Specified Passive Open Active Open or Active Open with Data SYN RECEIVE CLOSED ESTAB Initialize SV; Send SYN Initialize SV Close Clear SV Close Clear SV SYN SENT Receive SYN Receive SYN LISTEN Send SYN ACK Send SYN ACK Receive ACK of SYN Receive SYN,ACK Send ACK Receive FIN,ACK of SYN Send ACK LEGEND SV = state vector MSL = maximum segment lifetime Close Send FIN Receive FIN Send ACK FIN WAIT LAST ACK CLOSE WAIT CLOSED Receive ACK of FIN Receive FIN Send ACK Receive SYN,ACK Send ACK Close Send FIN FIN WAIT 2 CLOSING Receive FIN,ACK Send ACK Receive ACK of FIN Receive FIN Send ACK Timeout (2MSL) TIME WAIT

TCP timer UDP

TCP Traffic Control Traffic control
There are two reasons for sender to reduce the rate of sending packets. When receiver’s buffer space is not enough,  flow control When the network is congested,  congestion control network congestion Small-capacity receiver

Sliding Window Flow Control
Segments sent, but not acknowledged Segments that can be sent 1 2 3 Window is shrinking as the segments are sent Window expands as the acks are received (a) sender’s window Segments that were received Segments that will be received 1 2 3 The last segment That was acked Window is shrinking as the segments are received Window expands as acks are sent (b) receiver’s window

Is the sliding window scheme enough?
window size = 3 1 2 3 1 2 3 I(0) 1 2 3 1 2 3 I(1) I(2) 1 2 1 2 3 1 2 3 1 2 3 1 2 3 Window closed Window closed ACK(2) 1 2 3 1 2 3 1 2 3 1 2 3 I(0) I(3) I(1) 1 2 3 1 2 3 3 1 1 2 3 1 2 3 Window closed ACKs not sent Window closed, BUSY CONDITION TIMEOUT I(0) I(3) I(1) Retransmit I(3),I(0),I(1) Make the receiver’s state worse!!

What is wrong with the sliding window?
No distinction between the ACK and the current available buffer size. When the receiver TCP receives segments uncorrupted and stores them in the buffer, but does not finish processing them, If the TCP doesn’t send any ACK, then the sender’s timer expires and try to retransmit the segments. ==> It causes unnecessary loads to network! Otherwise, if the TCP sends ACKs, then the sender transmits new segments, which may be discarded eventually. ==> aggravate the receiver’s condition! Solution: credit allocation protocol It distinguishes the ACK from the credit information. The ACK information informs the sender of successful transmission, while the credit information notifies the sender of the its current empty buffer size.

Credit Allocation Protocol
window size = 3 1 2 3 1 2 3 I(0) I(1) 1 2 3 1 2 3 I(2) 1 2 1 2 3 1 2 3 1 2 3 1 2 3 Closing Window Closing Window ACK 2, CDT 3 1 2 3 1 2 3 1 2 3 1 2 3 I(0) I(3) I(1) 1 2 3 1 2 3 3 1 1 2 3 1 2 3 Closing Window ACK 1, CDT 0 Closing Window, BUSY CONDITION TIMEER Not retransmit I(3),I(0),I(1) 1 ACK 1, CDT 2 1 2 3 1 2 3 1 2 3 I(2) IDLE CONDITION I(3) Open Window

Example of TCP Credit Allocation Mechanism.
Transport Entity A Transport Entity B 1001 2400 A may send 1400 octets 1601 .…2600 2601 2001 2600 2601…. 4000 4001.… A shrinks its transmit window with each transmission A adjusts its window with each credit A exhausts its credit A receive new credit B is prepared receive 1400 octets, beginning with 1001 B acknowledges 3 segments (600 octets) but is only B acknowledges 5 segments (1000 octets) and through 2600 original budget (I.e., B will accept octets 1601 prepared to receive 200 additional octets beyond the restore the original amount of credit SN = 1001 SN = 1401 A = 1601, W = 1000 SN = 1601 SN = 2001 A = 2601, W = 1400 SN = 1201 SN = 1801 SN = 2201 SN = 2401

Too Small Data & Immediate Window Update
Example of TELNET When data arrives from application, if the sender TCP transmit it immediately, or the receiver TCP sends window update right after its buffer changes, then they have to exchange segments frequently, but do little. A keystroke arrive 41 bytes IP packets 40 bytes ACK Application read 1 byte of keystroke 40 bytes window update Application echoes it TCP는 응용 프로그램에서 데이터가 도착했을 때 바로 세그먼트로 만들어 전송할 필요가 없다. 또한 도착한 세그먼트에 대해서 바로 즉시 ACK를 보낼 필요도 없다. 위의 예는 응용 프로그램에서 데이터가 도착했을 때 이를 즉시 세그먼트로 보내는 경우, 그리고 버퍼의 변화에 대해서 이를 즉시 알려 주는 경우의 문제점을 보여 주고 있다. Nagle’s algorithm 데이터가 한 번에 한 byte씩 도착하면 먼저 첫번째 바이트를 전송하고 나머지는 버퍼에 모아 둔다. 그리고 첫번째 바이트에 대한 응답을 받았을 때 버퍼에 있는 데이터를 하나의 세그먼트로 만들어 전송한다. 그리고 이것에 대한 응답을 받을 때까지 나머지 바이트들은 다시 버퍼에 저장한다.

Silly Window Syndrome(caused by Receiver)
Receiver’s buffer is full Application reads 1 byte Window update segment sent New byte arrives Header Room for one more byte 1 byte Silly window syndrome 수신측 TCP가 버퍼의 변화를 즉시 상대편에 알려 줄 경우 발생하는 비효율성이다. 위의 그림은 응용 프로그램이 한 번에 한 바이트씩 TCP 버퍼의 데이터를 읽어 드릴 경우의 문제점을 보여 주고 있다. Clark’s solution 수신측 TCP는 최대 세그먼트 크기가 버퍼에 모여지거나 버퍼가 반이 찰 때까지(더 작은 쪽을 선택해서) window update를 상대편에 보내지 않는다.

Silly Window Syndrome(caused by Sender)
Sender’s Buffer is empty Application writes 1 byte Sender’s buffer has 1 byte. Header 1 byte TCP sends 1 byte. Silly window syndrome 수신측 TCP가 버퍼의 변화를 즉시 상대편에 알려 줄 경우 발생하는 비효율성이다. 위의 그림은 응용 프로그램이 한 번에 한 바이트씩 TCP 버퍼의 데이터를 읽어 드릴 경우의 문제점을 보여 주고 있다. Clark’s solution 수신측 TCP는 최대 세그먼트 크기가 버퍼에 모여지거나 버퍼가 반이 찰 때까지(더 작은 쪽을 선택해서) window update를 상대편에 보내지 않는다.

Avoiding SWS from the sender
Background Suppose the case that data from application arrives at TCP 1 byte at a time. In that case TCP does not need to send small segment immediately every time it receives data. Nagle’s algorithm If data arrives 1 byte at a time, TCP sends the first byte in a small segment, and collect the next bytes in its buffer. TCP sends the data in the buffer as a single segment when the ACK for the first segment arrives. And TCP store the next bytes in the buffer again until it receives the ACK for the segment.

Avoiding SWS from the receiver
Clark’s solution The receiver TCP does not send window update until before its buffer is half empty or the size of data in the buffer becomes as large as the MSS. Delayed ACK TCP does not send an ACK the moment it receives a segment. Instead, it delays the ACK, hoping to have data going to the same host as the ACK for piggybacking. Most implementations use a 200 ms delay.

TCP timer UDP

Congestion Control Background
Too much traffic has been injected into the network. The traffic inflow at this moment is exceeding the capacity that the network can accommodate. So, the solution is simple. The traffic influx should be pull down below the network capacity level. But the rate should be reduced way ahead of reaching the full capacity level. (need very early action!!) How can the network detect the early symptom of the congestion? Monitoring the buffer size of network nodes (eg, routers) Keeping track of the round-trip time of packets

TCP and congestion control
In the Internet, TCP is responsible for the congestion control. (It is somewhat odd!) Then, how does TCP detect the congestion? Timeout: No ACKs has arrived until timer expires. The timeout can be triggered by two occasions: One is the transmission error, and the other is packet loss by congestion. But in the current network, the transmission error happens very rarely, so we give the congestion the benefit of the doubt. TCP Congestion control methods Slow start Congestion avoidance Fast retransmit Fast recovery

Initial rate is slow, but ramp up exponentially fast.
Slow Start Control parameters Awnd (advertised window by receiver) At the initial setup, the sender informs the receiver of its maximum buffer size, which is the initial value of awnd. Every time the sender transmits an ACK, it advertises its current available buffer size. Cwnd (congestion window) Determine how many segments can be sent without receiving ACKs.. Slow Start Initialize: cwnd = 1 MSS (max. segment size); Every time each ACK arrives: cwnd = cwnd + 1 MSS until min(cwnd, awnd) /* exponential growth */ TCP는 window를 통해 데이터의 흐름을 조절한다. Window 어느 순간에 상대편으로부터 데이터를 받을 수 있는 버퍼의 크기 window advertisement 상대편에게 window의 크기, 즉 가용 버퍼의 크기를 알려 주는 것을 말한다. 매번 ACK 세그먼트를 보낼 때 마다 window advertisement를 한다. Slow start 두개의 파라메터에 의한다.(단위는 세그먼트의 수) Receiver’s advertisement window(awnd) 처음 연결이 설정되면 수신측은 송신측에 자신의 버퍼의 크기를 알려 준다. 초기의 awnd는 이 값으로 할당된다. Congestion window(cwnd) 현재의 순간에 송신측의 window 크기 초기에 cwnd =1 로 할당한다. Initial rate is slow, but ramp up exponentially fast.

Effect of Slow Start ... ..... receiver sender Cwnd = 1 Segment 1
ACK 2 Cwnd = 2 Segment 2 Segment 3 ACK 3 Cwnd = 3 ACK 4 congestion window(cwnd) 따라서 송신 TCP는 처음부터 수신측 TCP의 window 크기만큼 세그먼트를 보내는 것이 아니라 1 세그먼트부터 보내기 시작한다. 송신한 세그먼트에 대한 ACK을 받으면 cwnd를 하나씩 증가시킨다. 이렇게 점차적으로 증가된 cwnd의 값은 awnd의 값 보다 클 수는 없다. 이러한 증가는 exponential growth의 형태가 된다. 위의 그림은 cwnd가 증가되는 모습을 보여 주고 있다. Cwnd = 4 Segment 4 ... Segment 7 ACK 5 ..... ACK 8 Cwnd = 8

Congestion Avoidance If no ACKs arrive until timeout, TCP starts the Congestion Avoidance algorithm. Congestion Avoidance algorithm If (segment timeout) { 1. Set ssthresh = cwnd / 2 /* slow start threshold */ 2. Set cwnd = 1 MSS Restart “slow-start” until (cwnd=ssthresh) 3. If (cwnd  ssthresh) cwnd = cwnd + 1 MSS every roundtrip time } congestion avoidance timeout될 때까지 응답이 돌아오지 않으면 체증 발생으로 판단하고 congestion avoidance를 수행한다. 먼저 ssthresh=cwnd/2로 한다. 그리고 cwnd =1 로 한다. 즉 다시 처음 단계로 부터 다시 시작한다. 그리고 cwnd가 ssthresh될 때까지는 slow start 절차를 수행하고 그 이상이 되면 왕복 지연 시간 마다 cwnd를 하나씩 증가한다. 즉 일단 체증이 발생하면 이것이 복구되는데 시간이 걸린다고 가정하고 보수적인 방법을 취하게 된다.

Slow Start and Congestion Avoidance
CWND=1 B A CWND=1 B CWND=2 CWND=2 CWND=3 CWND=3 CWND=4 CWND=4 CWND=5 CWND=5 CWND=6 CWND=6 CWND=7 CWND=7 CWND=8 CWND=8 CWND=9 Congestion avoidance CWND=10 CWND=11 CWND=12 CWND=9 CWND=13 CWND=14 CWND=15 CWND=16 CWND=10 (a) Slow start, ending with a time out (b) Slow start followed by congestion avoidance

Slow Start and Congestion Avoidance
cwnd Round-trip times 15 20 5 2 1 10 4 3 12 6 9 8 7 13 11 16 14 Time out occurs Threshold

Fast Retransmission and Fast Recovery
Background TCP is required to generate an immediate acknowledgement (a duplicate ACK) when an out-of-order segment is received. We don’t know whether a duplicate ACK is caused by a lost segment or just a reordering of segments. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. Three or more duplicate ACKs implies that there is a flow of segments over the network. Therefore the Congestion Avoidance is too conservative approach to this case. Fast retransmission If 4 consecutive ACKs are received before timeout, then TCP do not wait for the timeout and retransmit the segment immediately. congestion avoidance timeout될 때까지 응답이 돌아오지 않으면 체증 발생으로 판단하고 congestion avoidance를 수행한다. 먼저 ssthresh=cwnd/2로 한다. 그리고 cwnd =1 로 한다. 즉 다시 처음 단계로 부터 다시 시작한다. 그리고 cwnd가 ssthresh될 때까지는 slow start 절차를 수행하고 그 이상이 되면 왕복 지연 시간 마다 cwnd를 하나씩 증가한다. 즉 일단 체증이 발생하면 이것이 복구되는데 시간이 걸린다고 가정하고 보수적인 방법을 취하게 된다.

Fast Retransmit A B Elapsed time less than current RTO SN=1001 A=801
SN=1201(lost) SN=1401 SN=1601 SN=1801 SN=2001 SN=2201 SN=2401 SN=2601 SN=1201(retransmission) SN=2801 SN=3001 SN=3201 A=801 A=1001 A=1201 A=2801 A=2601 Elapsed time less than current RTO

Fast Recovery Fast recovery algorithm (avoiding initial slow start phase) 1. When the third duplicate ACK is received, Set ssthresh = cwnd / 2; Retransmit the missing segment; cwnd = ssthresh + 3 ; 2. Each time another duplicate ACK arrives, Increment cwnd by the segment size; Transmit a new segment (if allowed by the new cwnd value); 3. When the next ACK arrives that acknowledges new data, cwnd = ssthresh ; cwnd = cwnd + 1 every roundtrip time ; congestion avoidance timeout될 때까지 응답이 돌아오지 않으면 체증 발생으로 판단하고 congestion avoidance를 수행한다. 먼저 ssthresh=cwnd/2로 한다. 그리고 cwnd =1 로 한다. 즉 다시 처음 단계로 부터 다시 시작한다. 그리고 cwnd가 ssthresh될 때까지는 slow start 절차를 수행하고 그 이상이 되면 왕복 지연 시간 마다 cwnd를 하나씩 증가한다. 즉 일단 체증이 발생하면 이것이 복구되는데 시간이 걸린다고 가정하고 보수적인 방법을 취하게 된다.

Fast Retransmission and Fast Recovery
seq # & cwnd cwnd sequence number send time (sec)

TCP timer UDP

Round Trip Time & Timeout
RTT is important because the timeout value is determined based on RTT. RTT can change over time as route might change and as network traffic changes. So, TCP should track these changes and modify its timeout accordingly.

Round Trip Time & Timeout
Original TCP specification RTT(n+1) = a * RTT(n) + (1-a) * RTT_SAMPLE(n) /* recommendation : a=0.9 */ RTO = b * RTT(n+1) /* recommendation : b = 2 */ RTO: Retransmission Timeout value RTT_SAMPLE : measured RTT Karn’s algorithm We cannot update the RTT estimation when an ACK for retransmitted segment arrives because we don’t know to which segment the ACK corresponds, the original one or the retransmitted one? Don’t calculate a new RTO until an acknowledgement is received for a segment that was not retransmitted. Set the timeout after retransmission as follows: Timeout = 2 * RTT(n) /* exponential growth */ After the ACK for the retransmitted segment arrives, restart the calculation of RTT_SAMPLE. Retransmission timer 정확한 양 종단간의 세그먼트의 왕복 지연 시간(RTT)을 사용한다는 것은 TCP의 동작에서 매우 중요한 과제이다. 세그먼트에 timestamp 값을 실어서 매번 실제 RTT값을 측정한다. 하지만 실제 상황에서 망의 상황에 따라서 RTT 값은 변한다. 따라서 매번 측정된 RTT 값과 이제까지의 RTT 값을 사용하여 보정된 값을 사용한다. 이 값을 구하는 방법은 다음의 세 가지가 있다. RTT variance estimation Exponential RTO backoff Karn’s algorithm

Jacobson’s Algorithm Background Jacobson’s algorithm
We can have better performance when we consider variance together rather than use simple RTT average values alone. Jacobson’s algorithm DIFF(n+1) = RTT_SAMPLE(n+1) - RTT(n) DEV(n+1) = DEV(n) + h * (|DIFF(n+1)| - DEV(n)) /* typically h = 1/8 */ RTT(n+1) = RTT(n) + g * DIFF(n+1) /* typically g = 1/4 */ Timeout(n+1) = RTT(n+1) + 4 * DEV(n+1)

TCP Timers Retransmission timer Persist timer Keepalive timer
2MSL timer

Retransmission Timer It is used for determining how long the TCP sender wait for retransmission (timeout). In the real implementation, there are not each timer operating for each segment. There is only one timer for each connection.

TCP Persist Timer Background Solution
When the TCP receiver advertises window = 0, the TCP sender stops sending temporarily. Afterwards, the receiver lets the sender know it can receive segments again by sending new window advertisement. But if this new window advertisement is lost, the sender will wait for the new advertisement forever. (Deadlock!!) Solution After the sender knows window=0, the sender transmits window probe segment periodically to check out if the receiver is ready to accept. The window probe is sent according to the persist timer. Window probe is a segment of 1 byte length. TCP allows sender to transmit one byte even if the receiver’s window is closed. TCP persist timer is increasing exponentially.

(normal TCP Exponential backoff)
TCP Persist Timer win=0 window probe win=0 ACK(win=0) win=256 window probe lost ACK(win=0) Deadlock window probe ACK(win=0) Persist Timer (normal TCP Exponential backoff)

TCP Keepalive Timer If there is no activity on a given connection for a period of time, the server sends a probe segment to see if the client is still alive. The keepalive timer specifies the interval at which the server want to know if client’s host has either crashed or is down. The interval is normally 2 hours. When the Keepalive timer expires, the server sends a probe segment: (1) if the client is still alive, It will respond and there will be no more prove for next 2 (2) if the client is down, It times out after 75 seconds, and the server sends a total of 10 probes, 75 seconds apart, and if no response, the server terminates the connection. (3) if the client is rebooted, There is a response for the probe, but the reponse will be a reset.  terminating the connection (4) if the client is alive but not unreachable, same as in case (2)

2 MSL Timer 2 MSL(Maximum Segment Lifetime) Quiet time concept
It is the maximum amount of time any segment can exist in the network before being discarded. When TCP performs an active close and sends the final ACK(reponse to the FIN), that connection must stay in the TIME_WAIT state for twice the MSL. If the final ACK is lost, the other TCP can resend the FIN segment. And, new TCP connection will open after 2 M니. (Some systems prevents from using the port numbers existed during 2 M니) Quiet time concept Suppose that a host crashed before the timeout while it is in the 2 MSLwait state, and then rebooted immediately. If the host open a new TCP connection as soon as it reboot, it cannot distinguish old segment in the previous connection from new segments in the new connection. To avoid this confusion, TCP is not allowed to open new connection for 1 MSL right after rebooting. This 1 MSL time is called quiet time.

2 MSL Timer (b) Closing simultaneously
FIN m FIN m FIN n ACK m+1 SN n-1 ACK n+1 ACK m+1 FIN n ACK n closed closed ACK n+1 closed Wait for 2 MSL and then terminate closed Wait for 2 MSL and then terminate (a) Closing connections sequentially (b) Closing simultaneously

TCP timer UDP

UDP Addressing and checksum
Providing unreliable service to application Datagram-oriented one application data -> one UDP datagram

UDP Header Data (if any) 16-bit source port number
IP datagram UDP datagram IP header UDP header UDP data 20 octets 8 octets Data (if any) 16-bit source port number 16-bit destination port number 16-bit Length 16-bit Checksum 8 octets

A Few Well-known UDP Ports
Decimal Keyword UNIX Keyword Description Reserved 7 ECHO echo Echo 9 DISCARD discard Discard 11 USERS systat Active Users 13 DAYTIME daytime Daytime netstat Who is up or NETSTAT 17 QUOTE qotd Quote of the Day 19 CHARGEN chargen Character Generator 37 TIME time Time 42 NAMESERVER name Host Name Server 43 NICNAME whois Who is 53 DOMAIN nameserver Domain Name Server 67 BOOTPS bootps Bootstrap Protocol Server 68 BOOTPC bootpc Bootstrap Protocol Client 69 TFTP tftp Trivial File Transfer 111 SUNRPC sunrpc Sun Microsystems RPC 123 NTP ntp Network Time Protocol snmp SNMP net monitor snmp-trap SNMP traps biff UNIX comsat who UNIX rwho daemon syslog system log timed Time daemon

TCP and UDP UDP TCP connectionless connection-oriented
Unreliable services No error control and no flow control datagram-oriented Good for short data or data that is permissible to error TCP connection-oriented Reliable service provisioning Error control and flow control stream-oriented Good for stable transmission of long persistent data 인터넷의 트랜스포트 프로토콜에는 두 가지가 있다. TCP(Transmission Control Protocol) UDP(User Datagram Protocol) TCP는 앞에서 언급한 바와 같이 보장성 서비스(reliable service)를 응용 프로그램에 제공해 주기 위한 것이다. 따라서 다음의 기능을 수행한다. Flow control error control congestion control 패킷 순서 보장 UDP는 또 다른 트랜스포트 프로토콜로서 비보장성 서비스(unreliable service)를 제공해 준다. UDP는 TCP에 비해 그 기능이 매우 단순하다. 따라서 datagram-oriented 응용 서비스는 TCP와 같은 많은 기능을 수행하는 것이 비효율적일 수 있으며 오히려 UDP와 같은 단순한 트랜스포트 프로토콜을 사용하는 것이 훨씬 효율적일 수 있다.

TCP.

Similar presentations

Presentation on theme: "TCP."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

TCP.

Similar presentations

Presentation on theme: "TCP."— Presentation transcript:

Similar presentations

About project

Feedback