Discussion 6: TCP, Congestion Control

Discussion 6:

TCP, Congestion Control

CSE 123: Computer Networks

Marti Motoyama & Chris Kanich

UDP: User Datagram Protocol

UDP: “best-effort” service

Connectionless, meaning no state setup

Unreliable, meaning lost packets are not re-sent

No flow control

No congestion control

CSE 123 – Discussion 4 2

Doesn’t seem very useful…

Useful for real time applications! If your Counterstrike data arrives at game server ten seconds

late, it is pretty much useless

UDP applications can implement their own packet loss checking, but it is best to use TCP for this

Question: What is the checksum in UDP computed over? Why does UDP have a checksum?


TCP Service Model

TCP Service Model

Reliable, in-order, byte-stream delivery and with

good performance

Challenges - the network can:

drop packets

delay packets

deliver packets out-of-order

replicate packets

corrupt packets


Providing Reliable Delivery

Checksum:

Used to detect corrupted data at the receiver,

leading the receiver to drop the packet

Sequence numbers:

Used to detect missing data and for putting the data

back in order

Retransmission

Sender retransmits lost or corrupted data

Timeout based on estimates of round-trip time

Fast retransmit algorithm for rapid retransmission


TCP Flow Control

TCP is a sliding window protocol For window size n, can send up to n bytes without receiving

an acknowledgement

When the data is acknowledged then the window slides forward

Each packet advertises a window size Indicates number of bytes the receiver has space for

Original TCP always sent entire window Congestion control now limits this


Establishing TCP Connection

Each side notifies other of starting sequence number it will use for sending Why not simply chose 0?

» Must avoid overlap with earlier incarnation

» Security issues

Each side acknowledges other’s sequence number SYN-ACK: Acknowledge sequence

number + 1

Can combine second SYN with first ACK


SYN: SeqC

ACK: SeqC+1

SYN: SeqS

ACK: SeqS+1

Client Server

Tearing down TCP Connection

Either side can initiate tear

down

Send FIN signal

“I’m not going to send any more

data”

Other side can continue

sending data

Half open connection

Must continue to acknowledge

Acknowledging FIN

Acknowledge last sequence

number + 1


A B

FIN, SeqA

ACK, SeqA+1

ACK

Data

ACK, SeqB+1

FIN, SeqB

Win. Flow Control: Sender


Source Port Source Port Dest. Port Dest. Port

Sequence Number Sequence Number

Acknowledgment Acknowledgment

HL/Flags HL/Flags Window Window

D. Checksum D. Checksum Urgent Pointer Urgent Pointer

Options… Options…

Source Port Source Port Dest. Port Dest. Port

Sequence Number Sequence Number

Acknowledgment Acknowledgment

HL/Flags HL/Flags Window Window

D. Checksum D. Checksum Urgent Pointer Urgent Pointer

Options... Options...

Packet Sent Packet Received

acknowledged sent to be sent outside window

App write

Adv. Window Question

What situation leads to advertised window becoming

0? What can the sender do in this situation?


UDP vs TCP: Part 1

Suppose a TCP flow and a UDP flow are sharing the

same link. The UDP flow sends at a rate equal to the

link capacity. Assuming the flows send for an

extended period of time, how would the flows end up

splitting the bandwidth?


UDP vs TCP: Part 2

Decide whether you should use UDP or TCP for the

following applications and justify:

File transfer

Skype video chatting

DNS


What we know…

We know how to not overrun a receiver (flow

control)….

Now… let’s look at how congestion control keeps a set

of senders from overloading the network


Congestion Control

Two basic components:

1. Detecting congestion: how do we know when we

are stressing the network

2. Rate adjustment algorithm

» Depends on whether congestion is occurring or not

» Three subproblems within adjustment problem:

1. Finding bottleneck bandwidth

2. Adjusting to bandwidth variations

3. Sharing bandwidth “fairly”


Detecting Congestion

Packet dropping is best sign of congestion Delay-based methods are hard and risky

How do you detect packet drops? ACKs TCP uses ACKs to signal receipt of data

ACK denotes last contiguous byte received » Actually, ACKs indicate next segment expected

Two signs of packet drops: 1. No ACK after certain time interval: time-out

2. Several duplicate ACKs


Rate Adjustment

Basic structure:

Upon receipt of ACK (of new data): increase rate

Upon detection of loss: decrease rate

But what increase/decrease functions should we use?

Depends on what problem we are solving

» Problem 1: What is the bottleneck bandwidth?

» Problem 2: How do we respond to oscillations in the bandwidth?

» Problem 3: How do we share the links fairly?

Close relationship between solving problems 2 and 3


Finding Available BW: Slow Start

Goal: Get a first-order estimate of the available bandwidth Assume bandwidth is fixed

Ignore presence of other flows

Want to start slow, but rapidly increase rate until packet drop occurs (“slow-start”), which indicates to the receiver that link is saturated


Slow Start Continued

cwnd increases exponentially: cwnd doubles every

time a full cwnd of packets has been sent

Each ACK releases two packets

Slow-start is called “slow” because of starting point


cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8

cwnd = 3

Slow Start Question

In what situation does slow start result in the most

number of losses?


BW Oscillations/Fairness

Goal 1: Track available bandwidth, oscillating around

its current value

Goal 2: If two identical flows are in the system, then

each should end up with roughly the same bandwidth

Four alternatives for accomplishing goals 1 and 2: AIAD: gentle increase, gentle decrease

AIMD: gentle increase, drastic decrease

MIAD: drastic increase, gentle decrease

MIMD: drastic increase and decrease

Suppose we have a router that can process 50 pkts/RTT and can buffer 20 packets…


AIMD Sharing Dynamics

No congestion rate increases by one packet/RTT every RTT

Congestion decrease rate by factor 2


A B

D E x2

x1

0

10

20

30

40

50

60

1 31 61 91 121 151 181 211 241 271 301 331 361 391 421 451 481

Rates equalize fair share

AIAD Question

Suppose we used AIAD:

No congestion x increases by one packet/RTT every RTT

Congestion decrease x by 1

What does the previous graph roughly look like?


Implementing AIMD

After each ACK

Increment cwnd by 1/cwnd (cwnd += 1/cwnd)

As a result, cwnd is increased by one only if all segments in a

cwnd have been acknowledged

But need to decide when to leave slow-start and enter

AIMD

Use ssthresh variable


Slow Start/AIMD Pseudocode


Initially:

cwnd = 1;

ssthresh = infinite;

New ack received:

if (cwnd < ssthresh)

/* Slow Start*/

cwnd = cwnd + 1;

else

/* Congestion Avoidance */

cwnd = cwnd + 1/cwnd;

Timeout:

/* Multiplicative decrease */

ssthresh = cwnd/2;

cwnd = 1;

TCP Win Size Question 1

A TCP connection has a congestion window of 4000

bytes. The maximum segment size

used by the connection is 1000 bytes. What is the

congestion window after it sends out 4 segments

and receives acks for all of them if the connection is in

slow start?


TCP Win Size Question 2

A TCP connection has a congestion window of 4000

bytes. The maximum segment size

used by the connection is 1000 bytes. What is the

congestion window after it sends out 4 segments

and receives acks for all of them if the connection is in

congestion avoidance?


The big picture (with timeouts)


Time

cwnd

Timeout

Slow

Start

AIMD

ssthresh

Timeout

Slow

Start

Slow

Start

AIMD

Optimizations

Fast retransmit

Goal: Avoid timeouts, since they are slow

Use receipt of 3 or more duplicate acks as indication of loss

Avoids waiting for timeout to retransmit packet

Fast recovery

Goal: Avoid stalling (dropping cwnd=1) after loss

After fast retransmit:

» Set ssthresh to cwnd/2

» Set cwnd to cwnd/2 + 3(for the 3 dup acks already seen)

» Increment cwnd by 1 MSS for each additional duplicate ACK

» After receiving new Acknowledgment, reset cwnd to ssthresh


TCP Question

Consider a TCP flow sending 7 segments. Due to

congestion, the TCP flow experiences exactly 2

losses. Only segments can be lost,

acknowledgements are not lost.

The time it takes the sender to send all segments

represents the difference between:

(i) the time the sender receives the ack for the last segment

(ii) the time the sender sends the first segment.

The retransmission timeout (RTO) is twice the RTT,

i.e., RTO = 2*RTT


TCP Question

What is the minimum time it could take the sender to

send all segments as a function of RTT? Show the

cwnd used by the sender when sending each

segment. Assume Fast Retransmission and Fast

Recovery.


Discussion 6: TCP, Congestion Control

Documents

Transcript of Discussion 6: TCP, Congestion Control