CS455 Syllabus

### Problem caused by finite sequence numbers - ambiguity

• Prelude: Acknowledgement scheme used in the discussion

• Fact:

• The discussion on the correctness of the sliding window algorithm does not depend on the ACK scheme used

• So, for simplicity, I will use selective acknowledge

I.e.:

 ``` ACK n ===> ACK data frame n only ```

• Sequence numbers in frames

• Fact:

• (Send/Receive) Sequence numbers are found in the

of data/ACK frames

• Example: HDLC I-frame

• Sequence numbers used in data communication:

 Sequence numbers is always a binary field of n bits The number of (different) sequence numbers available = 2n

• Example:

• Suppose a frame header uses 2 bits sequence numbers:

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

• The total number of sequence numbers = 4

Namely:

 00, 01, 10, 11

Or:

 0, 1, 2, 3   (in decimal base notation)

• The effect of finite number of sequence numbers

• Effect:

 Different data frames will be identified using the same sequence number

• Example:

• Suppose the available sequence numbers are:

 00, 01, 10, 11              Or: 0, 1, 2, 3

• Frames will be identified with sequence numbers as follows:

 ``` Frames: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 Infinite seq. no.: 0 1 2 3 4 5 6 7 8 9 4 seq no: 00 01 10 11 00 01 10 11 00 01 ... or: 0 1 2 3 0 1 2 3 0 1 ... ^ ^ | | Frame #2 and #6 are both identified with the seq. no. 01 ```

Notice that the sequence numbers will repeat

• Comment:

 I will use decimal sequence numbers for convenience.... (Remember they are binary numbers in the frame header)

• 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:

 The same sequence number is used to identified different frames

Consequently: ambiguity

• The receiver can not tell frame #2 from frame #6 by the sequence number 1 !!!

• How can ambiguity cause problems

• Potential problem scenario:

• The sender transmits data frame 0 using send seq no 0:

But:

 The ACK for data frame 0 is lost !!!

• Later, the sender times out and re-transmits the data frame 0 (with send seq no 0):

It is possible that:

 The receiver thinks it was (new) data frame #5 that was transmitted using send seq no 0 !!!

Result:

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

• Quiz: is frame numbered with seq no 0 the frame #1 or frame #5 ???

• Operational parameters:

• Sender and receiver use 2 bits sequence numbers

 Sequence numbers = 0, 1, 2, 3

The data frames are identified as follows:

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

Notice that:

 Frame #1 and frame #5 are both identified by sequence number 0 !!!

• Suppose:

 Send window size = 3 Receive window size = 3

• Consider the following scenario:

• Sender sends 3 frames (#1, #2, #3) (due to send window size = 3, the sender cannot send more !!!)

The frames are identified with sequence numbers 0, 1 and 2 to the receiver

 All frames has been received (correctly)

Graphically:

• Receiver sends ACK0, ACK1 and ACK2

 The fate of the ACK frames are unknown

Graphically:

Notice that:

Furthermore:

 The seq. no. 0 is used to identify the data frame #5 !!!

• Suppose the receiver received a data frame with sequence number = 0:

\$64,000 question:

• Is the frame identified by sequence number #0:

 Always correspond to the frame #1 ??            or           Always correspond to the frame #5 ??

• Comment:

• Because the receive window is equal to [3,0,1]:

 The receiver is using seq no "0" to identify the data frame #5

Therefore:

 The receiver will always interpret that the second frame identified by the sequence number 0 is the frame #5

• The \$64,000 question re-phrased:

• 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 second frame with sequence number 0 is the frame #5

• Scenario 1:

• Initial state:

• Suppose all ACK frames were received correctly

And: frame 3 (= #4) is lost:

Then:

 The second frame identified by sequence number 0 is frame #5

• Scenario 2: the second frame with sequence number 0 is the frame #1

• Scenario 2:

• Initial state:

• Suppose all ACK frames were lost:

Then:

 The second frame identified by sequence number 0 is frame #0 !!!

• Conclusion:

 The receiver does not have sufficient information to distinguish these 2 case !!! The sliding window algorithm will fail to ensure reliable communication !!!

• Can we avoid ambiguous situations ?