Network performance overview

PERFORMANCE VS. NET SPEED
• You should know your needs then can make sure you on’t spend too much money for performance you
don’t need.
• There are some nonperformance issues that must be considered first:
 Design cost
 Quality(HW)
 Standardization
 Upgradability
 etc.

NETWORK PERFORMANCE
• Aspects:
 QOS
Overall system performance
 QOE
Impact of network behavior on end user or number of happy users
• Aim:
 Prioritize applications , users , data flows
 Guarantee a certain level of performance to a data flow

CONT’D
• Performance charges with all aspects of a connection;
• A connection is affected by:
 Delay
 Loss
 Noise , crosstalk
 Errors
 Jitter
 Attenuation
 Reflection
 etc.

WHY IS MY CONNECTION SLOW, WHY I AM NOT GETTING
THE ACTUAL BANDWIDTH THAT IS ASSIGNED TO ME.

THROUGHPUT
• Maximum RATE of transferred data over the net
• It depends on other terms:
 Network topology
 Client/server process speed
 Time of use
 Other users(in shared networks)
 Weather(in wireless networks)
 Network internal pipeline

NETWORK INTERNAL PIPELINE
• Maximum achievable throughput for a single tcp connection is determined by different factors:
• Maximum bandwidth of the slowest link in the path
• RTT
• Window size(RWIN , tcp receive window , buffering)
• Packet loss
• Congestion
• MSS(maximum segment size)
• BDP(bandwidth delay product)

MSS
• It is the largest amount of data, specified in bytes, that a computer or communication evice can handle
in a single unfragmented piece.

RWIN
• It is buffering used to handle delay in the system(default 64KiB)
• Even if there is no packet loss in the network, windowing can limit throughput

BDP(BANDWIDTH DELAY PRODUCT)
• It refers to the number of bytes to fill tcp path
BDP = bandwidth * RTT

HOW RTT – RWIN – BDP AFFECT THROUGHPUT?
• For example:
Bandwidth=6Mbps
RWIN=64KB
RTT=100ms
Then
BDP=600Kib=75KiB
Finally
64/75 *100 = 85% of 6Mbps = 5.12Mbps = 660-670KBps

PERFORMANCE MEASUREMENT
fundamentals of how network performance metric(latency , PL , throughput) can be calculated

OVERVIEW:
• NETWORK LATENCY INDICATORES
 connection time
in tcp which is 3way handshake(syn,syn/ack,ack), time between syn and ack in the initial tcp session is a good indicator of
network latency
 roundtrip time
• time between a packet containing payload and its corresponding acknowledgment packet , it is a good indicator of round
trip network latency
• sometimes this procedure may get slow because of one end of connection , some systems combine ack responses
together into a single response
• PACKET LOSS INDICATORS
• TROUGHPUT INDICATORS

Rtt calculation:
 filter tcp.analysis.ack_rtt between two ip address to get the round trip statistics using io graph

tcp.nalysis.ack_rtt means time between syn and next packet

PACKET LOSS CALCULATION
• retrnsmissions occur when a packet does not reach the other side and is not acknowledged or when the
acknowledgment takes too much time to reach the initial sender.in both cases, the quality of the
network trasmission will be heavily impacted
• RETRANSMISSION RATE:
 number of retransmission packets compared to the initial packets sent , this rate clearly shows packet loss
 we can filter retransmissions by tcp.analysis.retransmission and specifying ip address of src/dest in io graph
• RETRANSMISSION DELAY:
 time interval between the initial packet sent and the first acknowledged retransmission

you may filter your desired hosts first then select the graph(in general it is whole count of sent data back and forth)

TCP/UDP/HTTP STREAMS DELAY MEASUREMENT

NORMAL DELAY:
• Some delays are normal and does not need calculation:
• delay before TCP RST is normal, maybe user switch another window , it is transparent
• delay before TLS encrypted alert
• Delays before a Periodic Set of Packets in a Connection that is Otherwise Idle

DELAYS THAT SHOULD BE CONSIDERED

DELAY BEFORE SYN/ACK
• the time between the SYN and SYN/ACK in the TCP handshake can be used to determine the round trip
time between the hosts

CONVERSATION TIMESTAMPS
• Wireshark numbers each separate TCP conversation with a TCP Stream Index (tcp.stream) value starting
with 0

• we can look for delays within a specific TCP stream. First we need to enable Wireshark to track time
within separate TCP conversations.

• After you enable the Calculate conversation timestamp preference setting, two additional time fields
will be visible at the end of the TCP header:
 Time since first frame in this TCP stream (tcp.time_relative)
 Time since previous frame in this TCP stream (tcp.time_delta)
• filter syn and syn/ack packets then compare tcp.time_delta
between them to findout RTT in tcp streams.

DELAYS BEFORE A CLIENT COMPLETES THE 3-WAY TCP
HANDSHAKE
• time between the syn/ack and client's ack can be used to findout delay

DELAYS BEFORE A SERVER SENDS A RESPONSE
• client requests, server ack followed quickly, but data flow has delay ,perhaps server is low in processing
or ask another server for info or is under attack

there are some other options which I ignored due to avoid more complexity like:
• Delays before the Next Packet in a Data Stream
• Delays before an ACK from a TCP peer
• Delays before a Window Update

UDP
• UDP is a connectionless transport protocol with a very simple 8-byte header. Unlike TCP, UDP has no
sequencing or acknowledgement capability. To detect delays in a UDP conversation, we can use two
time fields—frame.time_delta and frame.time_delta_displayed. use for example udp and
dns.time;udp is not connection oriented so we measure delays between requests and responses.

• sorted by bps a->b or
add frame.delta_time to columes and sort based on most delayed udp connections

• we can see that two dns esponse is slower than other(here a bit)(maybe dnsserver does not these
names in its cache):

• dns response time in io graph view:

• same but using wireshark's dns.time:

HTTP
• When we measure HTTP response time, we look at the delta time between a service request (such as an
HTTP GET request) and the response (such as an HTTP 200 OK). The HTTP response time field is called
http.time. to measure the time use http.time filter:it calculates time from client request until http data
flow:

• If you disable Allow subdissector to reassemble TCP streams, Wireshark will measure the time from the
HTTP Request and the actual response packet.

• for enable/disable reassembly do as follow:

PRACTICAL QOS/QOE:
ONLINE GAMING

• It takes time for the server to validate user input, so delay occur
• How to solve latency in online gaming?

Three main solutions:
• Prediction
1. Player
2. Opponent
• Time manipulation
1. Time delay
2. Time warp
3. Data compression
• Visual tricks

PREDICTION
PLAYER PREDICTION:
local system renders client's actions immediately without any delay(ie waiting for server to
acknowledge action)

ALGORITHM:
o sample user input
o pack data and send to server
o determine visible objects and game state
o render scene based on local actions receive updates from server and unpack
o correct any discrepancies
o repeat

CON’S
• there is variation between client side prediction and actual server side game response , client makes
adjustments in the game state , server updates client’s state, it could be sudden and cause jitter, so
looses consistency of the game.
• client could use polling interval between rendered local world and the server's update at a later time
instead of immediately rendering the latest update,
• some smoothing algorithms let game progress smoothly to the server world state

PREDICTION
OPPONENT
• the client predicts the behavior of the opponent before the server actually sends them to the client
• client predict opponent path with its last state direction and speed of the move

• movement's range is set by predetermined threshold, if the predicted location goes outside the
threshold, an update for new position will be sent.
• it requires an algorithm extrapolate the location of each client for each frame rendered
• smaller threshold, more fiddle in opponent location prediction

TIME MANIPULATION
DELAY
• there is a delay in processing to equalize latency, it ensures that all clients have the same effective
latency in the game.

TIME MANIPULATION
TIME WARP
• consider a plyer shoots at an opponent at time t0 but by the time message arrives at the server at time
t2,the opponent moved at time t1.then server uses time warp to roll back the events it had processed
since the client provided the input.

TIME MANIPULATION
DATA COMPRESSION
• reducing size of the message sent between a server and a client can reduce latency.
types of compression:
 lossless
 opponent prediction delta compression
 delta compression
 interest management
 peer to peer
 update aggregation

TIME MANIPULATION
VISUAL TRICK
• use animation for movements, for example a boat movement.

Network performance overview

More Related Content

What's hot (20)

Similar to Network performance overview (20)

Recently uploaded (20)

Network performance overview