Advanced Lab in Computer

Communications
M e e t in g 5 – Transmission Control Protocol

Instructor: Noam Koenigstein

Some slides taken from:

1)Computer Networks 2008 in CS department, Yale (Instructor: Y. Richard
Yang)

2)Introduction
to Computer Networks, EE School, TAU (Instructor: Yuval Shavitt
in 2004 and Boaz Patt-Shamir in 2005)

3)Computer Communications 2009, EE School, TAU (Instructor Yuval Shavitt)

TCP- Transmission Control Protocol

Virtual Circuit protocol Application

Transport

Reliable in-order delivery

Network

Full-duplex data transmissions Data Link

Physical

Congestion control
TCP – ACKs and Sequence #s

SNs facilitate detection of lost packets and in

order communication
 Sequence numbers- Count bytes, not packets.

ACKs- The SN of the next byte expected on the

other side.

GBN - In some implementation, cumulative ACKs

(Tahoe)
ACKs and SNs Examples
ACKs and SNs Examples (2)
Sequence Numbers
Requirement: SN large enough so that sender does not confuse

 Sending at R bps

 Packet can live up to MPL seconds

(MPL- Maximum Packet Lifetime)

 Receiver may delay up to A secs

 Sender waits T before giving up

 max_seq > R(2MPL+A+T)

 In practice: SN and ACK are 32 bit

TCP – Connection Setup
TCP – Connection termination
TCP Congestion Control

How does TCP limits its sending rate?

Congestion Window – CWD

Sender Limits Transmission:

LastByteSent – LastByteAcked ≤ min{CWD,AdWindow}

When CWD ≤ AdWindow:

rate = CWD / RTT Bps

CWD is a dynamic function of perceived network congestion

 Receiver Buffering
flow control receiver: explicitly informs
sender won’t overrun sender of (dynamically
receiver’s buffers by changing) amount of
transmitting too free buffer space
much,  RcvWindow field in
too fast TCP segment
RcvBuffer = size or TCP Receive Buffer sender: keeps the amount
RcvWindow = amount of spare room in Buffer of transmitted, unACKed
data less than most
recently received
RcvWindow

receiver buffering
11
TCP Congestion Control (2)

Closed-loop, end-to-end, window-based congestion control

Designed by Van Jacobson in late 1980s, based on the AIMD

alg. of Dah-Ming Chu and Raj Jain

Works well so far: the bandwidth of the Internet has increased

by more than 200,000 times

Many Versions
TCP/Tahoe: this is a less optimized version
TCP/Reno: many OSs today implement Reno type
congestion control
TCP/Vegas: not currently used
TCP Tahoe (1)

Slow Start:

Set CWD = 1
For each ACK CWD++

Exponential growth – CWD

doubles every RTT

When CWD = SSTHRESH

move to Congestion Avoidance.
Van Jacobson
January 2006

This pic is not TCP Tahoe

In TCP Tahoe – Cumulative

ACKs are used
TCP Tahoe (2)

Congestion Control:
On every ACK CWD += 1/CWD
Linear growth:
CWD increases by one byte for
every CWD bytes sent.

Timeouts:
Timeouts (TO) used to detect packet
failures.
After a timeout occurred:
CWD = 1
SSTRESH = CWD/2
Begin start Slow Start all over again.
TCP Round Trip Time and Timeout

EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT

Exponential weighted moving average
influence of given sample decreases exponentially
fast
typical value of x: 0.1
Setting the timeout

EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|

16
TCP Tahoe – Problems

Takes a complete timeout interval to detect a

packet loss

Cumulative ACKs-
Follows a Go-Back-N approach.
Every time a packet is lost, need to send the
whole window…
TCP Reno
TCP Reno (1)

Adds a mechanism to detect lost packets earlier:
ACK after every segment
3 duplicate ACKs (TD) means that a segment was lost

Fast Retransmit-
After 3 duplicate ACKs, assume that the packet was lost
and retransmit immediately.
Fast Recovery-
Skip slow start- go right to Congestion Control:
SSTRESH = CWD/2
CWD = SSTRESH

If a timeout occurred, do the same as before:

SSTRESH = CWD/2
CWD=1
(Slow Start)
TCP Reno (2)
TCP Reno The “Big” Picture

cwnd

TD TD TD
TO
ssthresh

ssthresh ssthresh
ssthresh

Time
slow congestion congestion congestion slow congestion
start avoidance avoidance avoidance start avoidance

TD: Triple duplicate acknowledgements

TO: Timeout

21
Reno in Steady State
SNs and CWND
AIMD - Additive Increase Multiplicative Decrease

x2

fairness line:
x1=x2

overload
x0

efficiency
underload line: x1+x2=C

x1

24
TCP Throughput - Objective

To understand the throughput of TCP/Reno

as a function of RTT (RTT), loss rate (p) and
packet size

We will derive the formula twice, using two

setups using two different approaches

25
TCP/Reno Throughput Modeling

Given mean packet loss rate p, mean round-trip

time RTT, packet size S
Consider only the congestion avoidance mode
(long flows such as large files)
Assume no timeout
Assume mean window size is Wm segments,
each with S bytes sent in one RTT:

Wm * S
throughput ≈ bytes/sec
RTT

26
 TCP/Reno Throughput Modeling:
(deterministic)

Consider congestion avoidance only

cwnd
3W W
= 3W 2
TD
4 2 8
W Wm = 3W
4

available
ssthresh bandwidth

W/2
Time
congestion
avoidance
Assume one packet loss (loss event) per cycle
Total packets send per cycle = (W/2 + W)/2 * W/2 = 3W2/8
Thus p = 1/(3W2/8) = 8/(3W2)
W= 8/3
p
= 1.6
p
⇒ throughput = S 3 1.6
RTT 4 p = 1. 2 S
RTT p

27
TCP/Reno Throughput Modeling
(random loss)

 W1 if the packet is not lost

∆W =  W
− 2 if packet is lost

mean of ∆W = (1 − p ) W1 + p (− W2 ) = 0
2 (1− p )
=> mean of W = p ≈ 1.4
p
, when p is small

=> throughput ≈ 1.4 S

RTT p
, when p is small

28
TCP Reno - Problems

Can only detect a single packet loss:

If there’s a multiple packet drop, the first info
about the first packet loss comes when we
receive duplicate ACKs. But the information
about the second packet loss will be delayed.

If the window is too small it is possible that we will

not receive enough duplicate ACKs for Fast
Retransmission.
TCP NewReno

Performance improvements for TCP Reno

More “aggressive” than regular Reno

Modifications only in the senders end

Improve performance against the multiple

packet lost problem of Reno
 TCP Vegas (1)

Congestion Avoidance (rather than Congestion Control)
Detect congestion before losses occur!

When bandwidth is tight, first routers try to buffer up packets.

Only when they are out of buffers, packets are dropped
->
Don’t use lost packets as a signal of congestion.

Vegas tries to estimate the available bandwidth, and increase/

decrease the transmission rate accordingly

An improved fast retransmission that utilizes RTT to overcome

Reno’s problem with small windows and with multiple losses.

Modified Slow Start to prevent overshooting at connection

establishment
Vegas increases exponentially every other RTT.
 TCP Vegas (2)

BaseRTT: RTT when flow is not congested (usually measured on the first packet).
ExpectedRate = CWD / BaseRTT

CurrentRTT = AckTime – SendingTime

ActualRate = CWD / CurrentRTT

Diff = ExpectedRate – ActualRate

If Diff < 0
Need to update BaseRTT: replace BaseRTT with CurrentRTT
Hence Diff is non-negative.

Define 2 thresholds: α < β

If Diff > β
We are close to congestion (routers are buffering packets), thus we need to decrease
CWD
If Diff < α
We are not utilizing the available bandwidth (we are close to ExpectedRate), thus
increase CWD

By updating CWD, TCP monitors Diff so that:

α < Diff < β
TCP Implementation In Practice

TCP is implemented as part of the OS.

In practice, TCP is no longer defined by a spec. It is defined by the implementation.

Often different implementations interoperate with performance problems

Windows Vista TCP/IP stack includes a component called Compound TCP (CTCP). If
enabled it uses “aggressive” congestion window algorithms borrowed from Vegas.

CTCP is enabled by default in computers running Windows Server 2008 and disabled
by default in computers running Windows Vista.

In Linux there are different TCP flavors with every release. Starting with Linux 2.6.13
the congestion window algorithm is pluggable and can be set to work according to
Reno, Vegas, Hybla (for satellites links), BIC and many more algorithms. The
administrator can set the correct algorithm according to the connection type he has.
 TCP over Wireless – New Challenges

The basic assumption behind TCP is that packets are lost due
to congestion, and that transmission errors are very rear.
This is not true for Wireless networks.

In wireless packet loss occurs more often due to unreliable

link: Poor SNR, 802.11 Ack loss, noise and interference.

In wireless, packet loss does not necessarily indicate

congestion. Therefore congestion window should not be
decreased.

Mobility may change the connection quality. Need to adjust

congestion window according to the changing connection
quality.

Bigger frames tend to have higher FER, than smaller ones

(This is true also in wired LAN, but the difference is
insignificant).

TCP over wireless- Hot topic for researches around the world!
TCP over Wireless – Some Solutions...

Timeout calculation:
Old method: Using only mean of RTT
New method: Using both mean and standard deviation of RTT

Link layer mechanisms:

1. Forward Error Correction (FEC)
2. Automatic Repeat Request (ARQ)
3. Adaptive Link layer: Dynamically vary FEC, retransmission limit, frame size

Split TCP connection solution:

Different protocols on each line. Fixed Base Mobile
The base station buffers between Host Station Host
the sender and receiver.
(Indirect TCP, Selective Repeat
Protocol (SRP), Mobile TCP)

TCP Aware Link Layer Protocols:

Snoop Protocol – Base monitors returning ACKs. No changes to MS, FS
Partial ACK Protocols – Normal ACKs, Partial ACKs that doesn’t cause backoff, only
retransmission.
Secure Shell

The goal of SSH is to replace Telnet, RSH

and Rlogin which did not provide strong
authentication or guarantee confidentiality.

First version released in 1995 as a freeware,
and gained popularity quickly.

Today there are a few open source versions
available.

SCP and SFTP are using SSH to allow an
encrypted file transfer environment.
Strong Authentication

2 Factor Authentication –

Requires 2 independent ways of

establishing identity.

Classic example: Credit Cards

Public-key Encryption

Each server publishes its public key which is

used to encrypted its messages.

To decrypted the messages the user needs a
special private key.

The private key is kept in a secured box that
can be opened only with a password.

Neither the password nor the private key ever
leave the user’s machine.
SSH Secure Shell (1)
SSH Secure Shell (2)
SSH Secure Shell (3)