solutions for improving tcp performance over emerging networks k.r.renjish kumar kaleelaz@comp...
TRANSCRIPT
Solutions for Improving TCP Performance over Emerging
NetworksK.R.Renjish Kumar
kaleelaz@comp
Centre for Internet Research
Outline
Introduction Emerging Networks TCP TCP over Emerging Networks
– Issues – Solutions
TCP HACK MBM
Introduction
Internet has come a long way with:– Different kinds of networks– increasing number of users – innumerable applications which require better
quality of service.
Emerging Networks
Lossy Link networks– Wireless networks like wavelans– Satellite networks
Quality of Service(QoS) model based networks– Integrated Services (IntServ): Provides QoS in a per
connection basis– Differentiated Services (DiffServ): Provides QoS for an
aggregate flow. Much more scalable compared to IntServ.
Transmission Control Protocol (TCP)
De facto Transport layer Protocol– 95% of data byte
share in the Internet
– Common applications like Telnet,FTP and HTTP uses TCP
TCP contd…
TCP Header– Sequence Number :
the first byte of data in this segment.
– Options: For any additional features.
Rate Control– Slow start,fast
retransmit,recovery, congestion
avoidance.– Segments send equal
to the minimum of the sender’s window(cwnd) and receivers window.
Emerging Networks-Lossy Networks
Access Networks are increasingly becoming wireless eg: wavelans
Acts as bottlenecks. Bandwidth limited. Prone to higher rate of corruption
TCP over Lossy Links …
Issues – performs poorly in lossy links where the rate of corruption of
packets are higher Reason: TCP assumes that loss of packets are due to
congestion and not corruption, thus reducing the cwnd and thus reducing the throughput.
Solution
TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links.IEEE INFOCOM 2001,Anchorage,Alaska
R.K.Balan,B.P.Lee,K.R.R.Kumar,L.Jacob,W.K.G.Seah,
A.L.Ananda, IEEE INFOCOM 2001,Anchorage,Alaska
TCP HACK
Key ObservationsFor most data transfers, the data portion of a
TCP packet is much larger than the header portion of the packet (may not be true for interactive traffic)
As such, corruptions are far more likely to occur in the data portion and not the header portion
Given this scenario, can we make use of the intact header to make TCP perform better?
TCP Hack Algorithm contd..
On receiving this specially marked ACK packet, the sender will know that packet corruption and not congestion has occurred
As such, the sender will retransmit the corrupted packet and will not half its congestion window
Header Checksum option
Kind=14
Length=41’s complement checksum of TCP header and pseudo-IP header
Kind=15
Length=632-bit sequence number of corrupted segment to resend
TCP Header Checksum option
TCP Header Checksum ACK option
TCP Sender
Header checksum option enabled?
Continue as per normal
1) Calculate header checksum of segment2) Continue as per normal
Yes
No
Data segment to be sent
Modifications to the TCP sender
TCP Receiver
TCP segment corrupted?
Continue as per normal
1) Recover sequence number of corrupted segment from header. 2) Generate ‘special’ ACK (option 15) containing the sequence number of the corrupted segment.
Yes
No
Data segment received
Header portion corrupted?
Discard PacketYes
No
ACK Processing
Option 15 present in the segment?
1) Extract sequence number of corrupted segment2) Selectively retransmit the segment 3) ACK is discarded without further processing
Yes
No
ACK segment received
Modification to the ACK processing
Note
For TCP HACK to be effective, link layer retransmissions and error recovery should be turned off
Corrupted packets should be sent up to the TCP layer where TCP HACK will do the retransmissions
Experimental Setup
Implemented into the Linux 2.2.10 kernel
Test bed was set up comprising of 3 machines
Client and server were running TCP HACK
2 different models were used– Single packet
corruption. – Burst corruption with
differing burst lengths
Client ServerError / Delay Box
Experimental test bed
Low Latency Links
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Percentage Packet Loss (%)
Th
rou
gh
pu
t (K
Byte
s/s
)
sack
hack+sack
hack
new reno
1
2
34
1
2
3
4
Throughput versus percentage packet loss for short latency (10 ms) link with random single packet errors
High Latency Links
0
5
10
15
20
25
30
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Percentage Packet Loss (%)
Th
rou
gh
pu
t (K
Byte
s/s
) sack
hack+sack
hack
new reno
1
2
3
4
1
2
3
4
Throughput versus percentage packet loss for long latency (300 ms) link with random single packet errors
Number of slow starts
Fig. 7: Average number of slow-starts for long latency link with random single packet errors
0
10
20
30
40
50
60
70
0 3 6 9 12
Percentage Packet Loss (%)
Av
era
ge N
um
ber o
f S
low
-S
tarts
newreno
sack
hack
hack+sack
Observations
Both SACK and TCP-HACK are better than NewReno
Hence NewReno was removed from the tests when burst errors were introduced
Burst errors
12.988
20.0838 19.7595
15.5958
3.5406
16.436
19.9486
0.5402
4.6428
0
5
10
15
20
25
2 5 10Length of Burst Error (packets)
Th
rou
gh
pu
t (K
B/s
)
hack+sackhacksack
Throughput for 2% burst error for various burst lengths
11.016211.6934
8.531
5.95827.6964
1.4022
0.21120.7454
8.5608
0
2
4
6
8
10
12
2 5 10Length of Burst Error (packets)
Th
rou
gh
pu
t (K
B/s
)
hack+sackhacksack
Throughput for 5% burst error for various burst lengths
Throughput vs Time
0
100
200
300
400
500
0 400 800 1200 1600 2000 2400 2800
Time (s)
Th
rou
gh
pu
t (K
b/s
) hack+sack
hack
sack
Throughput versus Time graph for various TCP implementations (5% packet error rate with burst length of 5)
Inference
How is TCP HACK doing retransmissions a good idea?– Could help stabilize TCP and prevent it’s RTT
calculation from fluctuating widely (especially useful when using a long latency link)
– Provides more information to TCP, thus preventing it from unnecessarily timing out
– Distinguishes between congestion and corruption – Improves overall TCP performance
Emerging QoS Network Architecture
Differentiated Services (DiffServ)– Provides QoS for aggregate flows using different
per hop forwarding behaviours at the core routers.
Basic building blocks of DiffServ– Classifiers– Meters– Markers– Policers
DiffServ
Classifier
Meter
Marker PolicerPacket
Logical View of a Packet Classifier and Traffic Conditioner
TCP over QoS based Networks
Issues– Bias against connections with long Round Trip Time (RTT)
Reason:Long RTT flows takes longer time to ramp up.
– Bias against connections with smaller window sizes Reason: Smaller windows mean smaller throughput
– Protection from unruly traffic like UDP traffic. Reason: UDP traffic has no rate control mechanism and
hence kills TCP traffic.
Solution
A Memory-Based Approach for a TCP-Friendly Traffic Conditioner in DiffServ Networks.to appear in Proc. of the 9th IEEE International Conference on Network Protocols (ICNP 2001), Riverside, California.
K.R.R.Kumar, A.L.Ananda, Lillykutty Jacob
Topology
Memory-Based Marker (MBM)
Key observations– Markers, one of the building blocks of a traffic conditioner play a major role for resource allocation in a DiffServ network. – TCP performance is highly influenced by two
parameters, namely RTT, and window size. – Markers are mostly deployed at the edge routers,
which cannot easily decide the window size and RTT of the various TCP connections passing through.
What is needed?
Marking algorithm– Least sensitive to both the marker and TCP
parameters– Should be transparent to end hosts.– Maintain optimum marking– Tracks the TCP dynamics
Why memory-based marker?
During the period when TCP flows experience
congestion, either or both of the following occurs:
a) The cwnd reduces reducing the value of W
b) The RTT increases
causing a decrease in throughput or rate of flow.
Why memory-based marker?
The TCP window size W and the round trip time RTT are related to the throughput by the equation:
BW = ¾*(MSS*W)/(RTT) where W is expressed in
number of segments. Any variation in W or RTT is reflected as subsequent
changes in BW, i.e., in our case, the avg_rate. The parameter previous average rate (par) is compared with
the present average rate to track any change in the rate of flow and thus indirectly extract the variations in RTT or W.
MBM Algo. explained
In the expression for the marking probability mp,– (par – avgrate)/avgrate tracks the variations in
RTT and window size (W) and thus increases or decreases the marking probability according to the changes in the flow rate.
– (1- avgrate)/cir constantly compares the average rate observed with the target rate to keep the rate closer to the target.
MBM Algorithm
For each packet arrival If avg_rate cir then mp=mp+(1-avg_rate/cir)+
(par- avg_rate)/avg_rate; par = avg_rate; mark the packet using: cp 11 w.p. mp cp 00 w.p. (1-mp)
else if avg_rate > cir
then
mp= mp + (par – avg_rate)/avg_rate;
par=avg_rate;
mark the packet using:
cp 11 w.p. mp
cp 00 w.p. (1-mp)
MBM Algo. Contd…
where,
avg_rate= the rate estimate upon each packet arrival
mp = marking probability (1)
cir = committed information rate (i.e., the target rate)
par = previous average rate
cp denotes ‘codepoint’ and w.p. denotes ‘with
probability’.
Experiments
We used FTP bulk data transfer for the TCP traffic in all our experiments.
We conducted simulation studies in NS for:– Assured service for aggregates with different
target rates.– Effect of different RTTs– Effect of different window sizes– Protection from best effort UDP flows– Effect of UDP flows with target rates.
Results
Expt #Rt 1 Rt 2 BE TCP flow Link goodput
Total Marked Total Marked (Mbps) (Mbps)1 1 1 2.85 1.45 3.35 1.97 2.94 9.142 1 2 2.93 1.76 3.6 2.7 2.64 9.173 1 3 2.93 2.08 4.08 3.44 2.2 9.214 1 4 2.93 2.21 4.29 3.84 1.93 9.155 1 5 2.8 2.32 4.89 4.64 1.51 9.26 2 2 3.4 2.58 3.56 2.73 2.49 9.457 3 3 3.75 3.34 3.53 3.08 1.85 9.138 4 4 3.88 3.7 3.94 3.7 1.31 9.139 5 5 4.38 4.38 4.35 4.35 0.42 9.15
10 6 6 4.35 4.35 4.5 4.5 0.34 9.199.192 Average link utilization = 92% (approx.)
Ra1 Ra2 Target Rates (Mbps) Achieved Rates (Mbps)
Achieved Rates (Ra) for different Target Rates (Rt).
Results….
RTT (ms) Ra 1 Ra 2
60 1.82 3.81 5.6380 1.49 3.74 5.23
100 1.52 3.52 5.04120 1.38 3.58 4.96140 1.43 3.45 4.88
25.74
Achieved Rates ( Mbps)
Total link goodput
per source pair goodput(Mbps)
Achieved Rates (Ra) for different RTT values
window size(KB ) Without MBM With MBMAchieved Rates Achieved Rates Ra (Mbps) Ra (Mbps)
384 0.58 1.88768 3.1 3.06
1125 3.21 2.871536 2.76 3.071920 1.25 2.93
13.81Total Link utilization 10.90
Achieved Rates (Ra) for different window sizes
More results
Target Rate (Mbps) Rt Ra(udp_be) Ra(tcp_be)
Total Marked2 3.83 2.03 2.95 2.64 4.85 4.13 2.91 1.666 5.76 5.6 2.84 0.818 7.13 7.13 2.22 0.04
10 7.94 7.94 1.4 0
Achieved Rates (Mbps) Ra(tcp_prio)
Achieved Rates in presence of BE UDP and TCP
Target Rate (Mbps)Ra(udp_prio) Ra(tcp_be)
Total Marked2 3.73 1.83 2.98 2.634 4.73 4.04 2.98 1.646 5.66 5.58 2.98 0.738 6.08 6.08 2.98 0.32
Achieved Rates (Mbps) Ra(tcp_prio)
Achieved Rates in presence of AS UDP and BE TCP
Inference
MBM– Achieves transparency from the end hosts, simplicity, and
least sensitivity to parameters of both TCP as well as its own parameters.
– helps in achieving the target rate, with a better fairness in terms of sharing the excess bandwidth among flows.
– provides the TCP flows, a greater degree of insulation
from differences in RTT and window sizes.– The overall link utilization also seems to be much better.
Future work
Working on a 3 colour marker, Memory-Based Three color Marker (MBTCM) which is apt for DiffServ with AF per hop behaviour in its core.
Study of TCP dynamics and its performance improvements over broadband networks.
Related Links…..
http://www.comp.nus.edu.sg/~srijith/cir/papers.html
http://www.comp.nus.edu.sg/~kaleelaz