Post on 23-Jan-2016
description
May 14, 2003 1
TCP Veno: TCP Enhancement foTCP Veno: TCP Enhancement for Transmission Overr Transmission Over
Wireless Access NetworksWireless Access Networks
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS,
VOL. 21, NO. 2, FEBRUARY 2003
Speaker : Chen YoChuan
May 14, 2003 2
OutlineOutline
• Introduction– TCP Reno, TCP Vegas
• TCP Veno algorithm
• Performance Evaluation of TCP Veno
• Concluding Remarks and Future Works
May 14, 2003 3
IntroductionIntroduction
• Wireless communication has been making significant progress– Usually using wired backbone networks– Many applications on the networks run TCP/IP
• Transmission control protocol (TCP)– a reliable connection-oriented protocol– Implement flow control (sliding window)
• TCP Reno is most popular in real network– Include SS, CA, Fast retransmission… algorithm
May 14, 2003 4
IntroductionIntroduction
• Reno treats the occurrence of packet loss as a manifestation of network congestion
• In wireless environment, packet loss is often induced by noise, link error…
• To tackle this problem, 2 parts of solution– How to distinguish between random loss and congesti
on loss?– How to make use of that information to refine the con
gestion-window adjustment process in Reno?
• TCP Veno (modify Vegas & Reno)
May 14, 2003 5
Relative workRelative work
• TCP Reno
• TCP Vegas
May 14, 2003 6
TCP RenoTCP Reno
• Sliding windows• Slow start and congestion avoidance algorithms• Fast retransmit and fast recovery
May 14, 2003 7
TCP RenoTCP Reno
• AIMD (Additive Increase and Multiplicative Decrease) algorithm
• 2 adjustment phases– Traffic load is steady or decreasing
• The internal traffic increases linearly
– Congestion signal is received• When 3 duplicate acks or retransmit timer timeout• Algorithm decreases the window size by half
May 14, 2003 8
TCP RenoTCP Reno
• The Rough Evolution of TCP Reno
May 14, 2003 9
TCP RenoTCP Reno• Slow start
– initiated at the start of a TCP connection– initiated after a retransmission timeout
• Slow start threshold – If cwnd is larger than ssthresh, cwnd is linear growth
May 14, 2003 10
TCP RenoTCP Reno
• Fast retransmit & fast recovery
May 14, 2003 11
TCP Reno TCP Reno --end--end
• Round trip time (RTT)
• Retransmit Time Out (RTO)– Too small, TCP will retransmit segments unne
cessarily– Too large, actual throughput will be low
• SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)• RTO = min[UPBOUND, max[LBOUND,(BETA*SRTT)] ]
• Reno conclusion
May 14, 2003 12
TCP VegasTCP Vegas
• Basic ideas– Before packet loss occurs, detect the early
stage of congestion in the routers between source and destination
– Additively decrease the sending rate when incipient congestion is detected
May 14, 2003 13
TCP VegasTCP Vegas
• Expected = cwnd/BaseRTT
• Actual = cwnd/RTT
• DIFF = (Expected-Actual)BaseRTT :the minimum of all measured RTTif ( DIFF*BaseRTT < α )
cwnd = cwmd + 1else if ( DIFF*BaseRTT > β )
cwnd = cwnd – 1else cwnd = cwnd
RTT:the actual round-trip time of a tagged packet
α and β are constant values that be set by experimentation
May 14, 2003 14
TCP VegasTCP Vegas
• Vegas main idea – Maintain the extra data (queue size) in the bot
tleneck router buffer to be between the lower threshold (α) and upper threshold (β)
– To reach high throughput– Avoid packet overflow
RTT = BaseRTT + N/μf
N = cwnd *( 1- BaseRTT/RTT) = DIFF*BaseRTT.μf *RTT = μf * BaseRTT + Ncwnd = BDP + N
μf = cwnd/RTT
May 14, 2003 15
TCP VegasTCP Vegas
• New Retransmission Mechanism– decreases cwnd multiplicatively using a factor
of ¾ rather than Reno’s ½
• On receiving a duplicate ack– Vegas resends the corresponding segment if t
he segment timer has expired– Without having to wait for n (3) duplicate acks
as in Reno
May 14, 2003 16
TCP VegasTCP Vegas
• Modified Slow Start– Try to find the correct window size without
incurring a loss– exponentially increasing its window every
other RTT and using the other RTT to calculate DIFF
– As soon as Vegas detects queue buildup during slow start, it transitions to congestion avoidance
May 14, 2003 17
TCP VegasTCP Vegas
• Problem with TCP Vegas– Asymmetry– Rerouting problem – Persistent congestion
May 14, 2003 18
TCP Veno algorithmTCP Veno algorithm
• Distinguishing between congestive & non-congestive (random) states
• Using N as an indication of whether the connection is in a congestive state
• N<β when packet loss is detected– Veno assume that loss is random
• N>=β when packet loss is detected– Veno assume that loss is congestion
May 14, 2003 19
TCP Veno algorithmTCP Veno algorithm
• In Vegas, BaseRTT is continually updated throughout the TCP connection– with the min RTT collected so far
• In this paper, BaseRTT is reset whenever packet loss is detected– either due to time-out or duplicate ACKs
• To avoid BaseRTT change from time to time
May 14, 2003 20
TCP Veno algorithmTCP Veno algorithm
• Congestion Control Based on Connection State
• Slow start algorithm (cwnd<sstresh)– Employ the same algorithm as Reno
• Additive increase algorithm (cwnd>sstresh)– Specifically, cwnd will be increased by 1 after
each RTT– cwnd is set to cwnd+1/cwnd
May 14, 2003 21
TCP Veno algorithmTCP Veno algorithm
• Additive increase algorithm
• Goal : let connection can stay in operating region longer
if ( DIFF*BaseRTT < β ) // available bandwidth under-utilizedcwnd=cwnd+1/cwnd when every new ack received
else if (DIFF*BaseRTT ≥ β ) // available bandwidth fully utilizedcwnd=cwnd+1/cwnd when every other new ack received
May 14, 2003 22
TCP Veno algorithmTCP Veno algorithm
May 14, 2003 23
TCP Veno algorithmTCP Veno algorithm
May 14, 2003 24
TCP Veno algorithmTCP Veno algorithm• Multiplicative decrease algorithm
1) Retransmit the missing packetset ssthresh = cwnd/2set cwnd= ssthresh+3
2) Each time another dup ACK arrives, increment cwnd by one packet.3) When the next ACK acknowledging new data arrives, set cwnd to ssthresh (value in step 1)
Reno Fast recoveryReno Fast recovery
if (DIFF*BaseRTT < β) //random loss due to bit errors is most //likely to have occurred
ssthresh = cwndloss * (4/5);else if
ssthresh = cwndloss /2 ; // congestive loss is most //likely to have occurred
Veno modify step (1) of Reno Veno modify step (1) of Reno
½~1More than ¾is better
May 14, 2003 25
TCP Veno algorithmTCP Veno algorithmVeno reduce window by 1/5
Detail is later
May 14, 2003 26
TCP Veno algorithmTCP Veno algorithmReno reduce window by 1/2
Detail is later
May 14, 2003 27
TCP Veno algorithm TCP Veno algorithm --end--end
• In summary, veno only refines the additive increase , multiplicative decrease (AIMD)
• All other parts of Reno remain intack– Including slow start, fast retransmit, fast recov
ery, computation of retransmission timeout algorithm
May 14, 2003 28
Performance evaluation of Performance evaluation of TCP VenoTCP Veno1. Verification of packet loss distinguishing
scheme in Venoa. Experimental Network setupb. The verification of packet loss distinguishing
scheme
2. Single connection experiments3. Experiment involving multiple co-existing
connections4. Live internet measurements
OutlineOutline
May 14, 2003 29
Performance evaluation of Performance evaluation of TCP VenoTCP Veno• Two experiments
1. Packet loss artificially induced,
2. On real wireless network where random packet loss actually occurs
Network setupNetwork setup
May 14, 2003 30
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
Src1,Src2 : TCP sendersthat run TCP Reno or Veno over NetBSD1.1Dst1,Dst2 : TCP receivers with Red Hat Linux installedRouter : drop-tail router with (FIFO) queues is set up using FreeBSD4.2Bf : forward buffer, Br : backward bufferμf : forward bandwidth, μr : reverse bandwidthτf : forward propagation delay, τr : reverse propagation delayDifferent random packet loss rates can also be artificially inducedusing the embedded system command in FreeBSD4.2
Random loss isartificially induced
in router
Network setupNetwork setup
May 14, 2003 31
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
Random loss actually occurs
in the wireless link
WC1 : wireless clientSrc2 : Veno sourceTCP connection : Src2 WC1UDP connection : Src1Dst1( provide the background traffic)TCPsuit : Tool developed by author, to infer
1.packet loss due to buffer overflow2.packet loss due to wireless link
Network setupNetwork setup
May 14, 2003 32
Performance evaluation of Performance evaluation of TCPTCP1. Single TCP Veno connection without bac
kground traffic
2. Background traffic is provided by a UDP
Configuration
forward buffer μf = μr = 1.6 MB/s backward buffer Bf = Br = 12
Round-trip time between WC1 and Src2 = 60 ms
12 MB file was transferred between WC1 and Src2
in each Veno’s test
Verification of Packet Loss Verification of Packet Loss Distinguishing SchemeDistinguishing Scheme
May 14, 2003 33
Performance evaluation of Performance evaluation of TCPTCP• First run experiment
– UDP sending rate is 500kb/s– 240 fast retransmits
• 84 non-congestive • 156 in congestive state
– Correct rate in non-congestive 83/84 = 99%– Correct rate in congestive 10/156 = 6.4%, 146 is
misinterpreting • Use Reno’s algorithm (worst case)• Misdiagnosis does not bring any throughput improvement
Verification of Packet Loss Verification of Packet Loss Distinguishing SchemeDistinguishing Scheme
May 14, 2003 34
Performance evaluation of Performance evaluation of TCPTCP
Verification of Packet Loss Verification of Packet Loss Distinguishing SchemeDistinguishing Scheme
EFFECTIVENESS OF VENO’S PACKET LOSS DISTINGUISHING SCHEME UNDER DIFFERENT UDP SENDING
RATES
Veno estimate in non-congestive state
Veno estimate in congestion state
May 14, 2003 35
Performance evaluation of Performance evaluation of TCPTCP• Window-halved reductions corresponding t
o these kinds of random loss may be right actions– Because the available bandwidth has been ful
ly utilized in these situations
Verification of Packet Loss Verification of Packet Loss Distinguishing SchemeDistinguishing Scheme
Really ?
May 14, 2003 36
Performance evaluation of Performance evaluation of TCPTCP• Only one of the source-destination pairs is turne
d on• The figure below shows the evolution of the aver
age sending rate– For loss probabilities ranging from 10-4 to 10-1
– buffer size at the router is set to be 12
– link speed μf = μr = 1.6 MB/s
– RTT = 120ms– Maximum segment size is 1460 Byte– Each data point of the sending rate divided by 160 ms
Single connection experimentsSingle connection experiments
May 14, 2003 37
TCP Reno & Veno TCP Reno & Veno Average sending rate for loss probability ranging from 10-4 to 10-1
May 14, 2003 38
Performance evaluation of Performance evaluation of TCPTCP• When the packet loss rate is relatively small
er– The evolutions of Veno and Reno are similar
• But when the loss rate is close to 10-2 packets/s– Veno shows large improvements over Reno
Single connection experimentsSingle connection experiments
May 14, 2003 39
Performance evaluation of Performance evaluation of TCP VenoTCP Veno• One 32-MB file is transferred for each run• Other parameters are the same as the above ex
periment setting
Single connection experimentsSingle connection experiments
TCP Veno (146.5 kB/s) is 80%higher than that of TCP Reno (81.9 kB/s)
Multiplicative decrease algorithm that performs intelligent window adjustmentintelligent window adjustmentbased on the estimated connection state
Veno and Reno operate similarlyby falling back to the slow start algorithm
May 14, 2003 40
• RFC3002 shows that – wireless channel with IS-95 CDMA-based
data service has an error rate of 1%–2%.
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Single connection experimentsSingle connection experiments
May 14, 2003 41
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
• 4 connections consisting of a mixture of Veno and Reno to share a common bottleneck link of 4 Mb/s
• Maximum segment size is 1460 Bytes• Bf = Br = 28• Round-trip propagation time of 120 ms
Multiple Co-existing ConnectionsMultiple Co-existing Connections
May 14, 2003 42
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Multiple Co-existing ConnectionsMultiple Co-existing Connections
• Veno connections exhibit higher throughput than coexisting Reno connections
• Evolution of two Reno connections in (d) is close to that of (c)• Veno does not achieve its superior throughput by aggressively grabbing ba
ndwidth away from Reno• Use the available bandwidth that will be otherwise left unused
May 14, 2003 43
• Conclude : Veno is compatible with Reno
• (d) are roughly the same as those in (b)– Veno connections are not adversely affected
by the random loss rate of 0.01
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Multiple Co-existing ConnectionsMultiple Co-existing Connections
May 14, 2003 44
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Multiple Co-existing ConnectionsMultiple Co-existing Connections
• Throughput for a total of five connections– consisting of a mixture of Reno and Veno connections
• The horizontal axis is the number of Veno connections
May 14, 2003 45
Performance evaluation of Performance evaluation of TCP VenoTCP Veno• From these two graphs, three important observat
ions can be made– Fairness
• All the data points exhibit small standard deviations
– Curves are nearly horizontal• Veno will not starve the bandwidth used by Reno connection
s
– throughput improvement• Veno has somewhat higher throughput than Reno in nonloss
y environments
Multiple Co-existing ConnectionsMultiple Co-existing Connections
May 14, 2003 46
Performance evaluation of Performance evaluation of TCP VenoTCP Veno• The performance over WLAN and wide ar
ea network (WAN)
Live Internet MeasurementsLive Internet Measurements
May 14, 2003 47
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
• The base station and the laptop in different room, distance between them is about 8 m
• Use laptop as a client to download an 8-MB file from the data server
• 10/100 Ethernet switch, RTT=20 ms
Live Internet MeasurementsLive Internet Measurements
in WLAN
May 14, 2003 48
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
• 10 throughput measurements over one day duration• Test over a period of five days• Veno connection is about 336 kb/s, 21% improvement over that of
a Reno connection (about 255 kb/s)• In our latest experiments on 802.11, Veno gets throughput improv
ement of up to 35%
Live Internet MeasurementsLive Internet Measurements
in WLAN
May 14, 2003 49
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Live Internet MeasurementsLive Internet Measurements
in WAN
Veno & Reno
metropolitan WANscross-country WANs
Planning
May 14, 2003 50
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Live Internet MeasurementsLive Internet Measurements
• RTT = 45 ms with 10 ms variation over different time slots• The general trends of the results among the five days are similar• Veno only obtains slightly higher throughput than Reno• Based on the reduced amount of timeouts, fast retransmits, and retr
ansmitted packets– Veno does not “steal” bandwidth from Reno and can coexist
May 14, 2003 51
• RTT = 45 ms with 10 ms variation over different time slots• Veno obtains throughput improvement of up to 41% over Reno in dif
ferent time slots• The numbers of timeouts, fast retransmits triggered, and retransmitt
ed packets are much low in Veno
Performance evaluation of Performance evaluation of TCP VenoTCP Veno Live Internet MeasurementsLive Internet Measurements
May 14, 2003 52
Performance evaluation of Performance evaluation of TCP VenoTCP Veno
• RTT = 290 ms with 30 ms variation among different tests• over cross-country WANs• Generally Veno achieves a much higher throughput than Reno, parti
cularly in metropolitan WAN• But, the improvement is not consistent throughout the day
– perhaps due to variability of other factors in the live Internet itself
Live Internet MeasurementsLive Internet Measurements
May 14, 2003 53
Concluding Remarks and Future Concluding Remarks and Future WorksWorks• TCP Veno can achieve significant improvement
– without adversely affecting other concurrent TCP connections in the same network
• Veno is desirable from the following 3 standpoints1. Deployability2. Compatibility3. Flexibility
• This paper has not addressed the issue of bursty packet loss
– SACK option has been proposed and shown to be effective in dealing with multiple packet losses
– Veno and SACK can be combined easily
May 14, 2003 54
Concluding Remarks and Future Concluding Remarks and Future WorksWorks• Generally speaking, we can see TCP Veno
– borrows the idea of congestion detection scheme in Vegas
– intelligently integrates it into Reno’s additive increase phase
• Future Works– how to refine additive increase at the next step – how much the window is to be reduced once fast retra
nsmit is triggered.– we could also use other predictive congestion detectio
ns
May 14, 2003 55
Ending…Ending…
AuthorAuthor
Cheng Peng FuPh.D. degree in information engineeringChinese University of Hong Kong
He is from Shanghai