CS455 Syllabus

### Using a Finite number of Sequence Numbers

• The effect of finite number of sequence numbers

• Fact:

 Finite sequence numbers will repeat after a certain number of frames have been labeled

• Example:

• Frame header uses 2 bits sequence numbers:

 ``` Frame header Body (data) CRC +--------------+--------------------+-----+ |x|x| .... | ..... | ... | +--------------+--------------------+-----+ Seq. number ```

• The total number of sequence numbers = 4:

 00, 01, 10, 11

The sender will number the frames as follows:

 ``` Frames: 0 1 2 3 4 5 6 7 8 9 Sequence number: 00 01 10 11 00 01 10 11 00 01 ... or: 0 1 2 3 0 1 2 3 0 1 ... ```

Notice that the sequence numbers will repeat

(I will use decimal sequence numbers for convenience !!!)

• Problem caused by finite sequence numbers: ambiguity...

• Problem created by a finite number of sequence numbers:

Explanation:

• The sender and receiver must re-use the sequence numbers to number different frames

(Sooner or later, the sender and receiver will run out of sequence numbers and must re-use (= repeat) them again.)

• Result:

 Different frames can be identified by the same sequence number

• Potential problem:

 The sender uses a sequence number to identify a re-transmission (of an old frame) The receiver uses the same sequence number to identify a new frame

Result:

 The receiver will deliver a re-transmitted (old) frame more than once !!!

• Example of ambiguity

• Suppose:

• Sender and receiver use 2 bits sequence numbers

How the frames will be numbered:

 ``` Frame: #1 #2 #3 #4 #5 #6 #7 #8 #9 ..... Seq. No.: 0 1 2 3 0 1 2 3 0 ..... ```

Notice that frame #5 is identified by the sequence number 0 !!!

• Suppose:

 Send window size = 3 Receive window size = 2

• Consider the following exchange of frames and ACKs:

• Sender sends 3 frames with sequence numbers 0, 1 and 2 to the receiver

 All frames has been received (correctly)

• Receiver sends ACK 0, ACK 1 and ACK 2:

Now:

• The receive window is now:

 ``` Receive window = [3, 0] // If we had more seq. no.'s,, the recv. window would be: [3, 4] // But since the seqn. no.'s are: 0, 1, 2, 3, the seq. no. 0 // is the number for the 5th frame !!! ```

• Note that:

 The receiver can not know what will happen to the ACK frames !!!

• Now:

• Because the receive window = [3,0] (0 = sequence number of the frame #5):

 the receiver will deliver this frame (The receiver assumes this frame (seq. no. = 0) is the frame #5 from the sender !!!)

Summary:

• \$64,000 question:

• Is the second frame 0:

 always (i.e., for sure) the frame #5 from the sender ??????

 NO !!!!

I will show you 2 scenarios that that shows that both cases are possible !!!

• Scenario 1:

• The scenario in the next figure shows that the second frame 0 is a new frame

 I.e.: the second frame 0 is the frame #5 transmitted by the sender

Scenario:

• Scenario 2:

 The scenario in the next figure shows that the second frame 0 is a re-transmission of an old frame !!!

Scenario:

• Conclusion:

• The receiver may deliver some frames (in our example: frame 0) more than once !!!

 This voilates the reliablity definition !!!

• Look at another example: no ambiguity !!!

• Suppose:

• Sender and receiver use 2 bits sequence numbers

How the frames will be numbered:

 ``` Frame: #1 #2 #3 #4 #5 #6 #7 #8 #9 ..... Seq. No.: 0 1 2 3 0 1 2 3 0 ..... ```

Notice that frame #5 is identified by the sequence number 0 !!!

• But now suppose:

 Send window size = 2 ***** (it was 3) Receive window size = 2

• Consider the following exchange of frames and ACKs:

• Sender sends frames 0 and 1 (can't send 3 frames because of send window size) to the receiver

 All frames has been received (correctly)

• Receiver sends ACK 0 and ACK 1:

Notice:

 The receive window = [2,3] The receiver does not know what have happened to the ACK frames.....

• Now:

Because the sequence number 0 is not part of the receive window:

 The receiver will discard the frame 0 (Because the receiver assumes that this frame 0 is a re-transmission)

Question:

• Is this frame 0:

 always a re-transmission (of the old frame 0) ????

Summary:

• \$64,000 question:

 Is the second frame 0 always a re-transmission of the frame #0 ???

• YES !!!!

 The second frame 0 must have been a re-transmission of an old frame !!!

I will show you all possible scenarios to prove that frame 0 can only be a re-transmission !!!

• All possible scenarios:

• Scenario 1: All ACKS lost =====> second frame 0 is a re-transmission

• Scenario 2: ACK 0 lost =====> in this case, it is not possible that a second frame 0 is transmitted

(Because the send window does not contain the sequence number 0 !!!)

• Scenario 3: All ACKS received =====> in this case, it is also not possible that a second frame 0 is transmitted

(Because the send window does not contain the sequence number 0 !!!)

• Conclusion:

• In this example:

 The second frame 0 can only be a re-transmission of the old frame 0

• I.e.:

 There is no ambiguiuty !!!

• Important reminder

• Recall that:

• Graphically:

It is impossible that the sender's window slides ahead of the receiver's window:

• Solution to the ambiguity problem

• I will first describe the problem with an example:

• Suppose the sender and receiver use 3 bits sequence numbers

 There are 23 different sequence numbers (Namely: 0, 1, 2, ...., 7 = 23−1)

• Suppose:

 The send window size = 5 The receive window size = 4

• Initially, the send window and receive window are lined up:

• Suppose the sender sends the maximum number of frames:

 Due to the send window size, the sender can send 5 frames without waiting for ACKs.

If all 5 frames were received correctly, then the receive window will slide 5 positions:

Notice that:

• The receive window (= [5,6,7,0]) contains the sequence number 0

The receiver has enter a state where it assumes that a frame 0 is a new frame !!!

 This is a premature assumption !

• The receiver will send back 5 ACKs:

 ACK 0, ACK 1, ACK 2, ACK 3 and ACK 4

Here is the problem:

• If all ACK frames are lost, then:

 The sender will retranmsit the frame 0 using the sequence number 0 !!! (And this retranmsission is delivered by the receiver as if it is a new frame !!!)

• We can prevent the receiver from delivering the frame with sequence number 0 by limiting the window size:

• Suppose:

 The send window size = 4 (previously, it was 5) The receive window size = 4

• Initially, the send window and receive window are lined up:

• Suppose the sender sends the maximum number of frames:

 Due to the send window size, the sender can send 4 frames without waiting for ACKs.

If all 4 frames were received correctly, then the receive window will slide 4 positions:

• Notice now that:

• The receive window contains all "new" values (4,5,6,7) that are different from the old set of values (0,1,2,3)

Therefore:

 This frame must be a re-transmission

 This frame must be a new data frame

• Sufficient condition to guarantee unambiguity

• Sufficient condition that guarantee that a sequence number in any send window will uniquely identifies one frame

• Let N = the number of different sequence numbers available
• Let Wsend = the send window size
• Let Wrecv = the receive window size

• If:

 ``` Wsend + Wrecv ≤ N ```

then:

 A sequence number in any send window will uniquely identifies one frame

Proof:

• From the discussion above, we learned that:

• The receiver must not slide too far that the new receive window contains a value in the original send window:

• Initially, the sender window and receiver window are lined up

Without loss of generality, we can assume that:

 The sender window and receiver window are lined up at the sequence number 0 (The argument will work for any sequence number. It is easier to understand using as starting sequence number = 0)

Initial situation:

• The most that the receive window can slide is:

 Wsend positions (before the send window slides) (The receive window slides 1 position for 1 received frame. And the sender can send at most Wsend frames.)

So, the receive window can go at most this far:

• Since:

 ``` Wsend + Wrecv ≤ N ```

The receive window will not have a sequence number that was in the original send window

So:

 no ambiguity possible

 ``` Wsend = 2N-1 Wrecv = 2N-1 ```