Technical University of Crete Electronic & Computer Engineering Department TCP Performance over UMTS...
-
date post
22-Dec-2015 -
Category
Documents
-
view
215 -
download
1
Transcript of Technical University of Crete Electronic & Computer Engineering Department TCP Performance over UMTS...
Technical University of CreteElectronic amp Computer Engineering Department
TCP Performance over UMTS Network
Diploma Thesis
by
Smaragdakis Georgios
OUTLINEbull From Mobile Networks to UMTS Revolution
bull UMTS Radio Access Network
bull UMTS Core Network
bull TCPIP
bull Simulation Parameters
bull NS2
bull Our Simulator
bull Results amp Discussion
bull Conclusions amp Future Work
From Mobile Networks to UMTS Revolution (16)
GSM Network
From Mobile Networks to UMTS Revolution (26)
VALUE ADDED Service Platform
From Mobile Networks to UMTS Revolution (36)
GPRS Service
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
OUTLINEbull From Mobile Networks to UMTS Revolution
bull UMTS Radio Access Network
bull UMTS Core Network
bull TCPIP
bull Simulation Parameters
bull NS2
bull Our Simulator
bull Results amp Discussion
bull Conclusions amp Future Work
From Mobile Networks to UMTS Revolution (16)
GSM Network
From Mobile Networks to UMTS Revolution (26)
VALUE ADDED Service Platform
From Mobile Networks to UMTS Revolution (36)
GPRS Service
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (16)
GSM Network
From Mobile Networks to UMTS Revolution (26)
VALUE ADDED Service Platform
From Mobile Networks to UMTS Revolution (36)
GPRS Service
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (26)
VALUE ADDED Service Platform
From Mobile Networks to UMTS Revolution (36)
GPRS Service
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (36)
GPRS Service
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (46)
3GPP R99 Network
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (56)
3GPP R4 Network
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
From Mobile Networks to UMTS Revolution (66)
3GPP R5 Network
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (17)
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (27)
0 20 40 60 80 100 120 140 160 180 200-30
-25
-20
-15
-10
-5
0Path Loss curve
distance (m) between Base Station and Mobile User
Fad
ing
in d
B
bullPath Loss (distance)
bullShadowing
bullDoppler (movement)
bullMultipath Transmission
LOSS due to Solution RAKE receiver
WCDMA Transmission
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (37)
Resource Management
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (47)
Handover
Softer where the User Equipment is connected to two sectors of the same Base Station simultaneously (no delays)
Soft where the User Equipment is connected to two sectors of different Base Stations simultaneously (no delays)
Hard where the User Equipment is connected to only one sector at the time
Algorithm
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (57)
MacrodiversityRNC Changes
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (67)
Power Control
WHY EXAMPLE
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Radio Access Network (77)
Speading Factor GP = Datarate
Chiprate
AssumptionsbullAll the subscribers under the TRX coverage are equally distributed so that they have equal distances to the TRX antennabullThe power level they use is the same and thus the interference they cause is on the same levelbullSubscribers under the TRX use the same base-band bit rate that is the same symbol rates
Number of userscell X asymp NoE
G
b
P
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Core Network (12)
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
UMTS Core Network (22)
end-to-end Services
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (112)
General OSI and OSI for the Internet
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (212)
TRANSMISSION CONTROL PROTOCOL
bull TCP is point-to-point protocol This means that there is always one sender and one receiver It is reliable and in-order in byte stream Multicasting is not possible with TCP as it is
bull TCP is pipelined This means that in TCP there is congestion window size is set
bull In TCP there are send and receive buffers
bull TCP uses full duplex data There exists bi-directional data flow in the same connection Moreover there is a Maximum Segment Size (MSS)
bull TCP is connection-oriented There exist handshaking that is exchange of control messages initiating sender and receiver state before data exchange
bull At last but not least TCP is flow controlled which means that sender will not overwhelm receiver
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (312)
TCP Reliable data transfer and Retransmission
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (412)
TCP Flow Control
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT
This average is an exponential weighted moving average There is an influence of given sample decreases exponentially fast A typical value for x is 0125
Timeout = EstimatedRTT + 4 Deviation
Deviation = (1-x) Deviation + x | SampleRTT ndash EstimatedRTT |
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (512)
TCP Congestion Control
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (612)
TCP Tahoe
bull TCP Tahoe is the oldest version of TCP
bull TCP Tahoe congestion algorithm includes Slow Start and Congestion Avoidance
bull In order to overcome a loss event three timeouts have to be passed This is its main drawback as when a segment is lost the sender side of the application may have to wait a long period of time for the timeout It implements an RTT-based estimation
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (712)
TCP Reno bull TCP Reno except from Slow Start and Congestion
Avoidance includes also Fast Retransmit In Fast retransmit mechanism three duplicate acknowledgements carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur The window adjustment strategy for this early timeout is the same as for the regular timeout and Slow Start is applied
bull The problem however is that the Slow Start is not always efficient especially if the error was purely transient or random in nature and not persistent In such a case the shrinkage of the congestion window is in fact unnecessary and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (812)
TCP NewReno bull TCP NewReno introduces Fast Recovery in conjunction
with Fast Retransmit The idea behind Fast Retransmit is that an ACK is an indication of available channel bandwidth since a segment has been successfully delivered This in turn implies that the congestion window should actually be incremented upon one ACK delivery Then instead of entering Slow Start the sender increases its current congestion window by the threshold number
bull TCP NewRenorsquos Fast Recovery can be effective when there is only one segment drop from a window of data given the fact that NewReno retransmits at most one dropped segment per RTT The problem with the mechanism is that is not optimized for multiple packet drops form a single window and this could negatively impact performance
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (912)
TCP Vegas bull TCP Vegas approaches the problem of congestion from another
perspective The basic idea is to detect congestion in the routers between source and destination before packet loss occurs and lower the rate linearly when this imminent packet loss is detected The longer the round-trip times of the packets the greater the congestion in the routers Every two round trips delays the following quantity is computed
ρ = (WindowSizeCurrent - WindowSizeOld) (RTTCurrent-RTTOld)
If ρgt0 the window size is decreased by 18 Else the window size is increased by one minimum segment size
bull One problem that it does not seem to overcome is the path asymmetry The sender makes decisions based on the RTT measurements which however might not accurately indicate the congestion level of the forward path Furthermore packet drops caused by retransmission deficiencies or fading channels may trigger a Slow Start
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (1012)
TCP SACK
bull TCP Selective Acknowledgements (SACK) is a TCP enhancement which allows receivers to specify precisely which segments have been received even in the presence of packet loss TCP SACK is an Internet Engineering Task Force (IETF) proposed standard which is implemented for most major operating systems
bull SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster and more efficiently On the contrary TCP Reno and New-Reno can retransmit only one lost packet per round-trip time because they use cumulative acknowledgements
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (1112)
R
SW gt
R
SRTT
Latency
If Then Latency = 2 RTT + OR
Else
Latency = 2RTT + OR + (K-1) [SR + RTT - RS
W ] +
Where K =
)1(log 2 S
O
Error adds Latency
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
TCPIP (1212)
Discussion
Even todayrsquos wired internet has so many problems that some people persist to call it the World Wide Wait These problems will enlarge in the future Mobile
Internet Although TCP was introduced years ago on the wired internet it will continue to be THE transfer
protocol Its hard defensive behavior towards any kind of loss will be its weakest point over wireless and
mobile networks TCP can not infer if an error is due to traffic congestion or losses over a wireless link Our
approach to this problem is to find the proper version of TCP to each profile of application and user over the
UMTS network Notice that the UMTS network is implemented using TCP and end-to-end QoS
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (16)
PARAMETER VALUE
Number of cells 7 (hexagonal)
Cell Side 200m
Path loss propagation exponent β 35
Path loss propagation parameter A ndash30dB
Shadowing parameter σ 4dB
Number of oscillators (Jakes) 8
Number of multipath rays 5
Noise -132 dbW
Doppler frequency 062080 Hz
Chip rate 384 Mcps
PC frequency 1500 Hz
PC power range 80dB
PC step 05 dB
PC SIR objective 25 to 3 dB
PC loop delay 123410
Maximum TX Power -16 dBW
Packet length(MTU) 1000 bytes
NETWORK PARAMETERS
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (26)
Users with 120 Kbps bit rate
Spreading Factor = 32
Approximately 16 users per cell (with one TRX per cell)
Approximately 110 users total
Approximately 330 users total if there are 3 TRX per cell
Performance is declined rapidly if total users gt 160
RTT asymp 120 msecs(but can be increased)
Spreading Factor = 64
Approximately 8 users per cell (with one TRX per cell)
Approximately 55 users total
Approximately 160 users total if there are 3 TRX per cell
Performance is declined rapidly ifTotal users gt 100
RTT asymp 80 msecs(but can be increased)
Users with 240 Kbps bit rate
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (36)
Error Statistics over UMTS (WCDMA) air interface
Let X(i) = E if the block I is in error (which occurs with probability Pe(i)) and C if it is correct For an ergodic process X(i) we have
P[burst length k] = P[X(t)=Et=2hellipk|X(0)=CX(1)=E]
= ])1()0([
]1)()0([
EXCXP
ktEtXCXP
The above model can be described by a Two-State Markov error model as shown in the following Figure
The model is fully characterized by its transition matrix
EEEC
CECC
pp
ppP =
ECCE
CE
Pp
p
P(E) =
and
P[burst lengthgt1] = P[E|E] = pEE ]1[
][
khburstlengtp
khburstlengtpP(E|E) = pEE =
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (46)
Error Statistics over UMTS (WCDMA) air interface
Simple as it is the two-state Markov Model does not capture all types of behavior An obvious way to get around this problem is use a multistate Markov Model We therefore further restrict ourselves to a three-state model such as the one shown in the next figure
Two error states are now present and the second of them E2 can only be entered from the first E1 Also exiting E2 necessarily leads to the Correct State (not to E1) The transmission matrix for such a model is as follows
222
121
1
0
0
0
pp
pp
pp
C
C
CCC
P =
And P[E]=P[E1]+P[E2]=a0
P[burst lengthgt1]=p12= a1
]1[
]2[
hburstlengtp
hburstlengtp=p22 = a2
Finally P(C)=P(E1)pC1 where
pC1= )1())(1(
)1()(
1222
22
ppEP
pEP
P(E1)= )1(
)1()(
1222
22
pp
pEP
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (56)
bullThe results in the first plot for slow fading show that most users will see independent errors since power control equalizes SIR so well that all randomness due to fading and interference is absorbed Also the fading randomness equalizes performance across most users since all will essentially see the same average This behavior resembles the behavior observed in the two-state Markov model
bullAs expected as fading rate increases everything gets more mixed but a similar qualitative trend can still be observed Note that a positive burst correlation can be observed ie P[E|E] asymp P[burstgt1]gtP[E] in most cases for values of the Doppler up to 20Hz This indicates that the system tends to stay in the bad state ie errors tend to be clustered which is intuitive pleasing since the channel has memory This resembles to the behavior observed in the three-state Markov model
bullOn the other hand for fast fading the opposite is observed ie the system tends to escape from error states This can be explained by noting that the power control tends to increase the transmitted power when an error is observed while at the same time the dynamics of the channel tend to make the channel exit quickly from bad conditions so that right after an error the probability that a transmission is successful is higher than average We refer to this case in which errors tend to occur isolated as the case of ldquoanticorrelatedrdquo errors This resemble the behavior observed in the two-state Markov model
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Simulation Parameters (66)
TCP Improvements Proposed for 3G
bull Large Window Size (Sender and Receiver)bull Increased Initial Window (Sender) The initial CWND must
be
equal to min ( 4 MSS max ( 2 MSS 4380 bytes )) bull Limited Transmit (Sender)bull IP larger than Default
576bytes (min IP compatible) lt MTU lt 1500bytes
Typical 1000 bytes (121000 bytes = only 12 overhead)bull MTU Discovery (Sender and Intermediate Routers)bull Explicit Congestion Notification activated (Sender
Receiver Routers) for congestion avoidance
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
NS 2 (12)
bull In order not to ldquoreinvent the wheelrdquo as base for our simulations we use the widely used Network Simulator (NS) version 2 (21b9)
bull NS2 is THE Network Simulator widely used from the network community providing procedures for all versions of TCP and TCP applications
bull It is an object-oriented discrete event driven network simulator developed at Lawrence Laboratories - UC Berkely (maintained by Information System Institute-ISI) written in C++ and OTcl and running in the UNIX operating system
bull All simulation results can be viewed by the Network Animator (NAM) which is a simulation display tool
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
NS 2 (22)
How it works
Node 1
Node 2
Agent (TCP)
Applications
Agent (TCP)
Sink
By observing the intermediate nodes or edge nodes we can examine the behavior of the network and applications Statistics can also be taken
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Our Simulator (15)
By monitoring the intermediate and edge nodes NS provides specific output format By using pattern recognition tools awk and cat we can determine the number of packets sent and correctly acked end-to-end
With NAM tool we can have a visible representation of topology and behavior of our simulations
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Our Simulator (25)
General Topology of our Simulations
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Our Simulator (35)
More Specifications
We use three TCP Applications FTP Telnet and HTTP
bullFTP Poisson Request adapted per user
bullTelnet Poisson Request adapted per user
bullHTTP HTTP11 with Proxy functionalitiesInter-page interval exponential (mean duration) 1 secondNumber of Page (mean duration) 4Inter object interval exponential (mean duration) 001 secondNumber of packets per object Pareto distributed shape 12 and scale 10
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Our Simulator (45)
We examine TCP Performance Energy Consumption and Application Efficiency for users with 120 and 240 kbps
bull for each version of TCP
bull for Doppler 6 20 and 80 Hz
bull Duration of simulation 600 seconds
bull TCP Performance ( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsCorrectlyAcked TCP Tahoe
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Our Simulator (55)
( _ )
( _ )
TotalPacketsSent TCP Version
TotalPacketsSent TCP Version no errors
bull TCP Energy Consumption
(or Resource Consumption
including Power(WCDMA)
CPURAM)
bull Efficiency of TCP Applications
(literature has shown that this
factor is load independent)
( _ )
( _ )
TotalPacketsCorrectlyAcked TCP Version
TotalPacketsSent TCP Version
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (114)
TCP Vegas outperforms only when load is light
If number of users gt 30TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (214)
TCP Vegas outperforms only when load is light
If number of users gt 50TCP SACK outperforms And TCP New Reno follows
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (314)
TCP Vegas outperforms only when load is very light
If number of users gt 20TCP SACK and TCP New Reno share the same performance
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases when the difference is obvious
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (414)
bull TCP Vegas outperforms when load is light
bull When the load is not very light TCP SACK outperforms TCP New Reno and all the other TCP versions follows
bull If Doppler is equal to 80Hz TCP New Reno share the same performance as TCP SACK
bull In all cases TCP SACK consumes less energy than any other TCP version
FTP Application
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (514)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (614)
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
TCP Vegas outperforms all TCP Versions
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (714)
TCP Vegas outperforms all TCP Versions
TCP SACK outperforms slightlyIn all cases and especially as numberof users increases
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (814)
bull TCP Vegas outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
Telnet Application
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (914)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (1014)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (1114)
TCP HTTP outperforms and TCP New Reno follows
TCP SACK outperforms in all cases and especially as numberof users increases
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (1214)
bull TCP SACK outperforms in all cases
bull In all cases TCP SACK consumes less energy than any other TCP version
HTTP Application
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (1314)
Statement for users with 240 Kbps bit rate
In the case of 240Kbps users we noticed the same behavior with 120Kbps link capacity in all applications
and similar results about energy consumption have been observed The only difference worth mentioning is that in the case of 240Kbps in HTTP application TCP
SACK still outperforms the others but to a smaller extend than before
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Results and Discussion (1414)
Doppler (in Hz)TCP Type BitRateUser (Kbps) Application 6 20 80
TCP (Tahoe) 120 FTP 080 040 026TCP Reno 120 FTP 085 041 026
TCP NewReno 120 FTP 087 044 027TCP Vegas 120 FTP 083 042 023TCP SACK 120 FTP 088 045 028TCP (Tahoe) 120 Telnet 096 094 092TCP Reno 120 Telnet 097 095 093
TCP NewReno 120 Telnet 097 095 093TCP Vegas 120 Telnet 097 096 093TCP SACK 120 Telnet 097 096 093TCP (Tahoe) 120 HTTP 093 070 050TCP Reno 120 HTTP 092 071 052
TCP NewReno 120 HTTP 093 072 053TCP Vegas 120 HTTP 090 070 050TCP SACK 120 HTTP 095 075 055TCP (Tahoe) 240 FTP 076 037 024TCP Reno 240 FTP 08 038 024
TCP NewReno 240 FTP 08 037 025TCP Vegas 240 FTP 077 037 021TCP SACK 240 FTP 082 040 028TCP (Tahoe) 240 Telnet 095 094 092TCP Reno 240 Telnet 097 095 092
TCP NewReno 240 Telnet 096 095 093TCP Vegas 240 Telnet 097 095 093TCP SACK 240 Telnet 097 096 092TCP (Tahoe) 240 HTTP 088 069 048TCP Reno 240 HTTP 090 071 050
TCP NewReno 240 HTTP 091 072 050TCP Vegas 240 HTTP 085 068 044
Application Efficiency
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Conclusions amp Future Work (13)
bull There is not a TCP Version that outperforms all the other in all
cases however TCP SACK outperforms all the other TCP
Version in Energy Consumption
bull More than 75 of UMTS load will be HTTP load In HTTP
Application TCP SACK outperforms all the other TCP Versions
bull Most of Operating Systems use only one type of TCP
UMTS must support TCP SACK (or TCP New Reno if
TCP SACK can not be used) If more TCP versions can be
used TCP Vegas will be suitable for special applications
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Conclusions amp Future Work (23)
An IETF Draft published in August is in clear agreement with the results of our Thesis
IETF Draft (draft-ietf-pilc-25g3g)
ldquoTCP over 25G3G SHOULD support SACK In the absence of SACK feature the TCP should use New
Renordquo
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip
Conclusions amp Future Work (33)
Future Work
Future Real Time Application Protocols will use TCP not only
for control data but also for information delivery This protocols
can be used over UMTS If the traffic of this TCP Application
can be modeled then we can select the best TCP version
THE END
QUESTIONS if anyhellip