Computer Networks

Answer: (iii) three

TCP connection establishment uses the three-way handshake:

1. Client → Server: SYN (seq = x)
2. Server → Client: SYN + ACK (seq = y, ack = x+1)
3. Client → Server: ACK (ack = y+1)

After step 3 the connection is established and data can flow.

Answer: (i) TCP guarantees a minimum communication rate

Why: TCP provides reliable, in-order, congestion-controlled byte-stream delivery, but it never reserves bandwidth or guarantees any minimum data rate — the achievable rate depends on network conditions and the congestion window. Options (ii), (iii) and (iv) are all standard TCP services (in-order delivery via sequence numbers, window reduction on congestion, and retransmission on loss).

Answer: (ii) port address

Why: A port number (port address) identifies a specific process/application on a host, enabling transport-layer process-to-process (end-to-end) delivery — e.g. port 80 → web server. The physical address identifies a NIC, the logical (IP) address identifies the host itself, and "specific address" is not a recognised addressing category.

Answer: (iii) 7 MSS

Working: Slow start doubles the window each transmission until the threshold is reached; after that congestion avoidance adds 1 MSS per transmission. On a time-out, ssthresh = cwnd / 2 and slow start resumes from the initial window.

Transmission	Window at start	Phase	Result
1st	2 MSS	Slow start	doubles → 4 MSS
2nd	4 MSS	Slow start	doubles → 8 MSS
3rd	8 MSS	Threshold (8 MSS) reached → congestion avoidance	+1 → 9 MSS
4th	9 MSS	Congestion avoidance	+1 → 10 MSS
5th	10 MSS	Congestion avoidance	time-out occurs
6th	2 MSS	Slow start restarts (new threshold = 10/2 = 5 MSS)	doubles → 4 MSS
7th	4 MSS	Slow start	would double to 8, but not permitted (8 > 5) → capped at 5 MSS
8th	5 MSS	Congestion avoidance	+1 → 6 MSS
9th	6 MSS	Congestion avoidance	+1 → 7 MSS
10th	7 MSS	Congestion avoidance	+1 → 8 MSS

So the congestion window at the tenth transmission is 7 MSS.

Why not the others: 14 MSS assumes the time-out was ignored and growth stayed linear (10 → 11 → … → 14); 12 MSS likewise ignores the multiplicative decrease; 8 MSS would require doubling past the new 5 MSS threshold, which congestion avoidance forbids.

TCP (Transmission Control Protocol) is a connection-oriented, reliable transport-layer protocol of the TCP/IP suite that provides process-to-process (end-to-end) communication between applications on hosts.

• Establishes a logical connection first using the three-way handshake before data transfer.
• Provides reliability by sequencing, acknowledgement, retransmission of lost/duplicate segments, and error detection.
• Offers flow control (sliding window) and congestion control (slow start, congestion avoidance).
• Delivers a byte-stream service to the application; uses 20-byte headers and ports for multiplexing.

Answer: (ii) connection less

UDP (User Datagram Protocol) is connectionless: it sends independent datagrams with no handshake, no connection state, no acknowledgements, and no retransmission. It is unreliable but fast and has low overhead, so it suits DNS, streaming, VoIP, and gaming. TCP is the connection-oriented transport protocol.

Answer: (iii) the process-to-process communication

Why: The transport layer uses port numbers to deliver data from a sending process on one host to the correct process on the destination host (it also performs multiplexing/demultiplexing). Node-to-node communication is the data link layer's job, and "application-to-application" is not the standard term — the application layer connects user-facing software, while the transport layer beneath it handles processes.

Answer: (i) stream of bytes

Why: TCP delivers an ordered, reliable byte stream to the application — it has no notion of message boundaries (characters or lines) and exposes no record framing. "Packets" is the network-layer term (IP datagrams); TCP segments are simply chunks of the byte stream that it numbers, sends and acknowledges by byte offset.

Answer: (i) Host to host

The classic TCP/IP model has four layers: Application - Host-to-Host - Internet - Network Access. The Host-to-Host layer (later also called the transport layer) provides process-to-process, end-to-end delivery using port numbers and the protocols TCP and UDP - precisely the service offered by the OSI transport layer (layer 4).

The Internet layer (ii) corresponds to the OSI network layer (3): it handles IP addressing, routing and best-effort datagram delivery. The Application layer (iii) merges the OSI session, presentation and application layers (5, 6, 7). The Network Access layer (iv) merges the OSI data link and physical layers (1, 2).

Answer: (ii) 10001

Why: A TCP segment's sequence number is the number of the first byte of data it carries, not the last byte or a byte count. Since the file's first byte is numbered 10001 and the whole file goes in one segment, the segment carries bytes 10001 through 11000 with sequence number 10001; the next byte's number (11001) would become the ACK number, while 10000/12001 are off by one block.

Answer: (i) Transport

The transport layer provides process-to-process (end-to-end) delivery using port numbers to identify the sending and receiving applications (TCP and UDP). The network layer gives host-to-host delivery using IP addresses, and the data link layer gives node-to-node delivery using MAC addresses.

Answer: (iv) increases exponentially

Why: In slow start the congestion window grows by one MSS for every ACK received, which doubles cwnd every RTT (1 -> 2 -> 4 -> 8 ...), i.e. exponential growth. Linear (additive) increase of +1 MSS per RTT begins only after cwnd reaches ssthresh, in the congestion-avoidance phase.

Answer: (iii) is connection-oriented and reliable

Why: TCP opens a connection with a 3-way handshake and guarantees ordered, error-free, duplicate-free delivery of the byte stream using sequence numbers, cumulative ACKs, a header checksum, retransmission and flow control. It runs at the transport layer, not the data link layer, so (i) is wrong; it is reliable, so (ii) is wrong; and "connectionless and unreliable" describes UDP, not TCP, ruling out (iv).

Minimum Frame Size for 50% Utilization on a Stop-and-Wait Link

Given: bit rate $R = 64$ kbps, one-way propagation delay $T_p = 20$ ms, ACK transmission time and node processing delay are negligible, target utilization $U \ge 50\%$.

Step 1: Time for one stop-and-wait cycle

One cycle = transmit the frame + propagate to receiver + propagate the ACK back:

$$T_{cycle} = T_t + T_p + T_p = T_t + 2T_p$$

Step 2: Utilization formula

$$U = \frac{\text{time the link is busy sending data}}{\text{total cycle time}} = \frac{T_t}{T_t + 2T_p}$$

Step 3: Apply the 50% condition

$$0.5 \le \frac{T_t}{T_t + 0.040}$$

$$0.5\,(T_t + 0.040) \le T_t \;\Longrightarrow\; 0.5T_t + 0.020 \le T_t$$

$$0.020 \le 0.5\,T_t \;\Longrightarrow\; T_t \ge 0.040\ \text{s} = 40\ \text{ms}$$

So the frame must occupy the link for at least 40 ms, i.e. $T_t \ge 2T_p$.

Step 4: Convert transmission time into frame size

$$L = R \times T_t = 64{,}000\ \text{bits/s} \times 0.040\ \text{s} = 2560\ \text{bits}$$

$$L = \frac{2560}{8} = 320\ \text{bytes}$$

Check

$T_t = 320 \times 8 / 64000 = 0.04$ s, so $U = 0.04/(0.04 + 0.04) = 0.5$, i.e. exactly 50%.

Final answer: the minimum frame size is 320 bytes. Any frame of 320 bytes or more yields a utilization of at least 50%.

TCP AIMD: Congestion Window at the End of the 10th Transmission

Given: $cwnd = 2$ MSS at the start of slow start, $ssthresh = 8$ MSS at the first transmission, a timeout occurs during the 5th transmission.

Rules used:

• Slow start (SS): cwnd doubles each RTT (2 -> 4 -> 8 ...) but stops doubling once it reaches ssthresh.
• Congestion avoidance (CA): cwnd grows additively by 1 MSS per RTT.
• Timeout: $ssthresh = cwnd/2$, then $cwnd$ resets to 1 MSS and slow start restarts.

Step 1: Behaviour up to the timeout

Transmission	1	2	3	4	5
cwnd (MSS)	2	4	8	9	10
Phase	SS	SS	SS, reaches threshold	CA	CA, timeout occurs

At transmission 3 the window hits $8 = ssthresh$, so from transmission 4 onward congestion avoidance adds 1 MSS per RTT: $8 \to 9 \to 10$.

Step 2: Effect of the timeout in the 5th transmission

$$ssthresh_{new} = \frac{10}{2} = 5\ \text{MSS}, \qquad cwnd = 1\ \text{MSS}$$

Step 3: Behaviour after the timeout

Transmission	6	7	8	9	10
cwnd (MSS)	1	2	4	5	6
Phase	SS	SS	SS, clamped at threshold 5	CA	CA
cwnd at end of transmission	2	4	5	6	7

Transmission 8 doubles $4 \to 8$ but is capped at the new threshold, $\min(8, 5) = 5$ MSS; with $cwnd = ssthresh = 5$ the connection switches to congestion avoidance, which adds exactly 1 MSS per RTT: $5 \to 6 \to 7$.

Final answer: the congestion window size at the end of the 10th transmission is 7 MSS.

Sliding Window Protocol at the Transport Layer

The sliding window protocol combines pipelined transmission with reliability and flow control. Instead of waiting for an ACK after every segment (stop-and-wait), both sender and receiver maintain a window — a contiguous range of sequence numbers that may be outstanding at any instant.

Sender side

• The send window covers [SND.UNA … SND.NXT + usable space]: every sequence number inside it may be transmitted immediately, without waiting for an acknowledgement, so the link stays busy (pipelining).
• The window slides right only when a cumulative ACK arrives, which frees sequence space for new data.
• The usable window is min(cwnd, rwnd) — the congestion window (network congestion control) and the receiver's advertised window (flow control) — so the sender can overflow neither the network nor the receiver's buffer.
• On a time-out or 3 duplicate ACKs, the unacknowledged part of the window is retransmitted (Go-Back-N retransmits the whole window; Selective Repeat / TCP retransmits only the missing segments, optionally with SACK).

Receiver side

• The receive window is the set of sequence numbers it is currently willing to accept, decided by its free buffer space.
• This size is advertised to the sender in every segment (TCP Window field, 16 bits) — this is TCP's flow-control mechanism.
• The receiver returns cumulative ACKs; out-of-order segments are buffered (TCP, Selective Repeat) or discarded (Go-Back-N).

Example — window size = 4

Sender:   [ 1  2  3  4 ]                 initial window: 4 unacked segments
            send 1,2,3,4  ---------------------------->   Receiver accepts 1-4
ACK for 1 arrives ->  [ 2  3  4  5 ]      window slides, slot freed
ACK for 1,2,3 arrives ->       [ 4  5  6  7 ]
(ACK lost / time-out)  ->  retransmit from SND.UNA onward

Comparison of window-based protocols

Aspect	Go-Back-N	Selective Repeat	TCP
Out-of-order frame	Discarded	Buffered & accepted	Buffered & accepted
What is retransmitted	Entire window	Only lost frames	Only lost segments (SACK)
Sender window	≤ 2ⁿ − 1	≤ 2ⁿ⁻¹	min(cwnd, rwnd)
Receiver window	1	> 1	> 1
Error control	Time-out / dup ACK	Time-out per frame	Time-out + fast retransmit

Advantages: high link utilisation, natural place for flow control and error recovery, and it bounds the number of unacknowledged bytes. Limitation: the window must never exceed the sequence-number space (hence the 2ⁿ⁻¹ / 2ⁿ − 1 limits), or duplicate sequence numbers would be ambiguous.

Both are traffic-shaping techniques used for congestion control. They regulate the rate at which packets enter the network.

1. Leaky bucket algorithm

Idea: a bucket with a small hole at the bottom. Water (packets) may arrive at any rate, but it leaks out at a constant rate. If the bucket is full, incoming water overflows and is discarded.

  bursty input  →  [ bucket (buffer) ]  →  constant-rate output
                          ↓ overflow
                       discarded

Working:

1. Incoming packets are placed in a finite queue (the bucket).
2. Every clock tick, packets are sent out at a fixed rate (e.g. one packet or n bytes per tick).
3. If the queue is full, arriving packets are dropped.

Properties:

• Converts bursty traffic into smooth, constant-rate traffic.
• Output rate never exceeds the leak rate, however large the burst.
• Simple to implement (a FIFO queue).
• Drawback: cannot exploit idle time, so a host that was quiet for a long time still cannot send a burst, and it may drop packets even when the network is free.

Byte-counting version (variable-size packets): each tick, send packets while the total bytes sent ≤ n.

2. Token bucket algorithm

Idea: the bucket holds tokens, generated at a constant rate (one every ΔT seconds) up to the bucket capacity C. To send a packet, the host must remove a token (or tokens equal to the packet size). Unused tokens accumulate, so after an idle period the host can send a burst.

  tokens generated at rate r  →  [ bucket capacity C ]
  packet arrives → token available? yes: send, remove token / no: wait (or drop)

Working:

1. Tokens are added at rate r; extra tokens beyond capacity C are discarded.
2. An arriving packet needs a token to be sent; if none is available it waits (or is dropped/marked).
3. Idle hosts save tokens, allowing bursts of up to C packets at full link speed.

Maximum burst length: S = C / (M − r), where M is the maximum output rate and r the token rate.

Example: r = 1 token/ms, C = 5. After 5 ms of idleness the host may send 5 packets back-to-back, and afterwards only 1 packet per ms.

Comparison

Basis	Leaky bucket	Token bucket
Output rate	Constant (fixed)	Variable; bursts allowed up to bucket size
Idle periods	Not exploited	Saved as tokens for later bursts
What is stored	Packets	Tokens
Bucket full	Packets are discarded	Tokens are discarded, not packets
Burst handling	Smooths bursts completely	Permits controlled bursts
Best for	Strictly uniform traffic	Bursty traffic with an average-rate limit

Simple JavaScript sketch of the token bucket

class TokenBucket {
  constructor(capacity, ratePerSec) {
    this.capacity = capacity; this.rate = ratePerSec;
    this.tokens = capacity;   this.last = Date.now();
  }
  allow(cost = 1) {
    const now = Date.now();
    this.tokens = Math.min(this.capacity, this.tokens + (now - this.last) / 1000 * this.rate);
    this.last = now;
    if (this.tokens >= cost) { this.tokens -= cost; return true; }   // send
    return false;                                                     // wait/drop
  }
}

Efficiency of a 16-Byte TCP Transmission

Given: useful data = 16 bytes; TCP header = 20 bytes (no options); IP header = 20 bytes (no options); Ethernet header = 6 (destination MAC) + 6 (source MAC) + 2 (type) = 14 bytes and trailer (FCS) = 4 bytes.

Efficiency = useful data ÷ total bytes transmitted on that layer.

1. Efficiency at the TCP level

$$\eta_{TCP} = \frac{16}{16 + 20} = \frac{16}{36} = 0.4444$$

η_TCP = 44.4 % (overhead 20 bytes of TCP header).

2. Efficiency at the IP level

The IP packet carries the TCP header + data:

$$\eta_{IP} = \frac{16}{16 + 20 + 20} = \frac{16}{56} = 0.2857$$

η_IP = 28.6 % (overhead = 20-byte IP header + 20-byte TCP header = 40 bytes).

3. Efficiency at the data link level (Ethernet)

The Ethernet frame = 14-byte header + (IP packet = 56 bytes) + 4-byte FCS:

$$\eta_{DLL} = \frac{16}{16 + 20 + 20 + 14 + 4} = \frac{16}{74} = 0.2162$$

η_DLL = 21.6 %

Note: the frame payload is 16 + 20 + 20 = 56 bytes, which is above Ethernet's 46-byte minimum payload, so no padding is added — 74 bytes is the true frame size.

If the 8-byte preamble and the 12-byte interframe gap on the wire are also counted: $\eta = \frac{16}{74+20} = \frac{16}{94} = 17.0\%$.

Summary

Level	Useful bytes	Total bytes	Efficiency
TCP	16	36	44.4 %
IP	16	56	28.6 %
Data link (Ethernet)	16	74	21.6 %

As expected, efficiency falls monotonically as each layer adds its own header to the same 16 bytes of useful data.

Congestion Control at the Transport Layer

Congestion occurs when too many hosts inject traffic into a part of the network faster than its links/routers can drain it — queues overflow, packets are dropped, delays rise and throughput can collapse. Detecting congestion and curing it are two different things: routers can detect it, but only the end hosts can reduce the offered load, which is why the transport layer must participate.

Why transport-layer control is necessary even though congestion is a network-layer problem

Aspect	Network layer	Transport layer
View	Local — one router's queue	End-to-end across the whole path
Can detect congestion?	Yes (buffer overflow, ECN bits, queue delay)	Yes (loss, RTT growth, duplicate ACKs)
Can throttle traffic?	Only per-packet (drop/mark/ECN) — cannot tell the source to slow down persistently	Yes — the sender controls its own sending rate
State kept	Ideally stateless (no per-flow state)	Per-connection state (cwnd, ssthresh)
Scope	Works only while packet is in that router	Adapts to route changes, cross traffic anywhere on path

• The network layer sees only a local snapshot; congestion is an aggregate, end-to-end phenomenon, so only an end-to-end mechanism can react correctly to it.
• IP routers are designed to be stateless and forward packets fast; holding per-connection rate information for millions of flows at every router is impractical (scaling, memory, processing).
• Cross traffic appears/disappears constantly and routes change — the sender must continuously adapt its rate, which only the source can do.
• Modern IP offers ECN: routers mark packets instead of dropping them, but the reaction (slowing down) still happens in TCP.

Why TCP has congestion control and UDP does not

TCP maintains a congestion window (cwnd); the effective sending window is min(cwnd, rwnd). It starts with slow start (exponential growth of cwnd from 1 MSS until ssthresh), then switches to congestion avoidance (linear +1 MSS/RTT). On 3 duplicate ACKs it does fast retransmit/fast recovery (halve cwnd); on RTO it resets cwnd to 1 MSS and doubles ssthresh — the classic AIMD (additive-increase/multiplicative-decrease) behaviour that keeps the network stable and fairly shared.

UDP has no congestion control because it is connectionless: there is no connection setup, no sequence numbers/ACKs, no retransmission and therefore no feedback signal to tell it that congestion occurred. It also keeps no per-connection state to hold a cwnd. UDP apps (DNS queries, RTP streaming) are typically short, delay-sensitive, or handle quality at the application layer (e.g. RTP/RTCP); if a UDP datagram is lost to congestion, it is simply dropped rather than retransmitted.

(Note: because uncontrolled UDP harms everyone, mechanisms like LEDBAT and QUIC-over-UDP implement congestion control above the transport — confirming that the control itself must exist somewhere, but not in connectionless UDP itself.)

TCP: Reliable Connection over an Unreliable Network

The underlying IP service is best-effort: it can lose, duplicate, reorder or corrupt datagrams and offers no timing guarantees. TCP sits above IP and adds connection-oriented, end-to-end reliability so that the application sees a dependable, in-order byte stream despite that hostile network.

How TCP builds reliability

1. Connection establishment & termination (3-way handshake). SYN → SYN-ACK → ACK fixes initial sequence numbers on both sides (avoiding old duplicate segments), establishes negotiated parameters (MSS, window scale), and symmetrically closes the connection with FIN/ACK so no data is lost.
2. Sequence numbers and acknowledgements. Every byte carries a sequence number; the receiver ACKs the next expected byte number. This detects lost segments and eliminates duplicates.
3. Retransmission on timeout/RTO. A retransmission timer (with RTT estimation and Karn's algorithm / exponential back-off) resends unacknowledged data. Fast retransmit on 3 duplicate ACKs avoids waiting for the full timeout.
4. Flow control (sliding window). The advertised receive window prevents the sender from overrunning the receiver's buffer — reliability at the endpoints.
5. Checksum. A 16-bit header+data checksum detects corruption; the segment is discarded and retransmitted.
6. Ordered delivery. The receiver re-sequences segments that arrive out of order using the sequence numbers before handing data to the application.
7. Congestion control (slow start, congestion avoidance, fast recovery). Even though the network is unreliable and may drop packets under load, TCP adapts its sending rate so that congestion (the main cause of loss) is minimised — the sender cooperates with the network instead of overloading it.

Why the network can stay unreliable

Reliability is placed end-to-end at the transport layer rather than in every router. Routers simply forward best-effort datagrams; TCP endpoints detect and repair loss. This is the end-to-end argument: a simpler, faster core plus intelligence at the edges yields a reliable service over an unreliable network.

In short: TCP converts IP's unreliable, connectionless datagram service into an error-free, ordered, flow- and congestion-controlled byte stream using connections, sequencing, ACKs, timers and retransmission.

Difference between TCP and UDP

Parameter	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
Connection	Connection-oriented (3-way handshake first)	Connectionless — no setup/teardown
Reliability	Reliable: ACKs, retransmission, sequencing	Unreliable: best-effort delivery
Ordering	Segments delivered in order using sequence numbers	No ordering guarantee
Error/flow control	Yes — checksum + retransmission, sliding-window flow control	Only a checksum; no retransmission, no flow control
Congestion control	Yes — slow start, congestion avoidance, fast recovery	None
Header overhead	20 bytes minimum (up to 60 B with options)	Fixed 8 bytes
Data unit	Segment (byte stream, no message boundaries)	Datagram (message-oriented, preserves boundaries)
Duplication	Duplicates detected and discarded	Possible duplicates passed to the app
Application	HTTP, SMTP, FTP control, file transfer, web, e-mail — where accuracy matters	DNS, DHCP, SNMP, streaming voice/video, VoIP, online games — where speed matters
Speed / latency	Slower due to handshakes and ACK overhead	Faster, low overhead
Broadcast/multicast	Not supported	Supported
Termination	Graceful connection release (FIN)	No termination concept

In brief: TCP trades speed for guaranteed, ordered, error-free delivery over a virtual connection; UDP is lightweight and fast, delivering datagrams with no guarantees — chosen when timeliness matters more than perfect accuracy (or when the application implements its own reliability).

Corrupted Destination Port & TCP Header for an FTP Segment

1. How the receiving TCP reacts to the corrupted port

The IP datagram reached host 130.14.16.19/16 (same /16 network as the intended 130.14.16.17), so IP delivers it normally — IP only checks the network/host address, not the transport port. The problem is at TCP:

1. TCP first verifies its checksum (which covers the TCP header, the pseudo-header of source+destination IP, and the data). A corrupted destination-port field changes the header, so the checksum fails → TCP silently discards the segment and sends no ACK and no ICMP error (TCP never reports errors for damaged segments, to avoid error-reporting storms).
2. The sender receives no ACK → its retransmission timer expires → it retransmits the segment; the original (correct) segment then reaches 130.14.16.17.
3. Even if the bad port passed checksum (hypothetically), TCP at .19 would look up the port in its connection table, find no socket bound to that port, discard the segment and reply with a TCP RST (reset) segment to the sender, tearing down the bogus connection attempt.

Key point: ports are used only for demultiplexing at the endpoints, never for routing — so corruption cannot mis-route the packet; it only causes local delivery failure + retransmission/RST.

2. TCP header for a message from an FTP client to an FTP server (data = 40 bytes)

Well-known port = 21 (FTP control). Ephemeral port chosen = 52345 (in the dynamic range 49152–65535). Header length = 20 bytes (5 words), so total segment = 20 + 40 = 60 bytes.

Field	Value	Remark
Source Port	52345	ephemeral port, client side
Destination Port	21	FTP well-known port
Sequence No.	1000	(example) first byte of this segment
Acknowledgment No.	5000	(example) next byte expected from server
Data Offset	5	5 × 4 = 20-byte header, no options
Reserved	000	—
Flags	URG=0, ACK=1, PSH=1, RST=0, SYN=0, FIN=0	pure data segment
Window	8192	advertised receive window (example)
Checksum	0x0000	filled with 0s as instructed
Urgent Pointer	0	URG=0, field unused
Options	none	header stays 20 bytes
Data	40 bytes	e.g. an FTP command/response

Total length = 60 bytes.

Token Bucket: Time the Host Can Transmit at Full Rate

Given: peak transmission rate $R_{out} = 6$ Mbps, token generation rate $r = 1$ Mbps, bucket capacity $B = 8$ megabits, bucket initially full.

Reasoning

The host may send at the full 6 Mbps only while the bucket still holds tokens. During transmission the bucket is simultaneously being refilled, so tokens are consumed at the net rate:

$$r_{net} = R_{out} - r = 6 - 1 = 5\ \text{Mbit/s}$$

The initial 8 Mbit of tokens therefore lasts:

$$t = \frac{B}{r_{net}} = \frac{8\ \text{Mbit}}{5\ \text{Mbit/s}} = 1.6\ \text{s}$$

Verification

In $t = 1.6$ s:

• tokens used = $6 \times 1.6 = 9.6$ Mbit
• tokens available = initial $8$ Mbit + refilled $1 \times 1.6 = 1.6$ Mbit = $9.6$ Mbit

Both match, so the bucket empties exactly at $t = 1.6$ s. After that the host is limited to the sustained rate of 1 Mbps.

Final answer: the computer can transmit at the full 6 Mbps for 1.6 seconds (sending 9.6 Mbit), after which it is throttled to 1 Mbps.

TCP flow control

Flow control ensures the sender does not send data faster than the receiver can process it, so the receiver's buffer does not overflow. TCP uses a sliding window in which the receiver advertises how much free buffer space it has (the receive window, rwnd) in every segment's Window field (16 bits).

Variables used

At the receiver (connection has a receive buffer of size RcvBuffer):

Variable	Meaning
RcvBuffer	Total size of the receive buffer
LastByteRcvd	Number of the last byte that arrived from the network and was placed in the buffer
LastByteRead	Number of the last byte the application has read from the buffer
rwnd	Free space advertised to the sender

Buffered data = LastByteRcvd − LastByteRead ≤ RcvBuffer, so

rwnd = RcvBuffer − (LastByteRcvd − LastByteRead)

The receiver puts the current rwnd in the window field of every ACK it sends.

At the sender:

Variable	Meaning
LastByteSent	Last byte sent
LastByteAcked	Last byte acknowledged
rwnd	Latest window advertised by the receiver

The sender keeps the amount of unacknowledged (in-flight) data within the advertised window:

LastByteSent − LastByteAcked ≤ rwnd

(In practice the limit is min(rwnd, cwnd), where cwnd is the congestion window.)

Working

1. At connection setup, rwnd = RcvBuffer.
2. The sender transmits up to rwnd bytes without waiting for ACKs.
3. As data arrives and the application reads it, the receiver updates rwnd and sends it back with each ACK.
4. If the application is slow, the buffer fills, rwnd shrinks, and the sender slows down.
5. When rwnd = 0, the sender stops. To avoid deadlock, it keeps sending 1-byte probe segments so the receiver can reply with a new rwnd once buffer space becomes free.
6. When space opens, the receiver sends a window update and transmission resumes.

Example

RcvBuffer = 4000 bytes. Sender sends bytes 0–2999. Receiver has read 1000 bytes (LastByteRead = 999, LastByteRcvd = 2999):

rwnd = 4000 − (2999 − 999) = 2000. The sender may have at most 2000 unacknowledged bytes.

Silly window syndrome

Tiny window updates would cause tiny segments. It is avoided by Clark's solution (receiver advertises a window only when it has a useful amount of space free) and Nagle's algorithm (sender waits to combine small writes).

Protocol Field (Network Layer) vs Port Numbers (Transport Layer)

Common purpose

Both fields are demultiplexing identifiers. Many protocols / many applications share the same physical network and the same IP address, so at the receiver something must say which upper-layer entity should get the payload. Both fields answer exactly that question — they let several users of a channel coexist (multiplexing at the sender, demultiplexing at the receiver).

Comparison

Feature	Protocol field (IP header)	Port numbers (TCP/UDP header)
Layer	Network layer (Layer 3)	Transport layer (Layer 4)
Size	8 bits	16 bits each
Number of fields	One	Two (source + destination)
Identifies	The next-layer protocol to which the payload is handed (TCP = 6, UDP = 17, ICMP = 1, IPv6 = 41)	The sending/receiving process (application socket)
Value assigned by	The sending host's IP layer	The OS/application — well-known ports 0–1023, ephemeral 49152–65535
Demultiplexing done by	Receiver's IP layer → protocol module	Receiver's transport layer → process
Namespace	Small, closed set of registered protocols	Very large, dynamic set of concurrent applications

Why two port fields but only one protocol field?

A received IP datagram contains the payload of exactly one protocol — IP delivers it to one and only one next layer — so a single "next protocol" field completely identifies the destination; there is no "sender protocol" to represent, since IP itself is always the sender at that layer. A transport segment, however, is part of a two-way conversation: the receiver must know which remote process it came from (so it can reply) and which local process it is for. Without a source port the reply could not be routed back to the right socket at the original host — hence, exactly as with source and destination IP addresses, two port fields (source and destination) are required.

Why is the protocol field only half the size of a port number?

• The protocol field is 8 bits = 256 values, which is ample because only a few dozen protocols are registered at the network layer; it merely has to point to a subsystem (TCP, UDP, ICMP, …) inside the host — a small, essentially fixed, closed set.
• A port number is 16 bits = 65 536 values because it must name individual processes/sockets on one machine: every concurrent web, mail, DNS, SSH, streaming … connection needs its own port, and both well-known and dynamically assigned (ephemeral) ports share that range. Two 16-bit fields also yield 2³² distinct (source, destination) socket pairs per IP address pair, which is necessary for many simultaneous connections between the same two hosts.
• So the difference in size simply reflects the difference in the size of the two namespaces: protocol identification is coarse-grained, process identification is fine-grained.

UDP segment format

UDP (User Datagram Protocol) is a connectionless, unreliable transport protocol with a very small 8-byte header:

 0                16                31
+-----------------+-----------------+
|  Source Port    | Destination Port|
|    (16 bits)    |    (16 bits)    |
+-----------------+-----------------+
|     Length      |    Checksum     |
|    (16 bits)    |    (16 bits)    |
+-----------------+-----------------+
|         Data (application)        |
+-----------------------------------+

Field	Size	Description
Source port	16 bits	Port of the sending process (optional; 0 if unused). Used as the reply address
Destination port	16 bits	Port of the receiving process (e.g. 53 = DNS, 67/68 = DHCP)
Length	16 bits	Length of the UDP header + data in bytes (minimum 8)
Checksum	16 bits	Error detection over the pseudo-header, UDP header and data

Features: connectionless (no handshake), no acknowledgements, no retransmission, no flow or congestion control, preserves message boundaries, low overhead and fast. Used for DNS, DHCP, streaming, VoIP, online games, SNMP.

UDP checksum

The checksum is the 1's complement of the 1's complement sum of all 16-bit words of the pseudo-header (source IP, destination IP, zero byte, protocol = 17, UDP length), the UDP header (with the checksum field set to 0) and the data. If the total length is odd, the data is padded with a zero byte.

Sender's steps

1. Divide the data into 16-bit words.
2. Add all words using 1's complement addition (any carry out of the top bit is wrapped around and added back to the least significant bit).
3. Complement the result (invert every bit). This is the checksum.

Receiver's steps

Add all the words including the checksum. If there is no error, the sum is 1111 1111 1111 1111. Any 0 bit means an error, and the datagram is discarded.

Example

Three 16-bit words:

Word 1 :  0110 0110 0110 0110   (0x6666)
Word 2 :  0101 0101 0101 0101   (0x5555)
Word 3 :  0000 1111 0000 1111   (0x0F0F)

Step 1: Word 1 + Word 2

  0110 0110 0110 0110
+ 0101 0101 0101 0101
= 1011 1011 1011 1011   (no carry)

Step 2: add Word 3

  1011 1011 1011 1011
+ 0000 1111 0000 1111
= 1100 1010 1100 1010   (0xCACA, no carry)

Step 3: 1's complement of the sum

Sum        = 1100 1010 1100 1010
Checksum   = 0011 0101 0011 0101   (0x3535)

Verification at the receiver: 0xCACA + 0x3535 = 0xFFFF = 1111 1111 1111 1111, so the data is accepted.

Wrap-around example: 1111 1111 1111 1111 + 0000 0000 0000 0010 = 1 0000 0000 0000 0001; wrapping the carry gives 0000 0000 0000 0010.

Limitations: the checksum detects most single-bit and burst errors but cannot correct them, and two compensating errors can go undetected. In IPv4 the checksum is optional (0 means "not computed"); in IPv6 it is mandatory.

TCP Header and UDP Checksum Verification

Part A — TCP header

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data Offset | Reserved  |C|E|U|A|P|R|S|F|      Window         |
|     (4)      |    (4)    |W|C|R|C|S|Y|I|N|N|    (16 bits)      |
|              |           |R|E|G|K|H|T|N|N|                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |       Urgent Pointer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Options (variable, 0–40 bytes)     |    Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field description

Field	Bits	Purpose
Source / Destination Port	16 + 16	Identify the sending and receiving processes (sockets) for demultiplexing
Sequence Number	32	Number of the first data byte of this segment (SYN/FIN each consume one number)
Acknowledgment Number	32	Next byte the receiver expects — valid only when ACK = 1
Data Offset	4	Header length in 32-bit words: 5 words = 20 bytes min., 15 words = 60 bytes max.
Reserved	4	Must be zero (future use)
Flags	8	CWR, ECE (ECN), URG (urgent pointer valid), ACK (ack # valid), PSH (push to app now), RST (reset), SYN (open connection), FIN (close connection)
Window	16	Flow control — number of bytes the receiver can still accept (rwnd); sender may transmit min(cwnd, rwnd)
Checksum	16	One's-complement sum of a pseudo-header (src IP, dst IP, zero, protocol = 6, TCP length) + TCP header + data — detects corruption on any link
Urgent Pointer	16	Offset from the sequence number to the end of urgent data (valid if URG = 1)
Options	0–40	MSS, Window Scale, SACK permitted / selective ACK blocks, timestamps, NOP, End-of-Option

Fixed part = 20 bytes; with options up to 60 bytes. Ports give process-to-process delivery, sequence/ack numbers give byte-stream reliability, the window gives flow control, and the checksum (with pseudo-header) guarantees end-to-end integrity across IP.

---

Part B — UDP checksum verification

Given

• Sum of all 16-bit words excluding the checksum = 00110010 00001101 = 0x320D
• Received checksum field = 01011101 11110010 = 0x5DF2

Test: the receiver adds all 16-bit words including the checksum field (folding any end-around carry). The segment is correct only if the result is 11111111 11111111 = 0xFFFF.

Computation

      00110010 00001101   (sum of all other fields)   0x320D
    + 01011101 11110010   (checksum field)            0x5DF2
    ------------------------------------------
      10001111 11111111                              0x8FFF

There is no carry out of bit 15, so no end-around carry is added, and

$$0x320D + 0x5DF2 = 0x8FFF eq 0xFFFF$$

Cross-check: the expected checksum is the one's complement of the sum of the other fields:
~00110010 00001101 = 11001101 11110010 = 0xCDF2, which is not the received value 0x5DF2.

Conclusion: the sum is not 0xFFFF ⇒ the segment is NOT correctly received (at least one bit has been corrupted).

What the receiver does

1. Silently discards the UDP segment. UDP is connectionless and unreliable: it sends no NAK, no error ICMP and no request for retransmission — recovery, if any, is left to the application.
2. The missing data must be re-sent by the application after its own timeout (or the transfer simply fails).
3. Had this been a TCP segment, the receiver would likewise discard it but would send no ACK; TCP's retransmission timer would then retransmit the segment, so the error would be repaired end-to-end.
4. (Note: in IPv4 the UDP checksum is optional and may be sent as 0 = "not computed"; in IPv6 it is mandatory. If the calculated checksum is 0 it is transmitted as all 1s.)

Transport-Layer Congestion Control, and Leaky Bucket vs Token Bucket

1. How the transport layer provides congestion control

Congestion means the network's routers/links are carrying more traffic than their buffers and bandwidth can absorb, causing queueing delay, packet loss and throughput collapse. IP itself has no congestion control, so the end hosts — specifically TCP at the transport layer — control the rate at which they inject data, treating losses and delay as feedback signals.

1. Window-based rate control. The sender may have at most $\min(\text{cwnd}, \text{rwnd})$ unacknowledged bytes in flight; increasing cwnd increases the injection rate.
2. Slow start. cwnd starts at 1 MSS and doubles once per RTT (exponential growth) until it reaches the slow-start threshold $ssthresh$ or a loss occurs.
3. Congestion avoidance. Beyond $ssthresh$, cwnd grows additively (+1 MSS per RTT) — probing cautiously for spare capacity (AIMD).
4. Loss as congestion signal (multiplicative decrease).
   • 3 duplicate ACKs → fast retransmit + fast recovery: $ssthresh = \text{cwnd}/2$, $\text{cwnd} = ssthresh + 3$, then additive increase.
   • Timeout (severe congestion): $ssthresh = \text{cwnd}/2$, $\text{cwnd} = 1$ MSS, back to slow start.
5. Explicit signals: ECN marks IP headers (CE bit) and the receiver echoes ECE so the sender reduces cwnd without loss; a receiver can also reduce its advertised rwnd, throttling the sender (receiver flow control).
6. Retransmission timers with RTT estimation keep the in-flight data bounded so buffers upstream are not overrun.

 cwnd  |        additive increase (+1/RTT)
 (MSS) |      ______________/
       |     /      × loss → half (multiplicative decrease)
 ssth. |/____/ 
       | slow start (exponential)
       +---------------------------→ time/RTT

2. Leaky bucket vs Token bucket

Both are traffic-shaping (policing) algorithms that convert bursty input into a smoother, rate-limited output.

Basis	Leaky bucket	Token bucket
Working idea	Packets enter a bucket (queue) and drain at a constant fixed rate; if full, arriving packets are dropped/rejected	Tokens are generated at a fixed rate; a packet may be sent only if it grabs enough tokens, otherwise it waits
Empty bucket	Bucket empty ⇒ nothing to output	Bucket empty ⇒ new packets may still be sent if burst capacity is available — the bucket accumulates surplus
Burst tolerance	No bursts — output is strictly uniform (any burst is delayed/dropped)	Allows bursts up to the bucket's token capacity
Output rate	Always exactly the leak rate	Average = token rate, but instantaneous bursts are permitted
Implementation	Simple FIFO queue with a timer	Counter of tokens + queue
Typical use	Constant bit-rate shaping, hard policing	Limiting average rate while permitting bursts (e.g. network access rate policing)
Analogy	Water leaks out of a punctured bucket at a fixed rate	Coins are minted at a fixed rate; spending them authorises sending
Burst after idle	Cannot send a burst immediately	Idle time accumulates tokens → burst up to bucket size can be sent instantly

Essence: the leaky bucket enforces a rigid, smooth output rate and treats any excess as error, while the token bucket enforces a long-term average rate but deliberately allows bursts up to the accumulated token count — which is why it is preferred for real, bursty application traffic.

Conclusion: congestion control is achieved end-to-end by TCP's AIMD window algorithms (slow start, congestion avoidance, fast recovery, ECN), and routers additionally police/shape traffic at entry points using leaky or token bucket algorithms.

TCP Sliding Window — Before and After the ACK

Given: previous ACK number (left edge of window) = 22,001, window size = 10,000 bytes. A segment arrives with ACK = 24,001 and window advertisement = 12,000.

Before

• Left edge (SND.UNA) = 22,001 → bytes < 22,001 are already acknowledged.
• Right edge = 22,001 + 10,000 − 1 = 32,000 → sender may transmit bytes 22,001 … 32,000.

 byte:  ... 21999 | 22001 22002 ............ 32000 | 32001 32002 ...
                  |<-------- window = 10,000 bytes --------->|  cannot
        ACKed      ^ SND.UNA                         right edge   send
                   (next byte expected by receiver = 32,001)

After (ACK = 24,001, new window = 12,000)

• Bytes 22,001 – 24,000 (2,000 bytes) are now acknowledged → they leave the window.
• New left edge = 24,001.
• New right edge = 24,001 + 12,000 − 1 = 36,000.
• The window has effectively slid forward by 2,000 bytes and grown by 2,000 bytes, opening 4,000 bytes of new sendable space at the right edge.

 byte:  ... 24000 | 24001 24002 ............ 36000 | 36001 36002 ...
                  |<-------- window = 12,000 bytes --------->|  cannot
        ACKed      ^ SND.UNA (new)                right edge     send
                   (next byte expected = 36,001)

Summary

Item	Before	After
ACK / left edge	22,001	24,001
Window size	10,000	12,000
Last byte in window	32,000	36,000
Bytes newly acknowledged	—	22,001 – 24,000 (2,000 B)
Newly sendable bytes	—	32,001 – 36,000 (4,000 B)

The sender may now transmit bytes 24,001 through 36,000 (12,000 bytes total, including any already sent but unacknowledged), and it must keep SND.NXT ≤ 36,001.

TCP connection

TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte-stream transport protocol. A logical connection is set up between two processes before data transfer and closed afterwards.

Features of a TCP connection:

• Identified by a socket pair: (source IP, source port, destination IP, destination port).
• Full duplex: data flows in both directions at once.
• Point-to-point: exactly two endpoints (no multicast).
• Reliable: sequence numbers, acknowledgements, retransmission, checksum.
• Byte stream: every byte is numbered; the application data has no message boundaries.
• Provides flow control (sliding window) and congestion control.

Three phases: connection establishment → data transfer → connection release.

Connection establishment: three-way handshake

   Client                                  Server
     |                                        |   (server does passive open: LISTEN)
     |-- 1. SYN, seq = x ------------------->|   active open
     |                                        |
     |<-- 2. SYN + ACK, seq = y, ack = x+1 ---|
     |                                        |
     |-- 3. ACK, seq = x+1, ack = y+1 ------->|
     |         connection ESTABLISHED         |

1. SYN: the client sends a segment with the SYN flag set and an initial sequence number x (random). It enters SYN-SENT.
2. SYN + ACK: the server replies with SYN and ACK set, its own initial sequence number y, and ack = x + 1. It enters SYN-RECEIVED.
3. ACK: the client acknowledges with ack = y + 1. Both sides are now ESTABLISHED and data can flow.

The SYN segment consumes one sequence number. The handshake synchronises sequence numbers and agrees on parameters (window size, MSS).

Why three steps? Two steps could not confirm that the client received the server's initial sequence number, and old duplicate SYNs could create false connections. SYN flooding (many half-open connections) is a known attack, mitigated with SYN cookies.

Connection release

Each direction is closed separately. The common four-segment exchange is FIN, ACK, FIN, ACK. When the server has no more data, it can combine its ACK and FIN into one segment, which gives the three-way release asked for here.

   Client                                  Server
     |-- 1. FIN, seq = u ------------------->|   client done sending
     |<-- 2. FIN + ACK, seq = v, ack = u+1 ---|   server acknowledges and also closes
     |-- 3. ACK, ack = v+1 ------------------>|
     |   client waits 2×MSL (TIME_WAIT), then closed

1. FIN: the side that finishes (client) sends a segment with the FIN flag.
2. FIN + ACK: the server acknowledges it (ack = u + 1) and, having no more data, sets FIN in the same segment.
3. ACK: the client acknowledges the server's FIN. The server closes when it receives this ACK.

The client stays in TIME_WAIT for 2 × MSL (maximum segment lifetime) so that a lost final ACK can be resent and old segments expire.

Four-way variant: if the server still has data to send after receiving the FIN, it sends a plain ACK first (half-close), later sends its own FIN, and the client sends the last ACK. An abrupt close can also be done with an RST segment.

Congestion

Congestion occurs when the load offered to a network (or part of it) exceeds its capacity, so routers' buffers fill up, delay increases and packets are dropped. Lost packets are retransmitted, adding even more load, and throughput can collapse (congestion collapse).

Throughput
   |        ____________
   |      /             \___   <- beyond capacity: packets dropped,
   |     /                    \    throughput falls
   |    /
   +---------------------------- Offered load
        (no congestion)  (congestion)

Causes: limited router buffers and link bandwidth, slow processors, many senders sending bursts, retransmissions of lost packets.

Difference from flow control: flow control is between one sender and one receiver; congestion control is a global issue involving all hosts and routers.

TCP controls congestion by using a congestion window (cwnd) in addition to the receiver's window: the sender may have at most min(rwnd, cwnd) bytes unacknowledged. The window is managed with three policies (phases).

Three congestion control policies in TCP

1. Slow start (exponential increase)

• Starts with cwnd = 1 MSS.
• For every ACK received, cwnd increases by 1 MSS, so cwnd doubles every RTT (1, 2, 4, 8, ...).
• Continues until cwnd reaches the slow-start threshold (ssthresh), then switches to congestion avoidance.

2. Congestion avoidance (additive increase)

• When cwnd ≥ ssthresh, cwnd grows linearly: +1 MSS per RTT (each ACK adds MSS²/cwnd).
• This probes for extra bandwidth carefully, avoiding congestion.

3. Congestion detection (multiplicative decrease)

Congestion is detected by packet loss:

Event	Meaning	Reaction (TCP Tahoe / Reno)
Timeout	Strong congestion	ssthresh = cwnd / 2; cwnd = 1 MSS; restart slow start
3 duplicate ACKs	Mild congestion (some segments still get through)	Fast retransmit of the lost segment; Reno: ssthresh = cwnd / 2; cwnd = ssthresh (fast recovery) and continue with congestion avoidance

Together these implement AIMD (Additive Increase, Multiplicative Decrease).

Diagram: cwnd versus time

Initial ssthresh = 8 MSS. A timeout occurs when cwnd = 12 (after RTT 8), so ssthresh becomes 6 and cwnd drops to 1.

cwnd (MSS)
 12 |                      *
 11 |                   *
 10 |                *
  9 |             *
  8 |          *                             *   <- ssthresh = 8, later 6
  7 |                                     *
  6 |                                  *
  5 |
  4 |       *                       *
  3 |
  2 |    *                       *
  1 | *                       *
    +------------------------------------------
      1  2  3  4  5  6  7  8  9 10 11 12 13 14   RTT

RTT	1	2	3	4	5	6	7	8	9	10	11	12	13	14
cwnd	1	2	4	8	9	10	11	12	1	2	4	6	7	8
Phase	slow start (exponential)			reaches ssthresh	congestion avoidance (linear)				timeout	slow start		reaches new ssthresh = 6	congestion avoidance

Summary

Phase	Increase	Trigger
Slow start	Exponential (×2 per RTT)	Start, or after a timeout; until ssthresh
Congestion avoidance	Linear (+1 MSS per RTT)	cwnd ≥ ssthresh
Congestion detection	Multiplicative decrease	Timeout or 3 duplicate ACKs

(Other techniques in the network layer include traffic shaping with leaky and token buckets, load shedding, and RED.)

TCP Header for an FTP Client → Server Message

Ports chosen

• Well-known port (destination) = 21 — FTP control connection is always terminated at port 21 on the server.
• Ephemeral port (source) = 52345 — any unused port in the dynamic/private range 49152–65535 chosen by the client (e.g. 15151 or 52345 are both acceptable).

Lengths

• TCP header with no options = 5 words × 4 = 20 bytes → Data Offset = 5.
• Data = 40 bytes → total segment length = 20 + 40 = 60 bytes; total TCP length field in IP = 60.
• Checksum field is filled with 0000 as instructed (in real transmission it would be computed over the pseudo-header + TCP header + data).

Header entries

#	Field	Value	Notes
1	Source Port	52345	ephemeral port (client)
2	Destination Port	21	FTP well-known port (server)
3	Sequence Number	1000	(example) sequence number of first data byte
4	Acknowledgment Number	5000	(example) next byte expected from server
5	Data Offset	5	20-byte header, no options
6	Reserved	0	3 bits (4 bits + 4-bit NS in some texts)
7	Control Bits	URG=0, ACK=1, PSH=1, RST=0, SYN=0, FIN=0	acknowledging earlier data + pushing this data
8	Window	8192	advertised receive window (example)
9	Checksum	0x0000	all zeros, as specified
10	Urgent Pointer	0	URG bit is 0, field not used
11	Options	none	Data Offset stays 5 (20 bytes)
12	Data (payload)	40 bytes	e.g. an FTP command or file block

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Source Port = 52345       |    Dest Port = 21            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Sequence Number = 1000                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Acknowledgment Number = 5000                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |r|A|P|R|S|F|            Window = 8192                   |
| Offset| |C|S|S|Y|I|                                    0 0 0 0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Checksum = 0x0000       |     Urgent Pointer = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Data (40 bytes) ...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Result: Source 52345 → Destination 21, 20-byte header + 40 bytes of data = 60-byte TCP segment, checksum 0000.

Part 1 — Difference between TCP and UDP

Parameter	TCP	UDP
Nature	Connection-oriented (3-way handshake)	Connectionless
Reliability	Reliable — ACK, retransmission, sequencing	Unreliable best-effort
Ordering	Yes, via sequence numbers	No
Flow control	Sliding window (rwnd)	None
Congestion control	Slow start, congestion avoidance, fast recovery	None
Header	20–60 bytes	Fixed 8 bytes
Data unit	Byte-stream segment (no message boundaries)	Datagram (preserves message boundaries)
Multiplexing	Port numbers	Port numbers
Overhead / speed	Higher overhead, slower	Lightweight, faster
Use cases	HTTP, FTP, e-mail, file transfer	DNS, DHCP, VoIP, streaming, gaming

Part 2 — Socket addresses for the given communication

Given:

• Client IP $= 122.45.12.7$, ephemeral port $= 51000$
• Server IP $= 200.112.45.90$, well-known port $= 161$

Concept: a socket address = (IP address, port number) pair. The port selects the process on a host, while the IP selects the host itself. A TCP/UDP connection (or datagram exchange) is identified by the pair of socket addresses — source and destination.

Step 1 — Server (destination) socket:

$$\text{Server socket} = (200.112.45.90,\ 161)$$

Step 2 — Client (source) socket: the client uses its own IP with an ephemeral (temporarily assigned) port chosen above 49151.

$$\text{Client socket} = (122.45.12.7,\ 51000)$$

Step 3 — The pair of socket addresses:

$$\boxed{(\text{Client: } 122.45.12.7:51000) \quad \longleftrightarrow \quad (\text{Server: } 200.112.45.90:161)}$$

• Destination socket = (200.112.45.90, 161) — the well-known port 161 (SNMP's standard port) identifies the server process.
• Source socket = (122.45.12.7, 51000) — the ephemeral port 51000 identifies the client process and lets the server's reply be demultiplexed back to it.
• Traffic from client to server is addressed to 200.112.45.90:161 with source 122.45.12.7:51000; the response simply reverses these two addresses.

Final answer: socket addresses = (122.45.12.7, 51000) and (200.112.45.90, 161), i.e. 122.45.12.7:51000 ↔ 200.112.45.90:161.

TCP Header vs UDP Header

TCP and UDP are both transport-layer protocols running over IP, but TCP's header is built for a reliable, connection-oriented byte stream while UDP's is a minimal 8-byte shim.

Aspect	TCP header	UDP header
Minimum size	20 bytes (up to 60 bytes with options)	8 bytes, always fixed
Fields	Source port, Dest port, Sequence no, Acknowledgment no, Data offset, Reserved, Flags (URG, ACK, PSH, RST, SYN, FIN), Window, Checksum, Urgent pointer, Options/padding	Source port, Dest port, Length, Checksum
Reliability	Seq/ack numbers, checksum, retransmission, duplicate detection	Checksum only (optional in IPv4), no retransmission
Flow control	Receiver's advertised window	None
Connection	SYN/FIN handshake and teardown	Connectionless
Multiplexing	Ports + connection state	Ports only
Overhead / use	Higher latency; file transfer, web, email	Lower latency; DNS, DHCP, RTP streaming, VoIP

TCP fields missing from the UDP header, and the reason for their absence

1. Sequence number - TCP numbers every byte of the stream so the receiver can reorder segments and detect gaps; UDP datagrams are independent and unordered, so there is nothing to sequence.
2. Acknowledgment number - needed for cumulative ACKs and reliable delivery; UDP has no ACK mechanism (an application such as DNS must build its own retry logic).
3. Data offset (header length) - TCP can grow to 60 bytes with options, so it must state how long it is; UDP's header is always exactly 8 bytes, so it carries an explicit Length field instead.
4. Window size - implements receiver-side flow control; UDP does no flow control and leaves pacing entirely to the application.
5. Control flags (SYN, ACK, FIN, RST, PSH, URG) - used for connection setup, orderly release, reset, push and urgent data; a connectionless protocol needs none of them.
6. Urgent pointer - points to urgent out-of-band data, which is meaningful only within an ordered byte stream.
7. Options (MSS, window scaling, SACK, timestamps) - parameters negotiated during connection setup; there is no connection to negotiate.

Key idea: every field that UDP lacks exists to provide connection, ordering, reliability or flow control - exactly the services UDP deliberately omits in exchange for low overhead and low delay.

TCP Sequence Number Wrap-Around Time

Given:

• Data rate = 2 Mbytes/sec
• Initial sequence number = 7000
• TCP sequence numbers are 32 bits, so the sequence number space is $2^{32} = 4{,}294{,}967{,}296$ bytes.

Step 1 — Bytes that must be sent before the number returns to 0

The sequence number wraps to 0 only after the entire 32-bit space is exhausted. Starting at 7000, the bytes still to be sent are:

$$N = 2^{32} - 7000 = 4{,}294{,}967{,}296 - 7000 = \mathbf{4{,}294{,}960{,}296 \text{ bytes}}$$

Step 2 — Convert the data rate to bytes/sec

Taking 1 Mbyte = $2^{20}$ bytes = 1,048,576 bytes:

$$R = 2 \times 1{,}048{,}576 = 2{,}097{,}152 \text{ bytes/sec}$$

Step 3 — Time = Data / Rate

$$T = \frac{4{,}294{,}960{,}296}{2{,}097{,}152} \approx 2047.997 \text{ s}$$

$$\boxed{T \approx 2048 \text{ s} \approx 34 \text{ min } 8 \text{ s}}$$

(Sanity check: $2^{32} / 2^{21} = 2^{11} = 2048$ s exactly; the initial 7000 bytes shave off only ~0.003 s, so the answer is essentially 2048 s.)

Alternative convention: if "Mbyte" is read as $10^6$ bytes, then $R = 2{,}000{,}000$ B/s and

$$T = \frac{4{,}294{,}960{,}296}{2{,}000{,}000} \approx 2147.5 \text{ s} \approx 35.8 \text{ min}$$

Final answer: ≈ 2048 seconds (about 34 minutes) for 1 Mbyte = $2^{20}$ bytes (≈ 2147.5 s if 1 Mbyte = $10^6$ bytes).

Note: this long wrap time is exactly why TCP may safely use a reduced window (e.g., window scaling / TCP timestamps) to disambiguate old from new segments — with wrap taking ~34 minutes, no segment can survive that long.

User Datagram Protocol (UDP)

UDP (User Datagram Protocol) is a connectionless, unreliable transport-layer protocol of the TCP/IP suite that provides a minimal, low-overhead process-to-process communication service using datagrams.

UDP Header (only 8 bytes)

 0 16 31
+--------+--------+----------------+
| Source | Destination | |
| Port | Port | |
+--------+--------+----------------+
| Length | Checksum | |
+--------+--------+----------------+

• Source/Destination Port (2 bytes each): process (socket) addressing / multiplexing.
• Length (2 bytes): header + data (minimum 8).
• Checksum (2 bytes): optional in IPv4 (mandatory in IPv6); covers UDP header, data and a pseudo-header (source & dest IP, protocol, UDP length).

Key characteristics

Feature	Behaviour
Connection	No connection setup — no handshake, no session state
Reliability	None — no ACK, no retransmission, no ordering, duplicates possible
Flow control	None; congestion control left to the application/upper layers
Error control	Only an optional checksum; lost/corrupt datagrams are silently discarded
Segmentation	Each message = one datagram (no byte stream, no fragmentation at transport layer)
Overhead	8 bytes (vs 20 for TCP) → fast, efficient
Delivery	Best-effort; one-to-one (datagram socket) or one-to-many (broadcast/multicast)

Why UDP is still used

• Real-time apps (VoIP, video streaming, online gaming) where timeliness matters more than perfect delivery — a late packet is useless anyway, and retransmitted data would add jitter.
• Request–reply protocols with small exchanges (DNS, DHCP, SNMP, TFTP, RIP) where a 3-way handshake would cost more than the query itself.
• Multicast/broadcast applications — TCP is strictly point-to-point.
• Encapsulation of other protocols (tunnelling, e.g., IPsec NAT traversal, VXLAN).
• Applications that need reliability add it themselves in the application layer, keeping the core protocol simple.

Summary: UDP is a thin layer over IP offering port-based multiplexing and an optional checksum with minimal delay and overhead — reliability, ordering and flow control are deliberately left to the application, trading correctness for speed.

Open-Loop vs Closed-Loop Congestion Control

Congestion-control policies are classified by when they act. Open-loop policies are decided before traffic is sent and never use feedback from the network; closed-loop policies rely on feedback to detect congestion that has already occurred and then correct it.

Basis	Open-loop congestion control	Closed-loop congestion control
Principle	Prevent congestion by design; no feedback is used	Detect congestion, feed information back to the sender/routers, then react
When applied	Before/during policy setup, ahead of transmission	Continuously during transmission, once per RTT
Feedback	None - the policy is blind to current load	Implicit (ACK rate, RTT, packet loss) or explicit (router marking, ICMP)
Goal	Avoid deadlock, starvation and queue overflow a priori	Keep the network in the comfortable operating region after congestion appears
Typical mechanisms	Retransmission policy, acknowledgment policy, error-control policy, admission/flow control at connection setup, packet-discard policy (drop-old vs drop-new), FQ/WFQ scheduling, differentiated service classes, traffic shaping (leaky bucket/token bucket)	Slow start, congestion avoidance (AIMD), fast retransmit and fast recovery (TCP), RED/WRED active queue management, ECN marking, adaptive routing
Response time	Slow - cannot adapt while traffic runs	Fast - adapts every RTT
Complexity	Simple, predictable	More complex; needs signalling between routers, receiver and sender
Where implemented	Mainly in routers and in the sender before sending	In the sender, driven by receiver/router feedback
Example	Shaping traffic at the edge so the core never overloads	TCP hearing three duplicate ACKs and cutting cwnd by half

Key differences in brief

1. Feedback: open-loop is fire-and-forget; closed-loop is a classic control loop (measure -> decide -> act).
2. Timing: open-loop acts at policy/setup time; closed-loop acts during the session and re-evaluates each RTT.
3. Objective: open-loop prevents bad states (guarantees are made so queues cannot overflow); closed-loop repairs them once loss or delay rises.
4. Adaptability: closed-loop can exploit changing conditions (grow the window while ACKs arrive quickly), whereas open-loop must stay conservative to remain safe.
5. Cost of failure: open-loop failures are hard to detect (no feedback), while closed-loop can oscillate around the optimum as it reacts to delayed feedback.

Rule of thumb: if a mechanism must hear from the network before it changes behaviour, it is closed-loop; if its behaviour is fixed in advance, it is open-loop.

TCP Connection Establishment — Three-Way Handshake

TCP is connection-oriented, so a logical connection must be established before data transfer. Connection establishment uses a three-way handshake in which both sides exchange SYN and ACK segments and agree on initial sequence numbers (ISNs).

Message exchange

        Client                                  Server
     (first)                                   (second)
        |                                         |
        | ---- (1) SYN, seq = x ---------------> |   SYN bit = 1
        |                                         |   ISN = x chosen by client
        | <--- (2) SYN+ACK, seq = y, ack = x+1 -- |   SYN bit = 1, ACK bit = 1
        |                                         |   ISN = y chosen by server
        | ---- (3) ACK, seq = x+1, ack = y+1 --> |   ACK bit = 1
        |                                         |
        |        ===== CONNECTION ESTABLISHED === |   both in ESTABLISHED state

Description of each step

1. Step 1 — Connection request (SYN): The client picks an initial sequence number x and sends a segment with SYN = 1 and no data (SYN segments consume one sequence number). The client enters SYN-SENT state.
2. Step 2 — Connection accepted (SYN + ACK): The server acknowledges by sending SYN = 1, ACK = 1, its own ISN y, and ack = x + 1 (acknowledging the client's SYN). The server enters SYN-RECEIVED state.
3. Step 3 — Acknowledgement (ACK): The client sends ACK = 1, seq = x + 1, ack = y + 1, acknowledging the server's SYN. Both sides now enter ESTABLISHED and normal data transfer begins.

Why three segments?

• It lets both sides agree on and acknowledge each other's initial sequence numbers (needed for reliability and flow control).
• It guarantees that both ends are ready to receive — a two-way handshake cannot resolve the problem of old duplicate connection requests still roaming the network (the classic two-way handshake failure case); with three-way handshake, the server replies with a SYN-ACK containing a new ISN, and stale duplicates cannot be accepted.
• It also synchronises timing parameters (maximum segment size, window scale, timestamps) exchanged in the SYN options.

Note on simultaneous open

TCP also supports simultaneous connection establishment: if both sides send SYN at the same time, both move to SYN-SENT and then answer each other's SYN with SYN+ACK — still converging in three segments to ESTABLISHED.

Result: After exactly three segments (SYN → SYN+ACK → ACK) the connection is established, and only then is application data exchanged.