Transport Layers 1

TCP stands for Transmission Control Protocol.

It provides:

• reliable delivery;
• in-order delivery;
• connection setup;
• flow control;
• congestion control;
• full-duplex communication;
• a byte-stream abstraction.

TCP hides many network-level problems from the application.

For example, IP may deliver packets out of order, lose packets, or deliver packets along different paths. TCP tries to make the application see a clean, ordered byte stream.

UDP stands for User Datagram Protocol.

It provides:

• connectionless communication;
• unordered delivery;
• unreliable delivery;
• no retransmission mechanism;
• no flow control;
• no congestion control;
• a small header;
• low overhead.

UDP is close to “best effort IP plus ports”.

If data is lost, UDP itself does not repair it. If data arrives out of order, UDP does not reorder it. If the receiver is overwhelmed, UDP does not slow down the sender.

Neither TCP nor UDP gives strict guarantees about:

• delay;
• bandwidth.

TCP can adapt to congestion and retransmit lost data, but it still does not promise that a segment will arrive within a fixed time. UDP is even simpler and also gives no such guarantees.

Congestion control protects the network.

If too many senders transmit too much data at the same time, routers may need to buffer packets. Buffers are finite. Once they fill up, packets are dropped. If many connections keep sending aggressively, the network can become congested and performance can collapse.

TCP congestion control tries to make senders reduce their sending rate when the network appears overloaded.

The important idea is:

Congestion control limits how much data the network can handle.

This is a network-side limitation.

Flow control protects the receiver.

The receiver has finite buffer space. If the sender sends faster than the receiver can process or read data, the receiver’s buffer may overflow.

The important idea is:

Flow control limits how much data the receiver is willing or able to accept.

This is a receiver-side limitation.

The sender should respect both limits:

\[ \text{allowed in-flight data} = \min(\text{congestion window}, \text{receiver window}) \]

The congestion window is related to the network. The receiver window is related to the receiver’s buffer.

On one host, many applications may use the network at the same time.

For example:

• a browser;
• an email client;
• a DNS resolver;
• a video call;
• an SSH session.

All of them use the same network stack. The transport layer therefore needs a way to combine data from multiple applications and later separate incoming data back to the right application.

Multiplexing happens at the source host.

It means:

Gather data from multiple application sockets, add transport headers, and send the resulting segments through the network.

So the source host takes multiple application data streams and sends them through the transport layer.

Demultiplexing happens at the destination host.

It means:

Use header fields to deliver each received segment to the correct socket or application process.

The destination host receives segments from the network and decides which application should get each segment.

The term multiplexing is not unique to the transport layer.

In general, multiplexing means combining multiple logical streams into one lower-level channel. Demultiplexing means separating them again.

For example, HTTP/2 can multiplex multiple application-level streams over one TCP connection.

UDP is a minimal transport-layer protocol.

It is:

• connectionless;
• unreliable;
• unordered;
• best-effort;
• simple;
• fast;
• low-overhead.

UDP was originally specified in RFC 768.

There is no handshake before sending UDP data. Each UDP datagram is handled independently.

UDP is useful because it avoids TCP’s connection setup and reliability machinery.

Advantages:

• no connection establishment delay;
• no connection state;
• small header;
• simple implementation;
• sender can transmit at its chosen rate;
• useful for simple request-response protocols;
• useful for loss-tolerant, delay-sensitive applications.

Examples:

• DNS;
• streaming multimedia;
• voice-over-IP;
• SNMP;
• HTTP/3 over QUIC.

For DNS, UDP makes sense because a typical DNS lookup is one query and one response. A full TCP handshake before every small query would add unnecessary round-trip delay.

UDP itself has no congestion control.

This can be useful for some applications, but it is also dangerous. A UDP application can send too aggressively and contribute to congestion.

If reliability or congestion control is needed on top of UDP, the application or a higher-level protocol must implement it.

This is relevant for QUIC:

• QUIC runs on top of UDP;
• QUIC implements reliability, congestion control, and flow control itself;
• therefore QUIC uses UDP as a substrate, but adds many TCP-like features above it.

UDP has a receive buffer at the receiver side.

However, UDP does not keep a sender-side retransmission buffer. Once UDP passes a datagram down to IP, UDP forgets about it.

TCP is different: TCP keeps sent data in a send buffer so that it can retransmit if necessary.

The UDP header is small:

So the UDP header is 8 bytes.

The length field includes:

• UDP header;
• UDP payload.

The checksum is used for error detection, not security.

The checksum helps detect accidental corruption, such as bit flips.

It does not provide cryptographic integrity. An attacker who can modify both the data and the checksum can still forge a valid checksum.

The checksum is computed using one’s-complement arithmetic over 16-bit words. A pseudo-header is also involved, including information such as IP addresses, protocol identifier, and length.

If the packet length is odd, padding may be added for checksum computation.

A checksum value of zero can indicate that no checksum is used, but the lecture emphasized that the checksum should normally be enabled.

UDP is best understood as:

Send and hope for the best.

UDP segments may be:

• lost;
• duplicated;
• delivered out of order;
• delivered correctly.

UDP does not fix these problems. If the application needs more guarantees, it must build them itself.

Suppose the sender sends block \(X+1\).

If the ACK is delayed, the sender may timeout and retransmit \(X+1\).

Now the receiver may receive two copies of \(X+1\). If it acknowledges each copy, then each ACK may trigger the sender to send \(X+2\).

Then the receiver may get two copies of \(X+2\), acknowledge both, and the sender may send two copies of \(X+3\), and so on.

The number of duplicate packets can grow.

This was called the Sorcerer’s Apprentice syndrome.

The lesson is that reliability is subtle.

It is not enough to simply say:

Every packet must be acknowledged.

The protocol must also handle:

• delayed packets;
• duplicate packets;
• duplicate ACKs;
• retransmissions;
• state management;
• loss recovery.

This motivates using a dedicated transport protocol like TCP instead of requiring every application to implement these mechanisms itself.

TCP provides a reliable, in-order byte stream.

This means:

• TCP views data as a stream of bytes;
• TCP does not preserve application message boundaries;
• bytes should be delivered to the receiving application in the same order in which they were sent.

For example, if an application writes:

write("hello")
write("world")

the receiver may simply read a byte stream:

helloworld

TCP itself does not necessarily remember that the application made two writes.

TCP is point-to-point:

• one sender;
• one receiver.

It is not one-to-many multicast.

TCP is full duplex.

One TCP connection supports data flow in both directions at the same time.

So a TCP connection between A and B contains:

• A-to-B byte stream;
• B-to-A byte stream.

Each direction has its own sequence number space.

TCP is connection-oriented.

Before normal data transfer, the endpoints perform a handshake to initialize connection state.

The state includes, for example:

• sequence numbers;
• acknowledgement numbers;
• buffer/window information;
• negotiated options;
• connection state.

The MSS is the maximum amount of TCP payload data that can be sent in one TCP segment.

It should be smaller than the MTU, because the IP and TCP headers also need space.

For Ethernet with MTU 1500 bytes, a common TCP payload size is:

\[ 1500 - 20 - 20 = 1460 \]

assuming:

• 20 bytes IPv4 header;
• 20 bytes TCP header without options.

The MSS is about TCP payload size, not total frame size.

TCP has a much more complex header than UDP.

Important fields:

Important flags:

TCP sequence numbers count bytes, not segments.

The sequence number of a TCP segment is the byte-stream number of the first data byte in that segment.

Example:

If a sender starts with sequence number 500 and sends 200 bytes, then the next sequence number is:

\[ 500 + 200 = 700 \]

So the next segment should start with sequence number 700.

If the sender later sends only 32 bytes, the next sequence number increases by

The sender’s sequence number space can be divided into regions:

The usable window is limited by both:

• flow control;
• congestion control.

The sender may have multiple unacknowledged segments in flight. This is pipelining.

The acknowledgement number means:

I have received all bytes before this number, and I expect this byte next.

Example:

If Host A sends 200 bytes starting at sequence number 500, then Host B sends:

\[ ACK = 700 \]

This means:

I received bytes 500 through 699. I now expect byte 700.

TCP ACKs are cumulative.

An ACK for byte \(N\) means:

All bytes before \(N\) have been received in order.

So if a receiver sends:

\[ ACK = 3000 \]

it means all bytes up to 2999 have been received in order.

If there is a gap, the receiver cannot cumulatively acknowledge beyond the gap.

Suppose TCP segments have payload length 500.

A sends:

If segment 2 is lost but segment 3 arrives, the receiver has:

• bytes 2500–2999;
• bytes 3500–3999;
• but not bytes 3000–3499.

The receiver cannot send \(ACK=4000\), because that would falsely claim that all bytes before 4000 were received.

Instead, the receiver repeats:

\[ ACK = 3000 \]

This duplicate ACK tells the sender:

I am still waiting for byte 3000.

A duplicate ACK is an ACK with the same acknowledgement number as before.

Duplicate ACKs usually mean:

• later data arrived;
• but some earlier data is missing;
• therefore the receiver keeps asking for the same next byte.

TCP does not immediately retransmit after one duplicate ACK because packets can be reordered in the network.

The common rule is:

After three duplicate ACKs, TCP assumes loss and performs fast retransmit.

More precisely, the sender receives the original ACK plus three additional ACKs for the same acknowledgement number.

Example 1:

A sends:

\[ Seq = 1500,\quad Length = 500 \]

B should ACK:

\[ ACK = 2000 \]

A then sends:

\[ Seq = 2000,\quad Length = 500 \]

B should ACK:

\[ ACK = 2500 \]

Example 2 with loss:

A sends:

\[ Seq = 2500,\quad Length = 500 \]

B ACKs:

\[ ACK = 3000 \]

A sends:

\[ Seq = 3000,\quad Length = 500 \]

but this is lost.

A sends:

\[ Seq = 3500,\quad Length = 500 \]

B receives this but sees a gap. It still sends:

\[ ACK = 3000 \]

because byte 3000 is still the next expected byte.

Each TCP segment contains both:

• a sequence number;
• an acknowledgement number.

Even a pure ACK segment, with no application payload, still has a sequence number field.

However, a pure ACK with no data normally does not consume sequence number space. SYN and FIN are special: they each consume one sequence number.

TCP sequence numbers do not simply start at zero.

Historically, predictable initial sequence numbers enabled attacks, because an attacker could guess where important data would appear in the byte stream.

Modern TCP uses random initial sequence numbers.

Each direction has its own initial sequence number.

For a connection between A and B:

• A chooses an initial sequence number for A-to-B data;
• B chooses an initial sequence number for B-to-A data.

The lecture uses a simple Telnet-like example where the user types one character, \(C\).

Host A sends \(C\) to Host B:

\[ Seq = 42,\quad ACK = 79,\quad data = C \]

Since \(C\) is one byte, Host B acknowledges the next expected byte:

\[ ACK = 43 \]

Host B also echoes \(C\) back using its own sequence number space:

\[ Seq = 79,\quad ACK = 43,\quad data = C \]

Then Host A acknowledges the echoed byte:

\[ Seq = 43,\quad ACK = 80 \]

Important lesson:

• the ACK number is the next expected byte from the other side;
• each direction has its own sequence number space;
• a one-byte payload increases the next sequence number by 1.

Suppose A’s initial sequence number is 10, B’s initial sequence number is 200, and A sends 10-byte segments.

A sends:

\[ Seq = 10,\quad Len = 10 \]

B should ACK:

\[ ACK = 20 \]

A sends another 10 bytes:

\[ Seq = 20,\quad Len = 10 \]

B can ACK cumulatively:

\[ ACK = 30 \]

This says:

I have received everything before byte 30.

A sends:

Suppose segment 2 is lost, but segments 3 and 4 arrive.

The receiver cannot ACK 50, because bytes 20–29 are missing.

It repeatedly sends:

\[ ACK = 20 \]

These are duplicate ACKs.

If the missing segment is later retransmitted and the receiver has buffered the out-of-order segments, then it can ACK:

\[ ACK = 50 \]

If the receiver did not buffer the out-of-order data, then it may only ACK after receiving more retransmitted data. The TCP specification does not fully mandate how out-of-order data must be buffered; that is implementation-specific.

TCP needs to decide when a segment is probably lost.

If an ACK does not arrive, the sender eventually retransmits.

The timeout must be chosen carefully.

If the timeout is too short:

• TCP retransmits unnecessarily;
• this wastes bandwidth;
• it may worsen congestion.

If the timeout is too long:

• TCP waits too long before repairing loss;
• performance suffers.

The round-trip time, RTT, is the time from sending a segment to receiving the corresponding acknowledgement.

\[ RTT = \text{time from segment transmission to ACK receipt} \]

RTT varies because of:

• queueing delay;
• route changes;
• changing network load;
• processing delay;
• propagation delay.

The most variable part is usually queueing delay.

TCP can measure a sample RTT:

\[ SampleRTT = \text{ACK receipt time} - \text{segment send time} \]

However, a single sample is noisy.

So TCP uses a smoothed estimate.

TCP estimates RTT using an exponentially weighted moving average:

\[ EstimatedRTT = (1-α) ⋅ EstimatedRTT

α ⋅ SampleRTT \]

Typical value:

\[ \alpha = 0.125 = \frac{1}{8} \]

This makes recent samples matter more than old samples.

The influence of an old sample decreases exponentially over time.

The lecture mentions that values such as \(1/8\) and \(1/4\) are convenient because they can be implemented efficiently using bit shifts.

This matters because TCP operations must be fast inside the operating system.

TCP also estimates how much RTT varies.

\[ DevRTT = (1-β) ⋅ DevRTT

β ⋅ |SampleRTT - EstimatedRTT| \]

Typical value:

\[ \beta = 0.25 = \frac{1}{4} \]

If RTT varies a lot, TCP needs a larger safety margin.

The timeout interval is:

\[ TimeoutInterval = EstimatedRTT + 4 \cdot DevRTT \]

The factor 4 is a safety margin.

So the timeout adapts to both:

• the average RTT;
• the variability of RTT.

Suppose TCP sends a segment and then retransmits it because of timeout.

Later an ACK arrives.

Question:

Does the ACK correspond to the original segment or the retransmitted segment?

The sender often cannot tell.

Therefore, the RTT sample would be ambiguous.

Karn’s rule:

• do not take RTT samples for retransmitted segments;
• keep the backed-off timeout;
• reuse RTT estimation only after a successful non-retransmitted segment.

This avoids corrupting the RTT estimator with ambiguous samples.

The lecture also mentions that modern TCP can use timestamp options.

With timestamps, the sender includes a timestamp in a segment, and the receiver echoes it back. This can help obtain more accurate RTT samples and reduce ambiguity.

When data arrives from the application:

1. create a TCP segment;
2. set the sequence number to \(NextSeqNum\);
3. pass the segment to IP;
4. update:

\[ NextSeqNum = NextSeqNum + length(data) \]

1. start the timer if it is not already running.

The timer is conceptually associated with the oldest unacknowledged segment.

Suppose an ACK with value \(y\) arrives.

If:

\[ y > SendBase \]

then this ACK acknowledges new data.

Update:

\[ SendBase = y \]

If there are still unacknowledged segments, restart the timer. Otherwise, stop the timer.

If the ACK does not acknowledge new data, it may be a duplicate ACK.

On timeout:

1. retransmit the segment with the smallest unacknowledged sequence number;
2. restart the timer.

A sends:

\[ Seq = 92,\quad Len = 8 \]

B receives it and sends:

\[ ACK = 100 \]

If the ACK is lost, A eventually times out and retransmits the same data.

B receives duplicate data, but can send \(ACK=100\) again.

The data is not delivered twice to the application as new data, because TCP can recognize the duplicate sequence numbers.

A segment may not be lost, but the sender’s timeout may fire too early.

Then the sender retransmits unnecessarily.

The receiver may get duplicate data and ACK accordingly.

This is why choosing timeout too short is bad.

Suppose ACK for an earlier segment is lost, but a later cumulative ACK arrives.

The later ACK may still acknowledge all earlier data.

For example:

• A sends bytes 92–99;
• B sends \(ACK=100\), but it is lost;
• A sends bytes 100–119;
• B sends \(ACK=120\).

The ACK 120 implies that bytes up to 119 were received, so ACK 100 is no longer needed.

This is the advantage of cumulative ACKs.

If an in-order segment arrives with the expected sequence number, and all previous data is already ACKed:

• use delayed ACK;
• wait briefly for another segment;
• if no next segment arrives, send an ACK.

The slides mention waiting up to 500 ms; the lecture notes that modern systems often use smaller values such as around 200 ms.

If another in-order segment arrives while an ACK is pending:

• immediately send one cumulative ACK;
• this ACK covers both in-order segments.

This reduces ACK overhead.

If a segment arrives with a higher-than-expected sequence number, there is a gap.

The receiver immediately sends a duplicate ACK indicating the next expected byte.

Example:

Expected:

\[ Seq = 200 \]

Received:

\[ Seq = 300 \]

The receiver sends:

\[ ACK = 200 \]

If a segment arrives and partially or completely fills a gap, the receiver immediately sends an ACK, provided the segment starts at the lower end of the gap.

This helps the sender quickly learn that recovery succeeded.

If the sender receives three duplicate ACKs for the same acknowledgement number, it assumes that the missing segment was lost.

Then it retransmits the oldest unacknowledged segment without waiting for the timeout.

This is called fast retransmit.

Important exam detail:

It is not enough to receive one duplicate ACK. TCP fast retransmit uses three duplicate ACKs.

That means four ACKs with the same ACK number in total:

1. the original ACK;
2. first duplicate ACK;
3. second duplicate ACK;
4. third duplicate ACK.

After the third duplicate ACK, the sender retransmits.

Because packets can be reordered.

A single out-of-order packet may just mean that the network delivered packets in a different order, not that a segment was lost.

Three duplicate ACKs are stronger evidence.

At the receiver, incoming TCP data is placed into a receive buffer.

The application process reads data from this buffer.

If the application reads slowly, the buffer can fill up.

If the sender keeps sending data after the buffer is full, the receiver would need to drop data.

TCP avoids this through flow control.

The receiver advertises available buffer space using the receive window field, often written:

\[ rwnd \]

The receive window tells the sender how many more bytes the receiver is currently willing to accept.

If the receive buffer has:

• total size \(RcvBuffer\);
• currently buffered data \(BufferedData\);

then approximately:

\[ rwnd = RcvBuffer - BufferedData \]

The sender limits unacknowledged in-flight data to at most \(rwnd\), unless congestion control is even more restrictive.

The receive window changes over time.

It increases when the application reads data from the buffer.

It decreases when new data arrives and fills buffer space.

Many operating systems auto-adjust receive buffer sizes. The default may start small, for example around 4096 bytes, and grow if necessary.

Although modern machines have lots of memory, kernel buffer memory is still a limited resource.

If the system allocates too much buffer memory for many connections, it can run out of kernel memory.

Therefore, buffer sizes are managed carefully.

If the receiver advertises:

\[ rwnd = 0 \]

then the sender cannot send normal data.

But if the receiver later frees buffer space, how does the sender learn this?

The receiver may not have a new data segment to send.

Therefore, the sender periodically sends small probes, often one byte, to test whether the receiver window has opened again.

If the receiver still has no space, it acknowledges the old next expected byte. The sender backs off and probes again later.

\[ Client \rightarrow Server: SYN=1,\quad Seq=x \]

The ACK flag is not set because the client does not yet know the server’s sequence number.

The client enters a SYN-SENT-like state.

\[ Server \rightarrow Client: SYN=1,\quad ACK=1,\quad Seq=y,\quad ACKnum=x+1 \]

The server acknowledges the client’s SYN.

Important:

A SYN consumes one sequence number.

So the ACK for \(Seq=x\) is \(x+1\), even if the SYN carries no application data.

The server also sends its own SYN with sequence number \(y\).

\[ Client \rightarrow Server: ACK=1,\quad Seq=x+1,\quad ACKnum=y+1 \]

This acknowledges the server’s SYN.

After this, both sides know that the other side is alive and has received the necessary initial state.

After the handshake:

• client data starts at sequence number \(x+1\);
• server data starts at sequence number \(y+1\).

Example:

If:

\[ x = 1000 \]

\[ y = 200 \]

Then:

1. Client sends:

   \[ SYN,\ Seq=1000 \]

2. Server sends:

   \[ SYN+ACK,\ Seq=200,\ ACK=1001 \]

3. Client sends:

   \[ ACK,\ Seq=1001,\ ACK=201 \]

If the client then sends 1000 bytes, it uses:

\[ Seq=1001,\quad Len=1000 \]

The next client sequence number becomes:

\[ 2001 \]

Like SYN, FIN consumes one sequence number.

If a side sends:

\[ FIN,\ Seq=x \]

the ACK is:

\[ ACK = x+1 \]

A typical close:

1. Client sends FIN.
2. Server ACKs the FIN.
3. Server may continue sending remaining data.
4. Server later sends FIN.
5. Client ACKs the server’s FIN.
6. Client waits in TIME-WAIT for \(2 \times MSL\).

Here \(MSL\) means maximum segment lifetime.

The endpoint that sends the final ACK waits to ensure old packets from the connection have disappeared from the network.

The wait is often:

\[ 2 \times MSL \]

This helps prevent old duplicate packets from being confused with a later connection using the same socket tuple.

FIN is graceful:

• one side says it has no more data to send;
• the other direction may still continue;
• state is cleaned up carefully.

RST is abrupt:

• it resets the connection;
• it is used for errors or unexpected packets;
• it tells the other side to discard connection state.

The lecture notes that historically, servers sometimes used RST instead of graceful FIN in some HTTP scenarios to avoid the cost of keeping many connections in TIME-WAIT or half-open states.

UDP is simple, fast, and connectionless.

It gives no reliability, ordering, flow control, or congestion control.

It is suitable when:

• the application can tolerate loss;
• low delay matters;
• the protocol is simple request-response;
• reliability is implemented elsewhere.

TCP provides reliable, in-order byte-stream communication.

It uses:

• sequence numbers;
• cumulative acknowledgements;
• retransmissions;
• timers;
• duplicate ACKs;
• flow control;
• congestion control;
• connection setup and teardown.

The most important rule:

\[ ACK = Seq + Length \]

for normal data, because the ACK number is the next byte expected.

But remember:

• sequence numbers count bytes, not segments;
• SYN and FIN each consume one sequence number;
• pure ACKs normally do not consume sequence number space;
• each direction has its own sequence number space.

TCP repairs loss using:

• timeout-based retransmission;
• fast retransmit after three duplicate ACKs.

Cumulative ACKs make ACK loss less serious because later ACKs can cover earlier data.

Flow control is receiver protection.

The receiver advertises:

\[ rwnd \]

The sender ensures that in-flight unacknowledged data does not exceed the receiver’s available buffer space.

Congestion control is network protection.

It was introduced but not fully covered in these lectures. The next lecture will focus on it.

The sender’s actual allowed in-flight data is limited by both:

\[ \min(cwnd, rwnd) \]

where \(cwnd\) protects the network and \(rwnd\) protects the receiver.

A two-way handshake is not enough because of delayed, reordered, or retransmitted messages.

TCP uses a three-way handshake:

\[ SYN \]

\[ SYN + ACK \]

\[ ACK \]

Connection closing is separate in the two directions and uses FIN/ACK, with RST for abrupt error handling.