CSS 432 EndtoEnd Protocols Textbook Ch 5 1

CSS 432 End-to-End Protocols Textbook Ch 5. 1 – 5. 2 Prof. Athirai Irissappane http: //courses. washington. edu/css 432/athirai/ athirai@uw. edu CSS 432: End-to-End Protocols 1

Outline n Transport Layer Protocols Communication between applications running in the end nodes hence end-to-end protocols ¨ How to convert host-to-host packet delivery service into a process-to-process communication channel ¨ n n Simple Demultiplexer (UDP) Reliable Byte Stream (TCP) CSS 432: Internetworking 2

End-to-End Protocols n Common properties that a transport protocol can be expected to provide ¨ Guarantees message delivery ¨ Delivers messages in the same order they were sent ¨ Delivers at most one copy of each message ¨ Supports arbitrarily large messages ¨ Supports synchronization between the sender and the receiver ¨ Allows the receiver to apply flow control to the sender ¨ Supports multiple application processes on each host CSS 432: Internetworking 3

End-to-End Protocols n Typical limitations of the network on which transport protocol will operate ¨ ¨ ¨ n Drop messages Reorder messages Deliver duplicate copies of a given message Limit messages to some finite size Deliver messages after an arbitrarily long delay Challenge for Transport Protocols ¨ Develop algorithms that turn the above limitations into the high level of service required by the application M 5, and M 3 Request a retransmission of M 3 and M 5, M 3 M 5, M 4, M 3, M 2, M 1 M 5, M 2, M 1 M 4, M 3 M 2, M 1, M 4 M 3 4

Simple Demultiplexor (UDP) n n Extends host-to-host delivery service of the underlying network into a process-to-process communication service Adds a level of demultiplexing which allows multiple application processes on each host to share the network Unreliable and Unordered Datagram Service No flow control: preventing senders from overrunning the capacity of the receivers (messages are discarded if the receiving buffers are full) CSS 432: End-to-End Protocols 5

Simple Demultiplexor (UDP) n n n Identify each process by port id associated to the sender and receiver Endpoints identified by ports ¨ servers have well-known ports 16 ¨ see /etc/services file on Unix 0 Src. Port Header format Checksum 31 Dst. Port Length Data n Optional checksum ¨ ¨ Calculated using psuedo header + UDP header + data Pseudoheader: IP header (protocol number) + source IP + destination IP, UDP length field CSS 432: End-to-End Protocols 6

UDP: Simple Demultiplexer int sd; sd = socket(AF_INET, SOCK_DGRAM, 0); socket() struct sockaddr_in server; struct hostent *hp, *gethostbyname( ); Server. sin_family = AF_INET; hp = gethostbyname( ); bcopy( hp->h_addr, &( server. sin_addr. s_addr ), sizeof( hp->h_length) ); server. sin_port = htons( 13579 12345 ); sendto( sd, buf, sizeof( buf ), 0, (struct sockaddr *)&server, sizeof( server ) ); socket() struct sockaddr_in server; server. sin_family =AF_INET; server. sin_addr. s_addr = htonl( INADDR_ANY) 13579 ); server. sin_port = htons( 12345 bind( sd, (struct sockaddr *)&server, sizeof( server ) ); bind() Port: 12345 Port: 13579 recv( sd, buf, sizeof( buf ), 0 ); recv() sendto() Packets demultiplexed UDP M 5, M 4, M 3, M 2, M 1 CSS 432: End-to-End Protocols 7

End-to-End Protocols n Common end-to-end services ¨ ¨ ¨ ¨ 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 support multiple application processes on each host P 1 P 2 P 3 P 4 M 5, M 4, M 3, M 2, M 1 Network m 5, m 4, m 3, m 2, m 1 CSS 432: End-to-End Protocols 8

TCP Overview n n n Connection Oriented It guarantees that all sent packets will reach the destination in the correct order Use of ACK packets, re-transmission, time out Full duplex: bi-directional, send and receive at each end Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning network CSS 432: End-to-End Protocols 9

TCP (Reliable Byte Stream) n n Application process Write bytes … n Byte-oriented protocol, sender writes bytes into a TCP connection and the receiver reads bytes out of the TCP connection. Byte Stream: Not individual bytes source application buffers enough bytes from the sending process to fill a reasonably sized packet (segment) and sends to destination Destination empties the contents of the segment into a receive buffer, and the receiving process reads from this buffer at its leisure. … n TCP Send buffer Read bytes TCP Receive buffer Segment … Segment Transmit segments CSS 432: End-to-End Protocols 10

Sockets (Code Example) int sd = socket(AF_INET, SOCK_STREAM, 0); socket() int sd, new. Sd; sd = socket(AF_INET, SOCK_STREAM, 0); socket() sockaddr_in server; bzero( (char *)&server, sizeof( server ) ); struct hostent *host = gethostbyname( arg[0] ); server. sin_family =AF_INET; sockaddr_in server; server. sin_addr. s_addr = htonl( INADDR_ANY ) bzero( (char *)&server, sizeof( server ) ); server. sin_port = htons( 12345 ); server. sin_family = AF_INET; bind( sd, (sockaddr *)&server, server. s_addr = sizeof( server ) ); inet_addr( inet_ntoa( *(struct in_addr*)*host->h_addr_list ) ); bind() server. sin_port = htons( 12345 ); listen( sd, 5 ); connect( sd, (sockaddr *)&server, listen() sizeof( server ) ); sockaddr_in client; socklen_t len=sizeof(client); connect() while( true ) { new. Sd = accept(sd, (sockaddr *)&client, &len); accept() write( sd, buf 1, sizeof( buf ) ); write( sd, buf 2, sizeof( buf ) ); write() buf 2, buf 1 if ( fork( ) == 0 ) { close( sd ); read( new. Sd, buf 1, sizeof( buf 1 ) ); read( new. Sd, buf 2, sizeof( buf 2 ) ); buf 2, buf 1 close( newsd); read() exit( 0 ); read() } close( new. Sd ); } CSS 432: End-to-End Protocols 11

Data Link Versus Transport n n Data Link layer transfers data between two adjacent nodes (a single point-to-point physical link) whereas transport layer provides communication between processes running in different hosts ¨ need explicit connection establishment and termination Single physical point-to-point link fixed RTT, TCP connections Potentially different RTT (Round Trip Time) as they connect different hosts anywhere on the internet ¨ TCP connection between nodes in same room or across network (different RTT) need adaptive timeout mechanism for re-transmissions Point-to-point link, packets received in FIFO order. In TCP, they can be re-ordered as they cross internet, e. g. , long delay in network, retransmission, etc ¨ need to be prepared for arrival of very old packets ¨ Packets slightly out of order can be corrected using Seq. Num of sliding window protocol ¨ How late a packet can be? need to set MSL (Maximum Segment Lifetime) ¨ n CSS 432: End-to-End Protocols 12

Data Link Versus Transport n Hosts connected to point-to-point are engineered to support the link. Hosts at both ends have similar resources. ¨ n If windowsize = bandwidth*RTT, sender and receiver likely to have window size buffer But for a TCP connection, resources dedicated to the TCP connection such as buffer space, etc, can vary, especially if one of the host supports multiple TCP connections ¨ need to accommodate different node capacity (flow control) Potentially different network capacity. In a directly connected point-topoint link, the bandwidth of the link is known and transmitter cannot send faster than the bandwidth and not possible to congest the network. In TCP, what links will be traversed is not known before hand, and multiple sources can traverse via the same link. ¨ need to be prepared for network congestion CSS 432: End-to-End Protocols 13

Segment Format (TCP Header) n n Each TCP connection identified with 4 -tuple: ¨ (Src. Port, Src. IPAddr, Dsr. Port, Dst. IPAddr) Sliding window + flow control ¨ Acknowledgment, Sequence. Num, Advertised. Window (Sequence. Num) Data Sender n Receiver Acknowledgment + Advertised. Window Flags ¨ SYN, FIN, RESET, PUSH, URG, ACK n n n n CSS 432: End-to-End Protocols SYN (Synchronize): Establishing a connection FIN (Finish): terminating a connection RESET: Confused and Terminating PUSH: Section 5. 2. 7 URG: Sending urgent data ACK: Validating acknowledgment field Sequence. Num is incremented in all cases other than ACK. 14

Segment Format (TCP Header) n n The Src. Port and Dst. Port fields identify the source and destination ports, respectively. The Acknowledgment, Sequence. Num, and Advertised. Window fields are all involved in TCP’s sliding window algorithm. Because TCP is a byte-oriented protocol, each byte of data has a sequence number; the Sequence. Num field contains the sequence number for the first byte of data carried in that segment. The Acknowledgment and Advertised. Window fields carry information about the flow of data going in the other direction. CSS 432: End-to-End Protocols 15

Segment Format (TCP Header) n n n n n The 6 -bit Flags field is used to relay control information between TCP peers. The possible flags include SYN, FIN, RESET, PUSH, URG, and ACK. The SYN and FIN flags are used when establishing and terminating a TCP connection, respectively. The ACK flag is set any time the Acknowledgment field is valid, implying that the receiver should pay attention to it. The URG flag signifies that this segment contains urgent data. When this flag is set, the Urg. Ptr field indicates where the nonurgent data contained in this segment begins. The urgent data is contained at the front of the segment body, up to and including a value of Urg. Ptr bytes into the segment. The PUSH flag allow the sender to tell TCP it should (send) flush all bytes collected to its peer and also notify it to the receiving side. . Finally, the RESET flag signifies that the receiver has become confused, it received a segment it did not expect to receive—and so wants to abort the connection. Finally, the Checksum field is used in exactly the same way as for UDP—it is computed over the TCP header, the TCP data, and the pseudoheader, which is made up of the source address, destination address, and length fields from the IP header. CSS 432: End-to-End Protocols 16

TCP Connection Establishment Tree-Way Handshake and Termination n ¨ Client n Active participant (client) Passive participant (server) Flag= SYN, Sequ n ¨ ence. N n = y, m u ce. N 1 quen + e x S = , ent ACK m + g d N le SY n ow Ackn ACK, A Server n um = x ¨ nt = y + 1 n Acknowledge the server request with ack=++y (next seq num expected) X and y chosen at random ¨ CSS 432: End-to-End Protocols Acknowledge the client request with ack=++x Initiate a reverse connection with its own start sequence num seq=y Set a timer and retransmit the request upon an expiration Client n cknow ledgm e Initiate a connection to a server by sending segment with seq=x Set a timer and retransmit the request upon an expiration Segment from earlier incarnation of same connection can interfere with a later incarnation of the 17 connection

State Transition Diagram CLOSED n Active open/SYN Passive open Close Open ¨ Active open Close n n LISTEN ¨ SYN_RCVD ACK Close/FIN Passive open n SYN/SYN + ACK Send/SYN SYN/SYN + ACK n SYN_SENT SYN + ACK/ACK n n n FIN/ACK FIN_WAIT_1 ACK FIN_WAIT_2 n CLOSE_WAIT FIN/ACK AC K + FI FIN/ACK N /A C K Close/FIN CLOSING ACK Timeout after two segment lifetimes TIME_WAIT (2 * MSL) ¨ n ACK n CSS 432: End-to-End Protocols client or server First close( ) Both side can be active Passive close LAST_ACK CLOSED server listen( ) Close ¨ Active close ESTABLISHED Close/FIN client connect( ) client or server close( ) in response to the first close( ) 18

State Transition Diagram n n n n States involved in opening and closing a TCP connection Anything between is hidden (ESTABLISHED) Each box represents the state of one end of TCP connection All connections start with CLOSED state As connection progresses, it moves from state to state Each arc represents the event/action. Two kinds of events: (1) a segment arrives from peer (2) local operation on TCP One/both sides can close connection. If one side alone closes, then it cannot send segments but can receive them Each arc is labeled using event/action. i. e. , When event happens at a given state, it moves to the next state and takes the action CSS 432: End-to-End Protocols 19

State Transition Diagram CLOSED Active open/SYN n Passive open Opening a connection: ¨ CLOSED to LISTEN: Server invokes passive open on TCP waits for conn req. ¨ CLOSED to SYN_SENT: Client invokes an active open, moves to SYN_SENT state and SYN segment sent to server. LISTEN to SYN_RCVD: Server receives the SYN segment from client, moves to SYN_RCVD state, sends SYN+ACK to client ¨ ¨ Close LISTEN SYN/SYN + ACK Send/SYN SYN/SYN + ACK SYN_RCVD ACK Close/FIN SYN_SENT SYN + ACK/ACK ESTABLISHED SYN_SENT to ESTABLISHED: Client receives the SYN+ACK from server, moves to ESTABLISHED state, sends an ACK back to server ¨ Close SYN_RCVD to ESTABLISHED: Server receives ACK from client and moves to ESTABLISHED Close/FIN FIN/ACK FIN_WAIT_1 ACK FIN_WAIT_2 CLOSE_WAIT FIN/ACK AC Close/FIN K + F IN CLOSING /A C K FIN/ACK LAST_ACK Timeout after two ACK segment lifetimes TIME_WAIT (2 * MSL) CLOSED CSS 432: End-to-End Protocols 20

State Transition Diagram 1. 2. 3. n ¨ ¨ ¨ ¨ This Side can close connection first Other Side can close connection first Both close the connection at the same time Closing a connection: CLOSED Active open/SYN Passive open Close ESTABLISHED TO FIN_WAIT_1: Server sends termination request FIN. Waits for LISTEN ACK from client ESTABLISHED TO CLOSE_WAIT: Client receives FIN, sends ACK to server, SYN/SYN + ACK Send/SYN waits for its own local FIN SYN/SYN + ACK SYN_RCVD SYN_SENT CLOSE_WAIT TO LAST_ACK: Client ACK SYN + ACK/ACK sends own FIN to server waits for ACK FIN_WAIT_1 TO FIN_WAIT_2: ACK received from client, wait for FIN from client Close/FIN ESTABLISHED FIN_WAIT_2 TO TIME_WAIT: FIN received from client. Server sends ACK to Close/FIN FIN/ACK Client, waits for enough time until client receives ACK FIN_WAIT_1 CLOSE_WAIT LAST_ACK TO CLOSED: Client receives AC FIN/ACK Close/FIN K ACK from server, moves to CLOSED + FI TIME_WAIT TO CLOSED: Server waits N FIN_WAIT_2 CLOSING LAST_ACK /A 2*MSL, moves to CLOSED C K ACK Timeout after two ACK segment lifetimes FIN/ACK TIME_WAIT (2 * MSL) CLOSED

State Transition Diagram CLOSED Active open/SYN n ¨ ¨ ¨ Passive open Closing a connection: Close ESTABLISHED TO FIN_WAIT_1: LISTEN Server, Client send termination requests FIN_WAIT_1 TO CLOSING: SYN/SYN + ACK Send/SYN Server/client receive FIN from each SYN/SYN + ACK SYN_SENT other and send ACK, wait for own SYN_RCVD ACK SYN + ACK/ACK CLOSING TO TIME_WAIT: Server/Client receive ACK for the Close/FIN ESTABLISHED FIN they sent, wait for enough time until other peer receives ACK they sent Close/FIN FIN/ACK CLOSE_WAIT TIME_WAIT TO CLOSED: Peer FIN_WAIT_1 waits 2*MSL, move to CLOSED AC FIN/ACK Close/FIN K FIN_WAIT_1 TO TIME_WAIT: + FI N Server/client receive FIN and ACK FIN_WAIT_2 CLOSING LAST_ACK /A C for the FIN that they sent K ACK Timeout after two ACK simultaneously segment lifetimes FIN/ACK TIME_WAIT (2 * MSL) CSS 432: End-to-End Protocols CLOSED 22

State Transition Diagram n n In what condition can the state transit from FIN_WAIT_1 to TIME_WAIT? What is the purpose of the TIME_WAIT state? ¨ ¨ ¨ TCP is given a chance to resend the final ACK. Client sends FIN, Server receives FIN ACK sent by server can be delayed, Client times out ( 1 MSL) Client resends FIN, it can also be delayed (1 MSL) If no TIME_WAIT, new TCP connection can get the delayed FIN and close connection CSS 432: End-to-End Protocols 23

Client ( connect( ) ) SYN_SENT Server LISTEN ( listen( ) ) SYN seq=x SYN_RCVD CK=x + 1 SYN seq=y, A ESTABLISHED ACK=y + 1 Establishment Timing Chart seq=x+1 ACK=y + 1 ( read( ) ) ACK x + 2 ( close( ) ) FIN_WAIT_1 FIN_WAIT_2 FIN seq=x+2 AC K =y + 1 ACK x + 3 1 FIN seq = y + TIME_WAIT ACK=y + 2 CLOSE_WAIT LAST_ACK( close( ) ) Termination ( write( ) ) Data Transfer ESTABLISHED Peek such a flow with tcpdump in assignment 3. CSS 432: End-to-End Protocols 24

Sliding Window Revisited n TCP’s variant of the sliding window algorithm, which serves several purposes: (1) it guarantees the reliable delivery of data, ¨ (2) it ensures that data is delivered in order, and ¨ (3) it enforces flow control between the sender and the receiver ¨ CSS 432: End-to-End Protocols 25

Sliding Window (Reliable & Ordered Delivery) Sending application Receiving application TCP Last. Byte. Written Last. Byte. Acked n Sending side Last. Byte. Read Last. Byte. Sent Next. Byte. Expected n Last. Byte. Rcvd Receiving side Last. Byte. Acked ≤ Last. Byte. Sent ¨ Last. Byte. Read < Next. Byte. Expected Receiver cannot ack the byte not sent Byte cannot be read by receiver until received ¨ Last. Byte. Sent ≤ Last. Byte. Written Cannot send a byte that has not been ¨ Next. Byte. Expected ≤ Last. Byte. Rcvd+1 written to the send buffer Next. Byte. Expected points to the start of ¨ buffer bytes between first gap when data arrive out of order [Last. Byte. Acked, Last. Byte. Written] ¨ buffer bytes between [Last. Byte. Read, Last. Byte. Rcvd] ¨ 26

Sliding Window (Reliable & Ordered Delivery) n Receiving side ¨ ¨ ¨ Last. Byte. Read Data that has been received and also application has read it from the TCP buffer Next. Byte. Expected Data that has not been received and expected as the next byte Last. Byte. Rcvd Data that has been received and in the receiver TCP buffer Last. Byte. Read < Next. Byte. Expected Bytes which are expected can’t be read as they have not yet reached the receiver The next expected byte points to the byte right after the last byte received if data is received in order, therefore Next. Byte. Expected = Last. Byte. Rcvd+1 If due to some reason, data has arrived out of order, Next. Byte. Expected will point to the first gap in the data Next. Byte. Expected ≤ Last. Byte. Rcvd+1 ¨ buffer bytes between [Last. Byte. Read, Last. Byte. Rcvd] ¨ 27

Flow Control n n n Keep sender from overrunning receiver Max. Send. Buffer, Max. Rcv. Buffer for sender, receiver Window is amount of data that can be sent without waiting for ACK Receiver advertises the sender a window <= Max. Rcv. Buffer To avoid overflowing receiver buffer, TCP on receiver sider must keep, Last. Byte. Rcvd − Last. Byte. Read ≤ Max. Rcv. Buffer Advertised. Window of receiver: Amount of free space in receive buffer = Max. Rcv. Buffer − ((Next. Byte. Expected − 1) − Last. Byte. Read) If rate of reading = rate of receiving, Advertised Window = Max. Rcv. Buffer ¨ If rate of reading slower, Last. Byte. Rcvd increases and Advertised Window shrinks to 0 ¨ CSS 432: End-to-End Protocols 28

Flow Control n Sender should adhere to receiver’s advertised window ¨ n Sender computes an effective window that limits how much data it can send to receiver ¨ n Effective. Window = Advertised. Window − (Last. Byte. Sent − Last. Byte. Acked) Local application process must not overflow the send buffer ¨ n Last. Byte. Sent − Last. Byte. Acked ≤ Advertised. Window Last. Byte. Written − Last. Byte. Acked ≤ Max. Send. Buffer If the sending process tries to write y bytes to TCP, but (Last. Byte. Written − Last. Byte. Acked) + y > Max. Send. Buffer then TCP blocks the sending process and does not allow it to generate more data. CSS 432: End-to-End Protocols 29

Flow Control Receiving application Sending application TCP Last. Byte. Read Last. Byte. Written y Last. Byte. Acked Last. Byte. Sent Next. Byte. Expected Last. Byte. Rcvd Last. Byte. Sent – Last. Byte. Acked ≤ Advertised. Window Effective. Window = Advertised. Window – (Last. Byte. Sent – Last. Byte. Acked) Last. Byte. Written – Last. Byte. Acked ≤ Maxsend. Buffer block sender if (Last. Byte. Written - Last. Byte. Acked) + y > Max. Sender. Buffer Last. Byte. Rcvd – Last. Byte. Read ≤ Max. Rcvbuffer Advertised. Window = Max. Rcv. Buffer – (Next. Byte. Expected – Next. Byte. Read) 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) CSS 432: End-to-End Protocols 30

Flow Control with A Slower Receiving application Sending application Read slow. TCP Last. Byte. Read Last. Byte. Written y Last. Byte. Acked y Last. Byte. Sent Last. Byte. Rcvd Next. Byte. Expected Last. Byte. Sent – Last. Byte. Acked ≤ Advertised. Window Last. Byte. Rcvd – Last. Byte. Read ≤ Max. Rcvbuffer 0 0 < 0 Effective. Window = Advertised. Window – (Last. Byte. Sent – Last. Byte. Acked) Advertised. Window = Max. Rcv. Buffer – (Next. Byte. Expected – Last. Byte. Read) 0 No more send, no more ack, thus it stays In the same value Last. Byte. Written – Last. Byte. Acked ≤ Maxsend. Buffer block sender since (Last. Byte. Written - Last. Byte. Acked) + y > Max. Sender. Buffer CSS 432: End-to-End Protocols 31

Flow Control n The sender won’t send any more data. n The receiver won’t initiate to send any advertised window. n Then, how can the sender find out when the receiver can receive more data? CSS 432: End-to-End Protocols 32

Protection Against Wrap Around n 32 -bit Sequence. Num ¨ 2^32 numbers: 0 to 2^32 -1 ¨ After 2^31 -1? Start from 0 (wrap around) ¨ MSL (Maximum Segment Lifetime) = 120 sec < wrap around time (time taken to exhaust all sequence numbers) Bandwidth Time Until Wrap Around T 1 (1. 5 Mbps) Ethernet (10 Mbps) T 3 (45 Mbps) FDDI (100 Mbps) STS-3 (155 Mbps) STS-12 (622 Mbps) STS-24 (1. 2 Gbps) 6. 4 hours 57 minutes 13 minutes 6 minutes 4 minutes 55 seconds 28 seconds CSS 432: End-to-End Protocols 33

Keeping the Pipe Full n n Utilize full bandwidth: sender transmit RTT*Bandwidth data Sender transmission restricted by Receiver Advertised Window should be enough to accommodate RTT*Bandwidth data But 16 -bit Advertised. Window = 64 KB (2^16 bytes) Bandwidth RTT(100 msec) x Bandwidth Product T 1 (1. 5 Mbps) Ethernet (10 Mbps) T 3 (45 Mbps) FDDI (100 Mbps) STS-3 (155 Mbps) STS-12 (622 Mbps) STS-24 (1. 2 Gbps) 18 KB 122 KB 549 KB 1. 2 MB 1. 8 MB 7. 4 MB 14. 8 MB CSS 432: End-to-End Protocols 34

Segment Transmission A segment is transmitted out: 1. 2. 3. When a segment to send reaches Maximum segment size (MMS) = Maximum Transfer Unit (MTU) When a TCP receives a push operation that flushes the unsent data, data is pushed as and when written instead of waiting for segment to be filled (Peek with tcpdump in programming assignment 3) When a timer fires CSS 432: End-to-End Protocols 35

Silly Window Syndrome n n n If you think of a TCP stream as a conveyer belt with “full” containers (data segments) going in one direction and empty containers (ACKs) going in the reverse direction, then MSS-sized segments correspond to large containers and 1 -byte segments correspond to very small containers. If the sender aggressively fills an empty container as soon as it arrives, then any small container introduced into the system remains in the system indefinitely. That is, it is immediately filled and emptied at each end, and never coalesced with adjacent containers to create larger containers.

Silly Window Syndrome

Silly Window Syndrome small MMS 2 MMS 1 Sender Receiver Ad Window n If a sender aggressively takes advantage of any available window, ¨ The receiver empties every window regardless of its size and thus small windows will never disappear. n The problem occurs only when either the sender transmits a small segment or the receiver opens the window a small amount n The receiver can delay ACKs to make a larger window ¨ n How long does it wait? The sender should make a decision ¨ Nagle’s Algorithm (Programming assignment 3) CSS 432: End-to-End Protocols 38

Nagle’s Algorithm n n If there is data to send but the window is open less than MSS, then we may want to wait some amount of time before sending the available data But how long? If we wait too long, then we hurt interactive applications like Telnet If we don’t wait long enough, then we risk sending a bunch of tiny packets and falling into the silly window syndrome ¨ The solution is to introduce a timer and to transmit when the timer expires

Nagle’s Algorithm n n n We could use a clock-based timer, for example one that fires every 100 ms Nagle introduced an elegant self-clocking solution Key Idea As long as TCP has any data in flight, the sender will eventually receive an ACK ¨ This ACK can be treated like a timer firing, triggering the transmission of more data ¨

Nagle’s Algorithm When the application produces data to send if both the available data and the window ≥ MSS send a full segment else if there is un. ACKed data at the sender // if ACK not received for buffer the new data until an ACK arrives previous data sent else // if no un. ACKed data send all the new data now

Nagle’s Algorithm n n n Ack works as a timer to fire a new segment transmission. intentionally delays packets. Time sensitive applications or real-time applications cannot afford such a delay ¨ TCP_NODELAY option in Socket Interface: Transmit data as soon as possible ¨ setsockopt(sockfd, SOL_TCP, TCP_NODELAY, &int. Flag, sizeof(int. Flag)) CSS 432: End-to-End Protocols 42

Adaptive Retransmission n n TCP retransmits segment if ACK not received within timeout Timeout determined based on RTT between different pair of hosts in internet different How to choose timeout? ¨ Adaptive Retransmission

Adaptive Retransmission Original Algorithm (keep running average of RTT) n Measure Sample. RTT for each segment/ ACK pair n n n Record time when you start sending Record time when you receive ACK Take difference Compute weighted average of RTT ¨ Est. RTT = a x Est. RTT + b x Sample. RTT ¨ where a + b = 1 1. a between 0. 8 and 0. 9 2. b between 0. 1 and 0. 2 Set timeout based on Est. RTT ¨ ¨ Time. Out = 2 x Est. RTT Why double? Est. RTT cannot respond to deviated Sample. RTT quickly. CSS 432: End-to-End Protocols 44

Original Algorithm n Problem ¨ ACK does not really acknowledge a transmission n It actually acknowledges the receipt of data ¨ When a segment is retransmitted and then an ACK arrives at the sender n It is impossible to decide if this ACK should be associated with the first or the second transmission for calculating RTTs

Karn/Partridge Algorithm Sender Receiver Sample. R TT inal n ansm Receiver Orig miss ion issio n ACK inal t rans miss io n ACK Retr ansm issio n Assume ACK for original transmission and actually it is for retransmission ¨ n Retr trans Sample. R TT Orig Sender Sample. RTT is too large Assume ACK for ret ransmission and actually it is for original transmission ¨ Sample. RTT is too smal CSS 432: End-to-End Protocols 46

Karn/Partridge Algorithm n n Do not sample RTT when retransmitting ¨ Can’t figure out which transmission the latest ACK corresponds to. Whenever TCP retransmits ¨ Set the last timeout to be double the previous value (similar to exponential backoff) ¨ Congestion causes this retransmission. n ¨ Do not react aggressively and be more cautious when more time outs happen Modestly retransmit segments. CSS 432: End-to-End Protocols 47

Karn/Partridge Algorithm n Karn-Partridge algorithm was an improvement over the original approach, but it does not eliminate congestion n We need to understand how timeout is related to congestion ¨ If you timeout too soon, you may unnecessarily retransmit a segment which adds load to the network

Karn/Partridge Algorithm Main problem with the original computation is that it does not take variance of Sample RTTs into consideration. n If the variance among Sample RTTs is small n ¨ Then the Estimated RTT can be better trusted ¨ There is no need to multiply this by 2 to compute the timeout

Karn/Partridge Algorithm On the other hand, a large variance in the samples suggest that timeout value should not be tightly coupled to the Estimated RTT n Jacobson/Karels proposed a new scheme for TCP retransmission n

Jacobson/ Karels Algorithm n Original Algorithm ¨ Est. RTT = a x Est. RTT + b x Sample. RTT 0. 8 and 0. 9 0. 1 and 0. 2 ¨ n Time. Out = Est. RTT * 2 New Algorithm that takes into a consideration if the variation among smaple. RTTs are large. ¨ Est. RTT = Est. RTT + d(Sample. RTT – Est. RTT) 0. 125 ¨ Diff Dev = Dev + d(|Sample. RTT – Est. RTT| – Dev) Diff ¨ Time. Out = m 1 x Est. RTT + f x Dev 4 CSS 432: End-to-End Protocols 51

TCP Extensions n RTT Measurement Store a 32 -bit timestamp in outgoing segments’ header option ¨ Receive an ack with the original timestamp ¨ Sample RTT by subtracting the timestamp from the current timer ¨ n Resolving the quick wrap-around of sequence number The 32 -bit timestamp and the 32 -bit sequence number gives a 64 -bit sequence space ¨ Time. Stamp differentiate 2 different incarnations of the same sequence number ¨ n Extending an advertised window ¨ Scale up the advertised window n How many bytes to send → How many 16 -byte units to send CSS 432: End-to-End Protocols 52

n 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 n Exercises in Chapter 5 ¨ Ex. 5, 14, 22, and 39 (TCP state transition) ¨ Ex. 9(a) (Sliding window) ¨ Ex. 20 (Nagle’s algorithm) CSS 432: End-to-End Protocols 53

Supplementary CSS 432: Internetworking 54

Jacobson/ Karels Algorithm Sample. RTT –= (Estimated. RTT >> 3) Estimated. RTT += Sample. RTT; If (Sample. RTT < 0) Sample. RTT = – Sampel. RTT; Estimated. RTT = 8 Est. RTT Deviation = 8 Dev Sample. RTT = Sample. RTT – 8 Est. RTT/ 8 = Sample. RTT – Est. RTT diff Deviation += Sample. RTT; Estimated. RTT = Estimated. RTT + d Diff 8 Est. RTT = 8 Est. RTT + Sample. RTT = 8 Est. RTT + (Sample. RTT – Est. RTT) Est. RTT = Est. RTT + 1/8 (Sample. RTT – Est. RTT) Time. Out = (Estimated. RTT >> 3) + (Deviation >> 1) diff Sample. RTT –= (Deviation >> 3); |Sample. RTT – Est. RTT| – 8 Dev/8 |diff| n ¨ ¨ ¨ Notes Scale calculation by 2^n, d = 1/n, n=3, avoid floating points Estimated. RTT, Deviation already in scaled form, Sample. RTT, Time. Out, , real values << multiply by 2^n; >> divide by 2^n Algorithm does not work accurately with a large granularity of clock (500 ms on Unix) Accurate timeout mechanism important to congestion control 8 Dev = 8 Dev + |Sample. RTT – Es. RTT| - Dev = Dev + 1/8( |Sample. RTT – Est. RTT| - Dev ) Time. Out = 8 Est. RTT / 8 + 8 Dev / 2 Time. Out = Est. RTT + 4 Dev 55