CSCI 356 Computer Networking
Homework 4, Solution
(1) In the rdt3.0 protocol, each data packet flowing from sender to receiver contains a sequence number. At first glance,
one might think that to be useful, a sequence number should be an integer between 0 and n, where n is the total number of
packets to be sent. Yet rdt3.0 uses only a 1-bit sequence number (i.e. a 0 or a 1), and the sequence numbers are re-used
frequently. So the first and third packet will both have sequence number 0, for example. How is it that rdt3.0 can be
correct despite using 1-bit sequence numbers?
Short answer: It is because rdt3.0 assumed the network would not reorder packets, but rather only drops them, or
corrupts them, or possibly duplicates them. With this assumption, receiver only needs to check that an arriving packet is the
expected one and isn’t the previous or next packet. It can do so because both the previous and next packet have the opposite
sequence number as the expected packet.
A
B
Long answer: Suppose the sender is going to transmit packets a, b, c, d, etc. As a worstsend a:0
case scenario, assume the sender’s timeout is very short, and many packets and ACKs
get lost. In that scenario, an rdt3.0 sender would send many copies of packet a, with
send ack 0
seqno 0, causing some smaller number of acks, with ackno 0, to come back. Then
similarly for b with seqno 1, then c with seqno 0, etc. Is it “safe” to re-use 0 as the
send b:1
sequence number for c? We have to make sure there are no earlier packets that might
send ack 1
refer to seqno 0 anywhere in the network.
 Any data packets with seqno 0 were all sent by A before A sent b:1, and because the
send c:0
network does not reorder packets, they must all have arrived or been lost before b:1
arrived at B. In other words, all earlier data packets with seqno 0 are strictly above
the red line in the diagram.
 Since all seqno 0 data packets arrive at B above the red line, B will send all ack packets for seqno 0 before it ever sends
ack 1. And because the network does not reorder packets, those ack 0 packets must all have arrived or been lost before
any ack 1 arrived at A. In other words, all earlier ack packets for seqno 1 are strictly above the green line in the diagram.
This means that, at the precise moment A is about to send c:0, there are no packets anywhere in the network that refer to
seqno 0, and it is therefore safe to use seqno 0 for this packet. The same reasoning will apply for d and subsequent packets.
(2) Suppose the rdt3.0 protocol is used on a network that may delay and re-order packets arbitrarily, but never loses or
corrupts packets. For example, if one side sends five packets a, b, c, d, e in that order, back to back, then packet b could be
delayed such that it arrives third, or fourth, or even last, possibly even minutes or hours after the other packets have
arrived. Is the protocol correct? That is, will the protocol (eventually) deliver all packets in the correct order? If so, provide
a convincing argument. If not, give a specific counterexample where the protocol does not work. That is, show a packet
trace timeline, with each packet and ACK clearly labeled and showing sequence numbers, that either causes the protocol to
deadlock, causes the reciever to be misled and deliver the wrong data, or causes some other mistake to occur.
A
send a:0
send a:0
B
accept a and send ack 0
send b:1
accept b and send ack 1
The rdt3.0 protocol is not correct for networks that can reorder packets. If
there are no retransmissions, the protocol will work fine. But with
retransmissions, there are many ways the protocol can become confused by
packet reordering, either causing B to accidentally accept data out of order, or
causing a deadlock.
In the example at left, A sends a:0, times out, and then sends a:0 again. One of
those data packets (shown in red) is delayed by the network, but B receives
the other, accepts it, sends ack 0, and the protocol continues with A sending
b:1, B sending ack 1, and A sending c:0, etc. Meanwhile, the delayed copy of
a:0 finally arrives at B. Since it has seqno 0, as B is expecting, B accepts it as the legitimate next packet, displacing the
actual correct c:0 which arrives moments later.
send c:0
accept a and send ack 0
ignore c and send ack 0
A
In the example at right, A sends a:0, times out, sends a:0 again. B receives
both copies, sends ack 0 twice. one of the acks is delayed. The other ack
arrives at A, and the protocol continues with A sending b:1, B sending ack 1,
A sending c:0, etc. Suppose c:0 is lost, but soon after, the delayed ack 0
arrives at A. At this point, A thinks that c:0 was received, and starts sending
d:1. But B never got c:0, and will wait forever for a packet with seqno 0.
The protocol deadlocks, with A forever sending the wrong packet.
send a:0
send a:0
send b:1
B
accept a and send ack 0
ignore a and send ack 0
accept b and send ack 1
send c:0
send d:1
waiting for seqno 0
(3) Suppose we use a pipelined (a.k.a. window-based) protocol, such as Go-Back-N, to send data
fromradius.holycross.edu to setiathome.berkeley.edu. If we use 1KB packets (including all data and
headers) and a 100 MBps channel, what window size should we use to achieve 95% channel utilization, in the absence of
losses or errors? Note: These are real machines, so you can go measure the RTT yourself.
The RTT is around 75ms, as measured using ping from radius. In that amount of time, at 100MBps, we can send a
maximum of 100MBps*0.075s = 7500KB, or 7500 packets. That would yield 100% channel utilization. To get 95%
utilization, we should use a window size of 95%*7500 = 7125 packets = 7125KB.
(4) Suppose we use Go-Back-N with window size 3 and 8-bit sequence numbers (0 to 255), over a channel that may corrupt or delay packets but does not reorder packets. At some time t, the next in-order packet the receiver is expecting is
for sequence number 42.
1. What is the range of sequence numbers inside the sender's window at time t? There are multiple correct possible
answers here! Give all possible answers, and justify.
The receiver window is [42, 43, 44]. The sender’s window never leads ahead of the receiver’s window, it must always
be equal or trail behind. The send window could be:
[42, 43, 44] – e.g. data packets 42, 43, 44 were sent, but 42 was lost, acks for the others are on the way back.
[41, 42, 43] – e.g. ack 41 is on the way, sender has just sent data 42 and 43 but those haven’t arrived yet.
[40, 41, 42] – e.g. ack 40 & 41 are on the way, but data packet 42 hasn’t arrived yet.
[39, 40, 41] – e.g. data packets 39, 40 & 41 all arrived, and acks for all those are on the way back.
Receiver may or
Receiver is may not have
waiting
gotten these..
for this
Receiver must have gotten these
and sent ACKs already
…
37,
38,
39,
40,
41,
42,
43,
44,
Receiver must
not have gotten
these yet
45,
46,
...
four different send
windows are
possible
Sender must have sent this,
so right edge of
window is at least here
Sender can't have gotten an ACK
for this, so left edge of window is
no further than here
2. At time t, which ACK numbers are currently propagating back to the sender? Again, there are multiple correct answers here! Give all possible answers, and justify. Note: This question is tricky! There are some subtle cases (e.g.
involving losses and retransmissions of data and ACK packets) that are easy to
overlook.
A
B
From the above examples, acks 39, 40, 41, 43, 44 might be in the network at this moment. Ack 42 can’t exist, because the question said the receiver hasn’t gotten data packet
42 yet. Acks above 44 can’t exist, because the sender can’t have sent those data packets
yet. Very old acks (e.g. ack 0, 1, 2, … 35) can’t still be in the network, but in some tricky
cases involving retransmissions, certain older acks (36, 37, and 38) can still exist in the
network. An example is at right. A sent a full window (36, 37, and 38), timed out, and
resent all three packets. Three ack arrive, A advances its window and sends three new
packets (39, 40, and 41), which all arrive. At this point, B is waiting for 42. But acks (36,
37, 38) from the retransmitted packets are still on the way back.
This reasoning does not extend to earlier packets. Acks from packets before 36 can’t still
be in the network. When A first sends 38 (the red packet), the send window must have
reached [36, 37, 38] at least, so A will never again send data packet 35 or less. Those
earlier packets must all be confined above the red line, because the network doesn’t reorder packets, and their acks must all be confined above the green line, because the network doesn’t reorder acks either. So no acks with numbers 35 or less could possibly still
be in the network at time t.
36
37
[36, 37, 38] 38
timeout, resend 36
entire window 37
38
advance window
[37, 38, 39] 39
[38, 39, 40] 40
[39, 40, 41] 41
t
36
37
38
36
37
38
now
waiting
for 42
(5) With large window sizes and a fixed range of sequence numbers, pipelined protocols like Go-Back-N and SR can become
confused about whether an arriving packet is a retransmission of an old packet (with a low sequence number) or a new
packet (with a high sequence number that has simply "wrapped around"). Suppose we use 8-bit sequence numbers (0 to
255). What is the largest allowable window size that will still avoid this problem?
Short answer: There are K=256 different sequence numbers, The max window size is K/2=128. Technically, for GBN the
max send window is K-1=255 packets, since the receiver should reject out-of-order packets.
Nifty animation and explanation: http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=73
Long answer: We need a unique sequence number for each packet in the sender and receiver's combined windows. For
example, suppose the sender has sent packets 0 through 127, but hasn’t yet gotten an ACKs, so the send window is still
[0..127]. Suppose all the data packets are received, so receiver is waiting for [128…255]. If the sender retransmits some old
packet, the receiver will know it is old because the seqno will fall outside [128..255]. If, on the other hand, we used a
slightly larger window size of 129, we would have a problem. The sender could send [0..128], and the receiver after
receiving these would be waiting for [129…255, 0, 1]. If the sender decides to retransmit packet 0 or packet 1, the receiver
will mistake these retransmitted old packets as if they are new packets falling right near the end of the receive window.
For GBN, suppose the sender window is size w. The receiver only accepts the single packet with the next expected sequence
number, meaning the receive window is effectively only 1 packet. The total w+1 can't be larger than K. So w+1<=K, or
w<=K-1.
For SR, both windows are size w. In the worst case, the receiver window is w packets ahead of the sender's window, and the
two windows would together span at most 2w packets. The size K of the sequence space must therefore be at least as 2w.
That is, 2w<K, or w <= K/2.