Data Transition & Network

Assignment 3

Aylar Khorsadnia
98100418

Problem 1. An application needs to send 100KB of data using a stop-and-wait reliable protocol. The
protocol splits the data into segments that have a 1KB application data payload. Each segment fits
in a single IP packet. The RTT is 50ms, there is no packetization delay, and no queueing delay. The
protocol uses a fixed retransmission timeout of 200ms and has no retransmission limit.
(a) How long will the transmission take, in seconds, if the network does not drop, duplicate or cor-
rupt any packets? You may assume the connection is established when you start your measurement,
so there is no additional latency from connection setup and consists only of data transmissions.
(b) Let us now suppose that the network drops each segment with a probability of 10%, indepen-
dently from segment to segment. The network drops both data and acknowledgments. What is the
expected duration of the transmission?

(a) Total number of frames needed = 100KB / 1KB = 100. Since this is stop-and-wait, the time
needed = 100 × 50 = 5000 ms = 5s.
(b) The time it takes to successfully transmit a packet is a random variable 𝑋 = 200 × 𝑌 +
50, where 𝑌 is the number of trials before the first successful transmission. Here, 𝑌 is
9 9
geometrically distributed with success probability 𝑝 = 10 × 10 = 0.81. Hence, the expected
time it takes to transmit one packet is E[𝑋] = 200 × E[𝑌] + 50 = 200( 𝑝1 − 1) + 50 = 96.9ms.
So the answer is 9690.

Problem 2. Suppose two hosts are about to open a TCP connection. The TCP headers used in the
communication are only 20 bytes long and regular (no-options) IPv4 is being used for Layer 3. If the
MTU of the link is 1260 bytes, what is the MSS?

1260 bytes - 20 bytes (TCP) - 20 bytes (IP) = 1220 bytes

Problem 3. Consider the following string of ASCII characters that were captured by Wireshark when
the browser sent an HTTP GET message (i.e., this is the actual content of an HTTP GET message).
The characters <cr><lf> are carriage return and line-feed characters (that is, the italized character
string <cr> in the text below represents the single carriage-return character that was contained at
that point in the HTTP header). Answer the following questions, indicating where in the HTTP
GET message below you find the answer.

(a) No, this transport protocol is not reliable. Here’s why:

* The receiver only acknowledges when it receives both a specific even packet (𝑃2𝑖 ) and the
next sequential odd packet (𝑃2𝑖+1 ).
* If a packet is lost, the receiver won’t send an ACK until it receives both the lost packet and
the following one.

1
 * This means the sender wouldn’t know about the missing packet until the next one in
sequence arrives.
This creates a situation where the sender might keep transmitting packets assuming ev-
erything is received correctly, while the receiver is stuck waiting for a lost packet before
acknowledging anything.
(b) Yes, there’s a modification to fix the protocol:
* Instead of waiting for both packets, the receiver can send an ACK for 𝑃2𝑖 as soon as it’s
received, even if 𝑃2𝑖+1 hasn’t arrived yet.
* The sender can maintain a window of sent packets and track acknowledgments.
* Upon receiving an ACK for 𝑃2𝑖 , the sender can move the window forward and start
transmitting subsequent packets.
* If a packet is lost, the receiver won’t acknowledge it. This will trigger a timeout on the
sender’s side for that specific packet (𝑃2𝑖 ).
* The sender can then retransmit only the missing packet (𝑃2𝑖 ) based on the timeout, without
waiting for the next one.
This modification ensures the sender is informed about missing packets promptly, allowing
for retransmission and achieving reliable data transfer. This approach is similar to Selective
Repeat protocols used in TCP (Transmission Control Protocol).

Problem 4. Suppose instead of a Three-Way Handshake, we use a Two-Way Handshake. Would there
be any problem with this method? If there is a problem, provide an example; otherwise, prove that
there is no problem.

There would be problems with using a Two-Way Handshake instead of a Three-Way Handshake
for TCP connections. Here’s the reasons:

• Incomplete Synchronization: A Two-Way Handshake only allows one party (usually the
client) to establish its sequence number (ISN) and receive acknowledgment from the other
party (server). The server wouldn’t have its own ISN acknowledged.
for example, the client sends a message indicating it’s ready to communicate (SYN). The
server receives it and acknowledges (ACK). However, the server doesn’t know if its initial
response (SYN-ACK) ever reached the client. It can’t send any data reliably until it’s sure
the client is ready to receive.
• Unreliable Communication: TCP relies on reliable, two-way communication. A Two-Way
Handshake doesn’t guarantee both parties are ready to send and receive data efficiently.

Problem 5. The sequence number in a TCP header is a 32-bit number that is sufficient to cover more
than 4 billion bytes of data! Considering that in practice the probability of sending this amount of
data is low, what is the reason for using 32 bits?

Reasoning for 32-bit Sequence Number in TCP

The sequence number in a TCP header is a 32-bit number, capable of addressing more than 4
billion bytes of data! While the likelihood of sending such a massive amount of data in a single
connection might be low, there are two reasons for using 32 bits:
1. Future Proofing: Even though current data transfers might not routinely reach 4 billion bytes,
internet traffic and data demands are constantly on the rise. A 32-bit sequence number allows
for much larger file transfers to be accommodated in the future without the need to redesign
the core TCP protocol.

Page 2
 2. Sequence Number Wrap-around: TCP relies on sequence numbers for reliable data delivery,
even if a single connection doesn’t send 4 billion bytes. The 32-bit size helps mitigate a concept
called "sequence number wrap-around."
Imagine a scenario with very rapid data transmission. With a smaller sequence number (say,
16 bits), it’s possible to exhaust all the possible sequence numbers relatively quickly. This could
cause confusion for the receiving end, as a new sequence number might appear to be a resend
of old data due to the limited range.
A 32-bit size makes wrap-around less frequent, allowing for smoother data flow over longer
connections or high-speed transfers.
In essence, the 32-bit size provides headroom for future growth and avoids potential issues with
sequence number exhaustion in high-traffic scenarios.

Problem 6. Suppose host A wants to send 10 segments of equal length to host B. For sending these
segments, a reliable protocol is used where the sender must send an acknowledgment (Ack) for each
segment it receives, and if the receiver does not receive an acknowledgment for each segment after
2RTT, it resends it. Assume RTT is constant, the sending capacity is unlimited, and the processing
time for packets at each host and along the route is negligible. If the third segment gets lost in each
of the following three scenarios, explain how long it would take to send all 10 segments in RTTs.
Explain how you arrived at this answer in each case:
(a) Stop-and-wait
(b) Go-back-N, without cumulative acknowledgment and with a window size of 4 segments
(c) Selective Repeat, without cumulative acknowledgment and with a window size of 4 segments

(a) Stop-and-wait
Steps:
1. Segments 1 and 2 are sent and acknowledged (2RTT).
2. Segment 3 is sent but lost. Since Stop-and-Wait waits for an acknowledgment before
sending the next segment, the sender waits for 2RTT (timeout) and resends segment
3.
3. Segment 3 (retransmission) is sent and acknowledged (2RTT).
4. Segments 4 to 10 are sent one by one, each requiring an acknowledgment (8RTT).

Total Time: 2RTT (initial segments) + 2RTT (segment 3 retransmission) + 8RTT (remaining
segments) = 12 RTT
(b) Go-back-N (without cumulative acknowledgment, window size of 4 segments)
Steps:

1. Segments 1, 2, and 3 are sent (1RTT).

2. Segment 3 is lost. The sender times out after 2RTT and resends segments 1 to 3
(Go-Back-N behavior).
3. Segments 1, 2, and 3 (retransmissions) are sent and acknowledged (2RTT). Since the
receiver doesn’t use cumulative acknowledgment, it acknowledges segments 1 and 2
again.
4. Segments 4 to 10 are sent one by one, each requiring an acknowledgment (7RTT).
Total Time: 1RTT (initial segments) + 2RTT (retransmissions) + 7RTT (remaining segments)
= 10 RTT
(c) Selective Repeat (without cumulative acknowledgment, window size of 4 segments)
Steps:

Page 3
 1. Segments 1, 2, and 3 are sent (1RTT).
2. Segment 3 is lost. The sender times out after 2RTT.
3. Segment 4 is sent within the window (1RTT). However, the receiver cannot acknowl-
edge segment 4 because it hasn’t received segment 3 yet (Selective Repeat behavior).
4. Segment 3 (retransmission) is sent (1RTT) upon timeout.
5. Receiver acknowledges segments 1, 2, and 3 (assuming in-order delivery) after receiv-
ing segment 3 (1RTT).
6. Segments 4 to 10 are sent one by one, each requiring an acknowledgment (7RTT).

Total Time: 1RTT (initial segments) + 1RTT (segment 4) + 1RTT (segment 3 retransmission)
+ 1RTT (acknowledgments) + 7RTT (remaining segments) = 12 RTT

Page 4