Test by Bikram | Computer Networks | Test 1 | Question: 27

Question

A sliding window protocol uses Selective Repeat. The sender sliding window size is $32$. After receiving the first $100$ frames, the acknowledgement number that is piggybacked by the receiver along with data frame is _______.

Comments

100 --------- 34

@akash.dinkar12 this is the problem. In SR if you are sending frame x with sequence number y, you get acknowledgement as y. Not y+1  

---

this is true for both pure ack and piggybacked ack or only for piggybacking ack?.

---

Should we consider the frames from zero or 1?

Answer 1

This screenshot is taken from Kurose's book which shows that if packet0 is receuived then ack0 is sent not Ack1, hence 35 should be correct answer!

But if we refer Forozuan then answer should be 36: following screenshot is from Forozuan

In my opinion 35 is correct answer, I have noticed in one more case when Forozuan's book gave different concept than Kurose's book. Kurose's book is more relible!

Comments

same thing in forouzan too...

---

@Bikram

According to Tanenbaum, it seems that Go back- n also follows the same rule as selective repeat(i.e ack1 mean packet 1 is received properly). Please confirm?

---

@Manu plz describe Bikram sir explanation

Now as we are using Selective Repeat, this send window size= recieve window size Which is 32

Now 100%32 is 4 , bcoz we received  100 frames 

we starting from 0 for counting the sequence number . 

We have 0-63 sequence numbers , With that 64 frames can be numbered

Then 0 for 65th frame

1 for 66th frame

35 for 100th frame

Ack35 will be piggybacked

acknowledge 35 is piggybacked with the data frame .

Above calculation.

Answer 2

In Selective Repeat, Sender and Receiver both have a window size of n. But to avoid sending a duplicate packet, or sending the wrong packet that has the right number, Sender and Receiver use different sequencing.

Given, n = 32.

So, Sender numbers from 0 to 31.

Receiver numbers from 32 to 63.

 

What sender sees as 0th frame, receiver sees as 32nd.

What sender sees as 1st frame, receiver sees as 33rd...

One might say that receiver sees the frame numbers in "Excess 32"

 

So, When sender sends 100th Frame, it got sent with number 99 (because counting starts from 0). Receiver saw it as 131. (Let's not perform modulo right now for simplicity)

So, now receiver expects 132nd frame. => 132 mod 32 => 4th frame. But hold on... Receiver sees it as "Excess 32", remember? This means the receiver expects 4 + 32 = 36th frame.

---

PS: EDIT:

As per some authors, in SR, Receiver won't send the ACK of expected frame, rather it'll send the ACK of the frame successfully received.

So, it'll send ACK of 131th frame. So, 131 mod 32 => 3rd frame. Do Excess 32 => 35th frame.

Answer 3

We have 0-63 sequence numbers

With that 64 frames can be numbered

Then 0 for 65th frame

1 for 66th frame

35 for 100th frame

Ack35 will be piggybacked

Comments

you are right it will be 36...

sequence# of 101th packet= 100mod64= 36

---

I mean 35 must be the correct answer as i have shown in my answer to this question, moreover both seem correct answer.

---

35 will be the only correct anwer . Why are we using the concept of TCP acknowledgements generation in here, it is entirely different from SR. The forouzan screenshot (that too of old book(problems rectified now)) you posted is illustrating TCP acknowledgements generation (kinda) but here in SR they are independent ACKs indicating that last packest has been received safe and sound...