CMPT 371

1. CMPT 371 Data Communications and Networking Principles of reliable data transfer

2. Fast Retransmit For sliding windows flow control we waited for a timer to expire before beginning retransmission of a packet TCP uses an additional mechanism based on cumulative acknowledgement to reduce the wait time for retransmission This fast retransmit mechanism keeps track of the retransmitted cumulative ACKs arriving at the source. If the same cumulative ACK arrives four times (three retransmissions), indicating that there is missing data at the destination then the source automatically retransmits the packet starting with the next octet expected by the receiver.

3. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 F0 F1 ACK1 F2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 F3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK1 ACK1 ACK1 F4 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 F5 F1 F6 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK7 ACK1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 Sliding Window: fast retransmit

4. Reliable underlying network: 1 • Allow each end to know the other exists • Negotiate of optional parameters (segment size, window size, QoS) • Allocation of transport entity resources (buffer space, entry in connection table) • Need ESTABLISHED (open), CLOSED, and ‘half open’ states. Process must be ‘listening’ to accept a connection • Need two types of messages (socket subroutine calls) • SYN: specifies initial sequence numbers for synchronization • FIN: indicates no more data to send, requesting termination

5. Reliable underlying network (2) • ‘half open’ states occur when opening or closing a connection • connection requested and not yet established (SYN SENT) (waiting for response SYN) • ready to accept connections no request received yet (LISTEN) (waiting for initiating SYN, will immediately respond with response SYN) • Close requested, data flow from requesting endpoint is complete (FIN WAIT) (waiting for response to sent FIN) • Close request received, data flow from endpoint receiving close request continues until completion (CLOSE WAIT) (waiting to respond to close request, FIN)

6. Connection State Diagram Stallings 2003: Figure 20.3

7. Connection Establishment • Lost or delayed data segments can cause connection problems if the previously discussed 2-way handshake is used • Cannot assume sent SYN or FIN reaches destination • Arriving SYN or FIN could be from an old connection attempt • Solve by using a three way handshake (must ACK receipt of FIN or SYN) and start segment numbers (SYNi, ACKi, FINi) far removed from those used by previous connections

8. Unreliable Network Service • ADDITIONAL PROBLEMS • Solved by using variants of sliding windows (hybrid of go back N or selective reject) and credit scheme already discussed • Segments may get lost, need retransmission strategy • Duplication detection • Flow control • Segments may arrive out of order, transport layer must deliver in order to application (solution unique sequence numbers) • Connection establishment / termination (replace two way handshake with three way handshake to deal with losses, duplications)

9. Ordered Delivery • Segments may arrive out of order • Number segments sequentially • TCP numbers each octet sequentially • Segments numbers indicate the by the first octet number in the segment • Flow may not start with octet 0 (helps distinguish between different connections)

10. Connection Establishment • Lost or delayed data segments can cause connection problems if the previously discussed 2-way handshake is used • Cannot assume sent SYN or FIN reaches destination • Arriving SYN or FIN could be from an old connection attempt • Solve by using a three way handshake (must ACK receipt of FIN or SYN) and start segment numbers (SYNi, ACKi, FINi) far removed from those used by previous connections

11. Unreliable underlying network • Must add additional states to the diagram • When opening need a SYN RECEIVED state to be in while waiting for the ACK of the SYN sent in response to the SYN sent by the initiating station • When closing in passive mode need a LAST ACK state to be in while waiting for the ACK of the FIN sent in response to the received FIN

12. Unreliable underlying network • When closing in active mode need • FIN WAIT2 state to be in while waiting for the station receiving the close request (the first FIN) to complete transmission and send response FIN. The ACK of the first FIN is received before entering this state • CLOSING state to be in while waiting for the ACK to the response FIN. The response FIN has already been received before entering this state

13. Three Way Handshake Active Open: CLIENT Active Open Passive Open: SERVER CLOSED Send SYN Close (Timeout) Close (Timeout) Receive SYN Send SYN-ACK SYN_RECEIVED SYN_SENT LISTEN Receive ACK of SYN Receive SYN-ACK Send ACK ESTABLISHED

14. Three Way Handshake: ESTABLISHED Receive FIN Send Ack Send FIN FIN_WAIT_1 CLOSE_WAIT Receive FIN Send Ack Receive ACK of FIN Send FIN Receive FIN-ACK Send Ack CLOSING LAST_ACK FIN_WAIT_2 Receive ACK of FIN Receive ACK of FIN Receive FIN Send Ack CLOSED TIME_WAIT Timeout

15. Structure of a TCP packet Variable length header: from 20 bytes (no options) to 60 bytes SOURCE PORT DESTINATION PORT 20 CHECKSUM

16. Flow Control and Error control • Flow may be controlled because: • The receiving transport layer entity can not keep up and runs out of buffer space • The receiving application layer process can not accept data fast enough and data must remain in transport buffer for longer • Longer transmission delays between transport entities than for a direct physical connection • Delay in communication of flow control info • Variable transmission delay make definition and use of timeouts problematical

17. When to send ACKs • Use sliding window flow control • Start by considering the simplest part of the problem and assume a reliable underlying network (delivery guaranteed) • When do we send the ACK after receiving a segment • Conservative approach is to send ACK only when buffer is available, to avoid buffer overflow • Optimistic approach send ACK so next data will arrive when buffer is available. Flow will resume more quickly after congestion, but data may be lost

18. Optimistic approach • ACK is sent when segment is received by the transport entity at the receiver, • When the ACK is received by the source the source is free to send another packet • This may cause buffer overflow at the receiver because • The transport layer buffers the segment until the data in the segment can be successfully transferred to the application layer • It is possible that the transfer (due to loading at the receiver’s host) will be slow. • The application may not be ready to accept the additional data when it arrives.

19. Buffer overflow example • Consider a system with source and receiver both having a sliding window that holds 100 octets. The source in this system sends segments each holding 25 octets. • The source sends segment 1, the receiver receives segment 1 • The receiver sends an ACK for segment 1 • The source sends segments 2, 3, and 4, the receiver receives them • The receiver is extremely busy and the data in segment 1 remains in the receiver’s receive buffer. • The source receives the ACK1 and sends segment 5. • Segment 5 arrives at the receiver, the receiver has not finished sending segment 1 to the application • The data in segment 5 overwrites the data for segment 1 and will be sent to the application as segment 1

20. Conservative approach • ACK is sent when segment has been transferred to the application layer • When the ACK is received by the source the source is free to send another packet • Thus, the buffer at the receiver already has space before the ACK is sent no overflow occurs • However in a congested network significant time may be wasted waiting for ACKS • If the delays due to congestion are significant unnecessary retransmission may also occur and further contribute to the congestion problems

21. Improving Sliding Windows • Flow may be controlled because: • The receiving user can not keep up (runs out of buffer space) • The receiving transport entity can not keep up • Control Flow using one of the following approaches: • Conservative: send ACK only when buffer is available, to avoid buffer overflow • Optimistic: send ACK so next data will arrive when buffer is expected to be available. (data may be lost and require retransmission) • Credit mechanism: decouple ACK from control of sliding window buffer

22. Credit allocation mechanism • The choice of when to ACK a packet can be addressed by using a credit allocation mechanism which separates acknowledgement of receipt from moving the sliding window • Each ACK contains two values • One indicates the next packet expected • One indicates the amount the sliding window can be moved • An ACK can be sent immediately after receipt of a packet, the sliding window need not be moved at the same time. • When the receiver can handle additional data, an additional ACK can be sent to move the window

23. Changes to the source window happen after ACK is received Changes to the receiver window happen after the ACK is sent An ACK can combine acknowledgement of any number of packets ending with packet m with granting credit for n packets (for any n>=0) Sliding window: credit allocation

24. Send/receive ACKm without credit allocation After the receipt of ACKm the start of source window slides to the right to the beginning of packet m. All packets up to packet m-1 have been successfully received and need not be kept in source buffer After sending ACKm the receiver location of window is unchanged Sliding window: receipt

25. ACKm with only credit allocation of n packets After the receipt of the ACK the end of source window slides to the right n packets After sending the ACK the receiver window (both ends) slides to the right n packets Sliding window: credit allocation

26. Credit Mechanism: 1 • All frames of data in transit must be buffered in the sliding window at the source until the ACK from the receiving station arrives at the sending station. • Source transmits frames from its sliding window until its send buffer is exhausted. Think of each frame as having a timer to indicate how long to wait for the ACK. • Receiver receives a frame and • Sends an ACK , indicates next frame expected and any credit allocation • Advances the left end of its sliding window past the end of the acknowledged data • Advances the right end of its sliding window by the amount of the credit allocation (if any) given in the ACK it sent

27. Credit mechanism: 2 • Source entity receives ACKand stops timer for acknowledged frame. • If an ACKm is received the source entity • advances the end (right end) of its sliding window by the amount of credit granted (n frames) • Advances the start (left end) of its sliding window to the beginning of the next frame (frame m) expected by the receiver • If a timeout timer expires the frame with an expired timer is retransmittedand the timer is reset

28. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 F0 F1 ACK2 CRED1 ACK1 CRED0 F2 F7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 F3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK5 CRED3 ACK4 CRED0 ACK3 CRED0 F4 ACK7 CRED1 F5 F6 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK6 CRED2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 Sliding Window with credit allocation: problem?

29. Credit Mechanism: 1 (fixed) • All frames of data in transit must be buffered in the sliding window at the source until the ACK from the receiving station arrives at the sending station. • Source transmits frames from its sliding window until its send buffer is exhausted. Think of each frame as having a timer to indicate how long to wait for the ACK. • Receiver receives a frame and • Sends an ACK , indicates how long the senders window should be • Advances the left end of its sliding window past the end of the acknowledged data • Advances the right end of its sliding window by the amount of the credit allocation (if any) given in the ACK it sent

30. Credit mechanism: 2 (fixed) • Source entity receives ACKand stops timer for acknowledged frame. • If an ACKm is received the source entity • Advances the start (left end) of its sliding window to the beginning of the next frame (frame m) expected by the receiver • advances the end (right end) of its sliding window to make the window the same length as it told the sender to make its window • If a timeout timer expires the frame with an expired timer is retransmittedand the timer is reset

31. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 F0 F1 ACK2 Window5 ACK1 Window5 F2 F7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 F3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK5 Window5 ACK4 Window3 ACK3 Window4 F4 ACK7 Window6 F5 F6 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 ACK6 Window6 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 Sliding Window with credit allocation

32. One more question • Do you see any other problems in the previous example? • Our cycle of window numbers is not long enough • If we send 6 segments, receive no ACKs for any of the 6 segments, then resend the six segments, the receiver will think the resent packets 0, 1, 2, 3 are the from the next cycle • Just like for selective repeat need a window that is <=N/2 where N is the length of our numbering cycle • So for a window of length 6 need a cycle of at least 12, cycle length should be 2N so use 16

33. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 9 12 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10 10 11 11 11 11 113 11 113 11 11 11 12 12 124 12 12 12 12 12 12 12 13 13 13 135 13 13 13 13 135 13 14 14 14 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 15 15 15 16 16 16 16 16 16 16 16 16 16 13 8 16 11 F0 F1 ACK2 Window5 ACK1 Window5 F7 F2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 F3 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ACK5 Window5 ACK4 Window3 ACK3 Window4 F4 ACK7 Window6 F5 F6 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ACK6 Window6 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 157 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Sliding Window with credit allocation