Download TCP Traffic Control

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Net bias wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Deep packet inspection wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

IEEE 1355 wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Internet protocol suite wikipedia , lookup

TCP congestion control wikipedia , lookup

Transcript
TCP Traffic Control:
Performance and QoS
Implications
1
Introduction
1. Performance implications of TCP
Flow and Error Control
2. Performance implications of TCP
Congestion Control
3. Performance of TCP/IP over ATM
Chapter 12: TCP Traffic Control
2
TCP Flow and Error Control


Uses a form of sliding window (~GBN)
TCP’s flow control is known as a credit
allocation scheme:



Each transmitted octet is considered to have a
sequence number
Each acknowledgement can grant permission to send a
specific amount of additional data
TCP Window Size <= Min (CongWin, RcvWin)
Chapter 12: TCP Traffic Control
3
TCP Credit Allocation
Mechanism
Note: trailing edge
advances each time A
sends data, leading edge
advances only when B
grants additional credit by
acknowledging receipt.
Chapter 12: TCP Traffic Control
5
Effect of TCP Window Size
on Performance
W = TCP window size (octets)
R = Data rate (bps) at TCP source
D = Propagation delay (seconds)
between source and destination
 After TCP source begins
transmitting, it takes D seconds for
first bits to arrive, and D seconds
for acknowledgement to return (2RD
= RTT)
 TCP source could transmit at most
2RD bits, or RD/4 octets
Chapter 12: TCP Traffic Control
9
Maximum Normalized
Throughput S
1
S =
4W
RD
W  RD / 4
W  RD / 4
Where:
W = window size (octets)
R = data rate (bps) at TCP source
D = dprop (seconds) between TCP source and
destination, 2D = RTT
Note: RD (bits) known as “rate-delay product”
Chapter 12: TCP Traffic Control
10
Window Scale Parameter
(TCP header option: RFC 7323)
W = RD/4
W = 220 - 1
W = 216 - 1
RD
Chapter 12: TCP Traffic Control
“LONG, FAT NETWORKS”
11
Complicating Factors
Multiple TCP connections are multiplexed
over same network interface, reducing
data rate, R, per connection (S)
However:
 For multi-hop connections, D is the sum of
delays across each network plus delays at
each router, increasing D (S)
 If source data rate R at source exceeds
data rate on one of the hops, that hop will
be a bottleneck (S)
 Lost segments are retransmitted, reducing
throughput. Impact depends on
retransmission policy (S)

Chapter 12: TCP Traffic Control
12
Retransmission Strategy



TCP relies exclusively on positive
acknowledgements and
retransmission on acknowledgement
timeout
There is no explicit negative
acknowledgement (NAK-less)
Retransmission required when:
1.
2.
Segment arrives damaged, as indicated by
checksum error, causing receiver to
discard segment
Segment fails to arrive (implicit detection
scheme)
Chapter 12: TCP Traffic Control
13
TCP Timers



A timer is associated with each segment
as it is sent
If a timer expires before the segment is
acknowledged, sender must retransmit
Key Design Issue:
value of retransmission timer…


Too small: many unnecessary
retransmissions, wasting network
bandwidth
Too large: delay in handling lost segment
Chapter 12: TCP Traffic Control
14
TCP Implementation Policy
Options (per RFC 793/1122)
TCP’s Performance Dilemma:
 The TCP standard provides a very
precise statement of the protocol to
be used
 However, protocol stack implementers
have certain leeway with regard to
their implementation
 Mismatched implementations, while
interoperable, may suffer reduced
performance.
Chapter 12: TCP Traffic Control
22
TCP Implementation Policy
Options (per RFC 793/1122)
Performance implications?



Send: free to transmit when convenient
Deliver: free to deliver to application when
convenient
Accept: how data are accepted



Retransmit: how to handle queued, but not yet
acknowledged, data




In-order (out of order data is discarded)
In-window (accept and buffer any data in window)
First-only (timer per queue, retransmit segment FIFO)
Batch (timer per queue, retransmit whole queue)… GBN
Individual (timer per segment, retransmit by segment)
Acknowledge:


Immediate (send immediate ack for each good segment)
Cumulative (timed wait, and piggyback cumulative ack)
Chapter 12: TCP Traffic Control
23
TCP Congestion Control





Dynamic routing can alleviate congestion by
spreading load more evenly
But, only effective for unbalanced loads and
brief surges in traffic
Congestion can only be effectively
controlled by limiting total amount of data
entering the network
ICMP Source Quench message is crude and
not effective
RSVP may help, but not widely implemented
Chapter 12: TCP Traffic Control
24
TCP Congestion Control is
Difficult

IP is connectionless and stateless,
with no provision for detecting or
controlling congestion
–


RFC 3168 adds ECN to IP, but
deployment not ubiquitous
Standard TCP only provides end-toend flow control
There exists no cooperative,
distributed algorithm to bind
together various TCP entities
Chapter 12: TCP Traffic Control
25
TCP Segment Pacing: Self-Clocking
Congestion
Control
(bottleneck
in the
network)
IMPLICATIONS??
Flow Control
( bottleneck
at the
receiver)
Chapter 12: TCP Traffic Control
27
TCP/IP Performance Issues
vis-à-vis QoS
1.
2.
Appropriate Timeout Value
– “Goldilocks dilemma”
Window management in the
face of congestion
– “Go as fast as you can, but don’t get
caught!”
3.
4.
Implicit congestion control
– “Too little, too late?”
TCP/IP over ATM
– “Ac-cen-tuate the positive… e-lim-inate
the negative.”
Chapter 12: TCP Traffic Control
31
RTT Variance Estimation
(Jacobson’s Algorithm)
3 sources of high variance in RTT
 If data rate is relatively low, then
transmission delay will be relatively
large, with larger variance due to
variance in packet size
 Load may change abruptly due to
other sources
 Peer may not acknowledge segments
immediately
Chapter 12: TCP Traffic Control
32
Jacobson’s Algorithm
SRTT(K+1) = (1 – g) × SRTT(K) + g × RTT(K+1)
SERR(K+1) = RTT(K+1) – SRTT(K)
SDEV(K+1) = (1 – h) × SDEV(K) + h ×|SERR(K+1)|
RTO(K+1) = SRTT(K+1) + MAX[G, f × SDEV(K+1)]
–
–
–
–
g = 0.125 ()
h = 0.25 ()
f = 2 or f = 4 (most implementations use f = 4)
G is granularity of local clock
Chapter 12: TCP Traffic Control
33
Jacobson’s RTO Calculations
Decreasing function
Increasing function
Chapter 12: TCP Traffic Control
34
Two Other Factors
Jacobson’s algorithm can significantly
improve TCP performance, but:

What RTO should we use for
retransmitted segments?
ANSWER: exponential RTO backoff
algorithm

Which round-trip samples should we
use as input to Jacobson’s algorithm?
ANSWER: Karn’s algorithm
Chapter 12: TCP Traffic Control
35
Exponential RTO Backoff
Increase RTO each time the same
segment is retransmitted – backoff
process
 Multiply RTO by constant:

RTO = q × RTO

q = 2 is called binary exponential
backoff (like Ethernet CSMA/CD)
Chapter 12: TCP Traffic Control
36
Which Round-trip Samples?

If an ack is received for a
retransmitted segment, there are
2 possibilities:
1.
2.


Ack is for first transmission
Ack is for second transmission
TCP source cannot distinguish
between these two cases
No valid way to calculate RTT:
–
–
From first transmission to ack, or
From second transmission to ack?
Chapter 12: TCP Traffic Control
37
Karn’s Algorithm
Must not use measured RTT for
retransmitted segments to update
SRTT and SDEV
 Calculate exponential backoff RTO
when a retransmission occurs
 Use backoff RTO for segments until
an ack arrives for a segment that
has not been retransmitted
 Then use Jacobson’s algorithm to
calculate RTO

Chapter 12: TCP Traffic Control
38
Dynamic Window Sizing on
Congestion
A lost segment indicates congestion
 Prudent (conservative) to reset cwnd
to 1 and begin slow start process
 May not be conservative enough:
“easy to drive a network into
saturation but hard for the net to
recover” (Jacobson)
 Instead, use slow start with linear
growth in cwnd after reaching a
threshold value

Chapter 12: TCP Traffic Control
42
TCP Congestion Window: Slow Start,
Fast Retransmit, Fast Recovery (Ex.)
Fast Retransmit with
Congestion Avoidance
Fast Recovery
Slow Start
Chapter 12: TCP Traffic Control
48
Explicit Congestion Notification
in TCP/IP – RFC 3168

ECN capable router sets congestion bits
in the IP header of packets to indicate
congestion
0
1
2
3
4
5
6
7
ECN
DSCP
IPv4 TOS field, IPv6 Traffic Class field

TCP receiver sets bits in TCP ACK header
to return congestion indication to peer
(sender)
0
1
2
HLEN
3
4
5
6
RSVD
7
8
C
W
R
9
E
C
E
10
U
R
G
11
A
C
K
12
P
S
H
13
R
S
T
14
S
Y
N
15
F
I
N
TCP Header flag field

TCP senders respond to congestion
indication as if a packet loss had occurred
Chapter 12: TCP Traffic Control
49
Explicit Congestion Notification
in TCP/IP – RFC 3168
0
1
2
3
4
5
6
7
ECN
DSCP
0
0
1
1
0
1
2
HLEN
3
4
5
6
RSVD
7
8
C
W
R
9
E
C
E
0 0
0 1
1 0
1 1
Chapter 12: TCP Traffic Control
10
U
R
G
0
1
0
1
11
A
C
K
Not ECN Capable Transport
ECT (1)
ECT (0)
Congestion Experienced
12
P
S
H
13
R
S
T
14
S
Y
N
15
F
I
N
Set-up: not ECN Capable response
Receiver ECN-Echo: CE packet
received
Sender Congestion Window Reduced
acknowledgement
Set-up: with SYN to indicate ECN
capability
50
TCP/IP ECN Protocol
TCP
Sender
Hosts negotiate ECN capability
during TCP connection setup
TCP
Receiver
SYN + ECE + CWR
SYN ACK + ECE
Sender
TCP
Sender
IP
reduces
marks data
window
size
packets
as
and
marks
ECN
next
packet
Capable
with
CWR
Transport
Chapter 12: TCP Traffic Control
Routers
Routers mark
mark ECN-capable
ECN-capable
IP
IP packets
packets if
if Congestion
Congestion
Experienced.
Experienced.
Receiver TCP
Acks packets
with ECNEcho set if
CE bits set
in IP header.
51
TCP/IP ECN – Some Other
Considerations




Sender sets CWR only on first data
packet after ECE
CWR also set for window reduction for
any other reason
ECT must not be set in retransmitted
packets
Receiver continues to send ECE in all ACKs
until CWR received
– Delayed ACKs: if any data packet has CE set,
send ECE
– Fragmentation: if any fragment has CE set,
send ECE
Chapter 12: TCP Traffic Control
52
Performance of TCP over
ATM
How best to manage TCP’s segment
size, window management and
congestion control mechanisms…
 …at the same time as ATM’s quality
of service and traffic control
policies
 TCP may operate end-to-end over
one ATM network, or there may be
multiple ATM LANs or WANs with
non-ATM networks

Chapter 12: TCP Traffic Control
54
TCP/IP over AAL5/ATM
TCP
IP
AAL5
Convergence S/L
SAR S/L
ATM
CPCS Trailer:
•CPCS-UU Indication
•Common Part Indicator
•PDU Payload Length
•Payload CRC
Chapter 12: TCP Traffic Control
55
Effect of Switch Buffer Size
(example - Romanow & Floyd)







Data rate of 141 Mbps
End-to-end propagation delay of 6 μs
IP packet sizes of 512 – 9180 octets
TCP window sizes from 8 Kbytes to 64
Kbytes
ATM switch buffer size per port from
256 – 8000 cells
One-to-one mapping of TCP connections to
ATM virtual circuits
TCP sources have infinite supply of data
ready
Chapter 12: TCP Traffic Control
57
Performance of TCP over UBR
(UBR)
(UBR)
Chapter 12: TCP Traffic Control
58
Observations
If a single cell is dropped, other
cells in the same IP datagram are
unusable, yet ATM network forwards
these useless cells to destination
 Smaller buffer increases probability
of dropped cells
 Larger segment size increases
number of useless cells transmitted
if a single cell dropped

Chapter 12: TCP Traffic Control
59
Approach: Partial Packet and
Early Packet Discard


Reduce the transmission of useless cells
Work on a per-virtual-channel basis
Partial Packet Discard
– If a cell is dropped, then drop all subsequent
cells in that segment (i.e., up to and including
the first cell with SDU type bit set to one)
Early Packet Discard
– When a switch buffer reaches a threshold
level, preemptively discard all cells in a
segment
Chapter 12: TCP Traffic Control
60
Performance of TCP over UBR
(UBR)
Chapter 12: TCP Traffic Control
61
ATM Switch Buffer Layout –
Selective Drop and Fair Buffer
Allocation
Chapter 12: TCP Traffic Control
62
EPD Fairness - Selective Drop
Ideally, N/V cells buffered for each
of the V virtual channels
 Weight ratio, W(i) = N(i) = N(i) × V
N/V
N
Selective Drop:
 If N > R and W(i) > Z
then drop next new packet on VC(i)
 Z is a parameter to be chosen
(studies show optimal Z slightly < 1)

Chapter 12: TCP Traffic Control
63
Fair Buffer Allocation
More aggressive dropping of packets
as congestion increases
 Drop new packet when:

N > R and W(i) > Z × B – R
N-R
Note that the larger
the portion of the
“safety zone” (B-R)
that is occupied, the
smaller the number
with which W(i) is
compared.
R
Chapter 12: TCP Traffic Control
64
TCP over ABR




Good performance of TCP over UBR can
be achieved with minor adjustments to
switch mechanisms (i.e., PPD/EPD)
This reduces the incentive to use the
more complex and more expensive ABR
service
Performance and fairness of ABR is quite
sensitive to some ABR parameter settings
Overall, ABR does not provide significant
performance over simpler and less
expensive UBR-EPD or UBR-EPD-FBA
Chapter 12: TCP Traffic Control
65