1. CSS432 (Link Level Protocols) Reliable Transmission Textbook Ch 2.5
Prof. Athirai Irissappane
CSS 432

2. Reliable Transmission
The University of Adelaide, School of Computer Science
30 December 2018
Reliable Transmission
CRC is used to detect errors.
Some error codes are strong enough to correct errors. The overhead is typically too high.
Corrupt frames must be discarded.
A link-level protocol that wants to deliver frames reliably must recover from these discarded frames.
Protocols use Acknowledgements and Timeouts
Chapter 2 — Instructions: Language of the Computer

3. Reliable Transmission
The University of Adelaide, School of Computer Science
30 December 2018
Reliable Transmission
An acknowledgement (ACK for short) is a small control frame (only header no data) that a protocol sends back to its peer saying that it has received the earlier frame.
The receipt of an acknowledgement indicates to the sender of the original frame that its frame was successfully delivered.
If the sender does not receive an acknowledgment after a reasonable amount of time, then it retransmits the original frame.
The action of waiting a reasonable amount of time is called a timeout.
Chapter 2 — Instructions: Language of the Computer

4. Frame Transfer Algorithms
Sender
Receiver
Stop and wait
Stop a transmission and wait for ack to return or timeout
Add 1-bit sequence number to detect a duplication of the same frame
Sliding window
Allow multiple outstanding (un-ACKed) frames
Upper bound on un-ACKed frames, called window
Frame 0
Ack 0
Frame 1
Ack 1
Frame 0
Ack 0
Sender
Receiver
If ACK is lost or delayed in arriving
The sender times out and retransmits the original frame, but the receiver will think that it is the next frame since it has correctly received and acknowledged the first frame. (duplicate copies of frames will be delivered!!) …
Time
CSS 432

5. Stop and Wait (use seq num 0 to n)
timeout
// Test 2: client stop-and-wait message send
int clientStopWait( UdpSocket &sock, const int max, int message[] ) {
int retransmits = 0; // # retransmits
int ack; // prepare a space to receive ack
// transfer message[] max times
for ( int sequence = 0; sequence < max; ) {
message[0] = sequence; // message[0] has a sequence number
sock.sendTo( (char *)message, MSGSIZE ); // udp message send
// until a timeout (1500msecs) occurs
// keep calling sock.poolRecvFrom( )
// if an ack came, exame if its ack sequence is the same as my sequence
// if so, increment my sequence and go back to the loop top
// if a timeout occurs, resend the same sequence and increment retransmits }
return retransmits;
Frame
sent 1 1 2
ack=1
seq=1
seq=2
ack=0
seq=1
ack=1
seq=0
late
// Test 2: server reliable message receive
void serverReliable( UdpSocket &sock, const int max, int message[] ) {
int ack; // an ack message
// receive message[] max times
for ( int sequence = 0; sequence < max; ) {
sock.recvFrom( (char *)message, MSGSIZE ); // udp message receive
// if this is a message expected to receive
send back an ack with this sequence number and increment sequence
// if this message is < sequence number of expected message
ignore the message, but send an acknowledgement for it }
Frame
received 1 1 2
discarded
CSS 432

6. Stop and Wait (HW2)
Client writes a message sequence number in message[0], sends message[] and waits until it receives an integer acknowledgment from a server, while the server receives message[], copies the sequence number from message[0] to an acknowledgment, and returns it to the client.
UDP bind client socket (connect, sendTo implicit bind but receiveFrom no implicit bind)
CSS 432

7. Stop and Wait Problem: Can’t utilize the link’s capacity Example 1
Consider a 1.5 Mbps link with a 45 ms RTT
The link has a capacity, i.e., delay  bandwidth = 67.5 Kb ~ 8 KB
Sender can send only one frame (size = 1 KB) per RTT
1KB for 45ms RTT (one-eighth of the link’s capacity)
To use the link fully, then sender should transmit up to eight frames before having to wait for an acknowledgement.
CSS 432

8. Sliding Window Protocol
Utilizes link capacity
Transmit 8 frames before receiving ACK0
Transmit 9th frame same time when ACK0 received
Allow multiple outstanding (un-ACKed) frames
Upper bound on un-ACKed frames (<=8), called window
CSS 432

9. Sliding Window CSS 432 window max = 5 frame sent lost lost Cum ACK 1 2
// Test 3: client sliding window + early-retransmission
int clientSlidingWindow( UdpSocket &sock, const int max, int message[], const int windowSize ){
int retransmits = 0; // # retransmits
int ack; // prepare a space to receive ack
int ackSeq = 0; // the ack sequence expected to receive
// transfer message[] max times
for ( int sequence = 0; sequence < max || ackSeq < max; ) {
if ( ackSeq + windowSize > sequence && sequence < max ) {//send till sliding window full
message[0] = sequence; // message[0] has a sequence number
sock.sendTo( (char *)message, MSGSIZE ); // udp message send
// check if ack = ackSeq using sock.poolRecvFrom( )
if true increment ackSeq
// increment sequence
} else { // the sliding window is full!
// until a timeout (1500msecs) occurs check for ack
// keep calling sock.poolRecvFrom( )
// if an ack came, if ack >= ackSeq, ackSeq = ack + 1
// else resend the lost message (ack+1) and increment retransmits
// break if (any) ack received
// if a timeout occurs, resend the message corresponding to ackSeq and increment retransmits }
return retransmits;
window
max = 5
TimeOUT
frame sent 1 2 3 4 5 6 7 3 3 3 3 8
lost
// Test 3: server early retransmission
void serverEarlyRetrans(UdpSocket &sock, const int max, int message[], const int windowSize ){
int ack; // an ack message
bool array[max]; //array[i]=true if i is received
for ( int j = 0; j < max; j++ ) array[j] = false; // no message has arrived yet
// receive message[] max times
for ( int sequence = 0; sequence < max; ) {
sock.recvFrom( (char *)message, MSGSIZE ); // receive a UDP message
// if message[0] = sequence.
//expected message received bool match=true
//mark array[sequence]=true,
//Increment sequence until you identify the first non-received message
// else if message[0] > sequence
//mark arrray[seqNum]=true.
// if match=true
//send ack=sequence
// increment sequence
// else send ack=sequence-1 }
lost
Cum ACK 1 2 2 2 2 2 7 7 7 8
CSS 432

10. Sliding Window
No. of Packets Sent by Client before detecting packet loss = 5 + 3
If the 3rd packet is lost
Client already has sent Window Size packets , i.e., 5
Client has received ACK for 0, 1, 2 packets
Thus nPAckets sent before detecting packet loss = 8
No extra time is taken by the server to send ACKs
Timer is triggered only when the expected ACK from Packet 3 is missing
If it takes 5us to send 1 packet and the timeout is 100us
Total time taken by sender to detect that packet 3 is lost = 8* = 140us
CSS 432

11. Sliding Window (HW2)
Client keeps writing a message sequence number in message[0] and sending message[] as far as the number of in-transit messages is less than a given window size
Server receives message[], memorizes this message's sequence number in its array and returns as its acknowledgment the minimum sequence number of messages it has not yet received
Repeat sending and receiving MAX times.
CSS 432

12. Sequence Number Space
SeqNum field is finite; e.g., 3-bit SeqNum field (0..7)
Repeat sequence numbers, MaxSeqNum: e.g. 8
SWS <= MaxSeqNum-1, differentiate between new, old incarnations when ACK is lost
If (RWS = 1), SWS <= MaxSeqNum-1 is sufficient
If (RWS = SWS), SWS <= MaxSeqNum-1 is not sufficient
suppose 3-bit SeqNum field (0..7)
SWS=RWS=7
sender transmit frames 0..6
arrive successfully, but ACKs lost
sender retransmits 0..6
receiver expecting 7, 0..5, but receives second incarnation of 0..5
SWS < (MaxSeqNum+1)/2 or 2 x SWS – 1 < MaxSeqNum
RWS: Upper bound on the number of out-of-order frames that the receiver is willing to accept
SWS: Upper bound on the number of outstanding (unacknowledged) frames that the sender can transmit
CSS 432

13. Reviews
Stop-and-wait
Sliding window
CSS 432