# Exercise: Sliding window protocol: Bits for sequence number

This is a task in a lecture on computer networks:

"Suppose you are designing a sliding window protocol for a 1-Mbps point-to-point link to the moon, which has a one-way latency of 1.25 seconds. Assuming that each frame carries 1 KB of data, what is the minimum number of bits you need for the sequence number?"

R = 1-Mbps = 125KBps

d_prop = 1.25 sec so I assume RTT = 2.5 sec

The solution I was given ignores the transmission delay but I calculated it to be

d_trans = 1KB/125KBps = 0.008s

Within one second you can put 125 frames into the link if you allow full utilization. I assume the task ignores the size of the acknowledgements as well as the processing and transmission delay of the receiver for simplicity. Nothing else is said about the links properties.

Since within 1 second you could send 125 frames, within 2.5 seconds you could send. 312.5 frames. If we include the senders d_trans then within 2.508 seconds we could send frames 313.5 frames until the acknowledgement for the first frame should be received. If you complete the LastFrameSent then I think you should need a send_window_size(SWS) of 314 to acknowledge each frame individually. In this case you would need Ceil(log2(314)) = 9 bits for the sequence numbers.

The solution given by the tutor says that you need at least 10 bits and part of the explanation I noted down is that (ignoring d_trans) you can send 312 frames until the first frame is received. And then you can supposedly send another 312 frames until you receive the first ACK back, so you'd need a SWS of 624.

So did I misunderstand anything about the task or did the tutor make an error by doubling the one-way-latency (which I assume to be the same as d_prop) twice? Can additionals assumptions be made regarding the properties of the link?

I saw a similar question where the link was considered the be a full-duplex link (which wasn't explained in the lecture iirc). But even if you'd consider a full-duplex link which means only the half of the bandwidth may be used then you could only send ~156 frames until you get the ACK and then you'd need 8 bits instead of 10, right?

Assuming SWS(sender window size) = RWS(receiver window size)

In this case Assume a scenario where SWS = RWS = 3 so MaxSeqNum = SWS - 1 = 2

LAF(Last Acknowledged frame) LFS(Last Frame Sent)

Sender = { [ 0, 1, 2 ], 0, 1, 2, 0, 1, 2}

Note: Sequence of packets waiting on the queue. Square bracket represent the window

Receiver = {0, 1, 2, [0, 1, 2], 0, 1, 2}

Here the packets 0, 1, 2 are obtained and window is moved further acks sent by the receiver.

but acks are lost in traffic.

So the sender didnt got the acks thinks that the packets have lost and sends the first window packets with sequence numbers 0, 1, 2. In this case the packets received are actually not distinguished by the receiver.