CMPT 371

© Janice Regan, CMPT 128, 2007-2012

CMPT 371Data Communications and Networking

Principles of reliable data transfer

1

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.

2Janice Regan © 2007-2013

Sliding Window: fast retransmit

3

F0

F2

F3

F4

F5

ACK1

ACK1

ACK1

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 05 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

F1 5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK1

ACK1

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0ACK1

F6

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

F1

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK7

Janice Regan © 2007-2013

Janice Regan © 2007-2013 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


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)


Connection State Diagram

Stallings 2003: Figure 20.3


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


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)


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)


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


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


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


Three Way Handshake Active Open Passive Open: SERVER Active Open: CLIENT

CLOSED

LISTENSYN_SENT

ESTABLISHED

Send SYN

Close(Timeout)

Close(Timeout)

Receive SYN-ACK Send ACK

Receive SYN Send SYN-ACK

Receive ACK of SYN

SYN_RECEIVED


Three Way Handshake:ESTABLISHED

Send FIN

FIN_WAIT_1

FIN_WAIT_2

Receive FINSend Ack

Receive FINSend Ack

Receive FIN-ACKSend Ack

Send FINReceive FIN

Send Ack

Receive ACK of FINReceive ACK of FIN

Receive ACK of FIN

TIME_WAIT

CLOSING

CLOSED

CLOSE_WAIT

LAST_ACK

Timeout


Structure of a TCP packet

SOURCE PORT DESTINATION PORT

CHECKSUM

20

Variable length header: from 20 bytes (no options) to 60 bytes


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


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


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.


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


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


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


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


Sliding window: credit allocation

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: receipt 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: credit allocation 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


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


Credit mechanism: 2 Source entity receives ACK and 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 retransmitted and the timer is reset


Sliding Window with credit allocation: problem?

F0

F2

F3

F4

F5

ACK1CRED0

ACK6CRED2

ACK3CRED0

F6

F7

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 05 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

F15 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK2CRED1

ACK4CRED0

ACK5CRED3

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK7CRED1


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


Credit mechanism: 2 (fixed) Source entity receives ACK and 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 retransmitted and the timer is reset


Sliding Window with credit allocation

F0

F2

F3

F4

F5

ACK1Window5

ACK6Window6

ACK3Window4

F6

F7

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 05 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

F15 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK2Window5

ACK4Window3

ACK5Window5

5 6 7 0 1 2 3 4 5 60 1 2 3 4 7 0

ACK7Window6

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



Sliding Window with credit allocation

F0

F2

F3

F4

F5

ACK1Window5

ACK6Window6

ACK3Window4

F6

F7

5 6 7 8 9 10 11 12 135 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 113 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 113 124 135 140 1 2 3 4 15 165 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

F15 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

5 6 7 8 9 10 11 12 13 140 1 2 3 4 15 16

ACK2Window5

ACK4Window3

ACK5Window5

5 6 7 8 9 10 11 12 13 140 1 2 3 4 157 16

ACK7Window6

Documents

CMPT 371