---

Effect of Finite Set of Sequence Numbers

---

• Put it in the proper context:
  • As we have seen, the Go-Back-N protocol using infinite set of sequence number can ensure that each frame is received exactly once.

  • Frame header that contains the frame and ACK numbers has finite length

  • When a finite set of sequence numbers (for frame and ACK) is used, the "deliver exactly once and in order" reliability guarantee cannot be guaranteed without an additional conditions.

• Illustration of the problem caused by using a finite set of sequence numbers
  • Consider an example using the following settings:
    • Total number of sequence numbers = 4 (2 bit field used in header for sequence number)
    • sender window size is 3
    • receiver window size is 2

  • Consider the following exchange of information:
    • What should the receiver do with the last frame (the right most frame with sequence number 0) ?

      Clearly, the correct thing to do is:

      • If this frame is a retransmission of the earlier frame 0, the receiver must NOT accept it.

      • If this frame is a transmission of a NEW frame (that happens to receive the sequence number 0 because the numbers "rapped around"), the receiver MUST accept it.

  • The $64,000 question is then:
    • Can we tell for sure if the last frame with sequence number 0 is a retransmission of the earlier frame 0 or a transmission of a NEW frame ???

  • The answer to this question is: NO

    Because both outcomes as possible

    1. The following scenario shows that the last frame with the sequence number can be a transmission of a NEW frame (that happens to receive the sequence number 0 because the numbers "rapped around"):

    2. The following scenario shows that the last frame with the sequence number can be a retransmission of the earlier frame 0:

  • Conclusion:
    • When finite sequence numbers are used, it is possible for to create a situation where the same sequence number will be used for a retransmission and a new transmission

  • Now that we know what is the problem, we are better equipped to find a solution.

    Next we will see that:

    The error situations given above cannot arise when:

    Sender Window Size + Receiver Window Size <= # Sequence number used

  ---

  ---

• Avoiding numbering confusion
  • Fact:
    The sequence number X will exit the receiver's window before it exits the sender's window.

  • Derived Fact:
    The receiver's window is always ahead of the sender's window.

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

    From the operation of the sliding window protocol, the receiver's window is always ahead of the sender's window:

    (because when the frame X is received, the receiver sends Ack X and immediately slide its window. But the sender window will only slide when the corresponding ACK is received - this will always be later !).

    ---

    ---

  • Consider the worst case difference in the sender and receiver windows:

    In the worst case scenario, the receiver has received every frame transmitted by the sender and moved its window as far away as possible. In the mean time, the sender's window did not move at all - because all Ack messages were lost.

    Example:

    ---

    ---

  • If in the worst case scenario, sequence of numbers has NOT rapped around yet, then the receiver will NOT accept a retransmission as a NEW transmission:

  • On the other hand, if in the worst case scenario, sequence of numbers has rapped around already, then the receiver WILL accept a retransmission as a NEW transmission:

    ---

    ---

    So, to ensure that there is no confusion about whether a frame is a retransmission or a new frame, we must make sure that in this worst case, the sender and receiver windows do not have any sequence number in common (i.e., do not overlap).

    If the sender and receiver windows do not ever have any sequence number in common, then the receiver can use this simple way to decide on a received frame:

    • A frame with a sequence number within the Receiver window are new frames

    • A frame with a sequence number outside the Receiver window are retransmission.

    And there will never be the case where the same sequence number is used for a new frame and a retransmission

  ---

  ---

• Example Revisited

  • Let us apply this result to the above example:
    • Sender window size = 3
    • Receiver window size = 2

    • Worst case senario:

    • So according to the discussion above, if we use 5 sequence numbers (0, 1, 2, 3, 4), there will be no confusion whether a frame is new or a retransmission.

  • The first case of the earlier example of the "confusion example" above is shown here using sequence numbers (0, 1, 2, 3, 4):

    • The number of this frame is now in the receiver's window !!!

    • We see that the receiver can tell that the frame is new

  • The second case of the earlier example of the "confusion example" above is shown here using sequence numbers (0, 1, 2, 3, 4):

    • The number of this frame is NOT in the receiver's window !!!

    • We can see that the receiver can tell that the frame is a retransmission

  ---

• Practical Implementation of this result

  • OK, how do you apply this knowledge in practice ?
    • Each frame has a field to hold a transmission sequence number (and a field to hold the sequence number for the ACK !)

    • If this field has N bits, then the number of different sequence numbers available is 2^N

    • We must make sure that: SWS + RWS <= 2^N

    • SWS = Sender's Window Size
    • RWS = Receiver's Window Size

  • We can specify a tigher relationship if we use some common sense...

    Is it practical to use SWS > RWS ?

    No... because the receiver will not buffer more than RWS frames (any frames received in excess to the reserved buffer space will be discarded).

  • Therefore:
    • RWS <= 2^N-1
    • SWS <= min(2^N-1, RWS), usually: SWS = RWS