Transcript Network AssessmentResults Analysis

Question
Latency = 100ms
Network conditions
Minimum
quality
Optimal
quality
Inter-arrival Packet Jitter (average)
≤ 5 ms
≤ 2 ms
Inter-arrival Packet Jitter (maximum)
≤ 40 ms
≤ 20 ms
Packet Loss Rate (average)
≤ 1%
≤ 0.5%
Network Latency
≤ 100 ms
≤ 50 ms
So, 100ms latency would be bad?
Not necessarily. Context is key!
Monitor end-to-end quality metrics that track end-user experience
Classified Poor Call-based reports like the Media Quality Summary Report
Discussion of metrics centered around how much impairment the Lync stack and absorb
Monitor Packet loss, jitter, latency metrics using low thresholds (<1% average loss, <3ms average jitter,
“speed of light” + 2x jitter for latency)
Scope monitoring to “Managed Infrastructure” and fix “bugs” in the infrastructure
Use user education and end-user diagnostic tools to drive down the rest of the poor calls
Two types: one-way and round trip (RTT); latter is easier to measure and therefore used in the most
places
Typically, discussion revolves around what latency levels are acceptable
Instead let us focus on sources of latency
Stack latency (capture/framing/codec) – there is not much the admin can control here
Jitter buffering latency – amount proportional to amount of packet loss and jitter; good network endto-end equals low latency
Network propagation latency (sum of latency across each hop) – huge latencies are often caused by one
bad network leg
This is a sign that a real problem exists
Have the expectation of latency, such as speed of light x distance + minimal overhead
On managed networks, there should be almost 0 loss and very little jitter
The media stack has state of the art technology to recover from loss and jitter so
values outside optimal range may not be noticeable. But, address these issues anyway
and you will still improve quality (with lower bandwidth)
On unmanaged networks, there is nothing the user can do other than to avoid making
calls with a bad connection. Use user education and policy to prevent bad calls
Location
BothInside
BothInside
BothInside
BothOutside
BothOutside
BothOutside
Inside-Outside
Inside-Outside
Inside-Outside
Total Sessions
ConnectionType
BothWired
BothWireless
Wired-Wireless
BothWired
BothWireless
Wired-Wireless
BothWired
BothWireless
Wired-Wireless
NumSessions
PoorSessions
74682
7072
23080
4572
9254
9429
14329
10356
70236
223,010
% poor
442
437
1202
687
1440
1330
1652
1330
5912
% poor of total
0.6%
0.2%
6.2%
0.2%
5.2%
0.5%
15.0%
0.3%
15.6%
0.6%
14.1%
0.6%
11.5%
0.7%
12.8%
0.6%
8.4%
2.7%
14432
6.47%
Managed Diamond Class Line
India
Consumer Line
The Netherlands
Internet
Unmanaged Line
United Kingdom
Managed Diamond Class Line
The Netherlands
Managed diamond class Line
United States
Managed diamond class Line
United States
MPLS CLoud
Average, minimum,
and maximum
9.7 % average, 4% min, 67 % max means…
3.3 % average, 2 % min, 5.4 % max means…
7.9 % average, 2.4 % min, 39% max means…
Can usually be improved by Quality of Service (QoS)/packet prioritization
Latency is round trip
High latency causes satellite phone calls
Can latency be caused by retransmission of packets?
Cannot always be improved!
Jitter will add to the delay
Can be improved with traffic prioritization
Percentage of “ junk” packets
Arrived too late for Jitter Buffer or are malformed
Narrow-Band MOS
Not used in our reports
Used as an indicator to validate your results
Discovery
Modeling
Simulation
Create a slide for each site that you tested
Call Flows
Bandwidth Usage
Traffic Modelling
Recommended QoS approach
Delay
Packet Loss
Jitter
Sample Report
Sample Report
Update codecs and
bandwidth to reflect
your model
Sample Report
Update codecs to
reflect your model
Sample Report
network conditions
Inter-arrival packet jitter (avg)
unmanaged network
≤ 20ms
managed networks
≤ 5ms
Inter-arrival packet jitter(max)
≤ 80ms
≤ 40ms
Packet loss rate (avg)
≤ 5%
0%
Network latency One-Way
≤ 150ms
≤ 60ms
Sample Report
6000
4000
Zero in ‘steady state’, spikes on slide transitions etc
2000
0
In-built congestion control
Screen size
Acceptable
Optimal
1280x800
384 Kbps
1.5 Mbps
1440x900
512 Kbps
2 Mbps
1680x1050
768 Kbps
2.75 Mbps
1920x1200
1 Mbps
3.5 Mbps
Kilobits/sec sent by Sharer
Sample Report
Background and Our
Recommendations
Network QoS Strategy
Sample Report
Audio
Traffic
Audio
DSCP 46 - Queue
Video
Traffic
Video
DSCP 34 - Queue
Other
Lync
Traffic
Signalling
App Sharing
File Transfer
Unmarked- Queue
Total Available
Bandwidth
Sample Report
Which methodology is the customer choosing?
35
DSCP
Port-based
DSCP + Port
Protocol-based
• GPO to mark traffic
from OCS / Lync
• Trust DSCP marking
from distribution
layer
• Must overcome 3rd
Party applications
re-marking their
traffic with DSCP
• Must overcome
rogue machines
connecting to
network and using
priority queue
overloading for
denial of service
(DoS) attack
• Re-mark based on
port at WAN
Ingress point
• Restrict Media to 40
UDP ports
• Limited risk of
network equipment
upgrades
• Possible issue if
third party
application
randomly chooses
the defined port
range, and is
prioritized
• Mark DSCP using
policies
• Restrict port range
by GPO
• Check DSCP and
Port are correct
• A 3rd Party
application
randomly using the
specific port range
will not be marking
with DSCP
• A third party
marking DSCP will
not be using our
Port range
• Re-mark based on
protocol (SRTP) at
WAN Ingress
• Requires network
equipment to
support deep
packet inspection at
line speed
IP-based
• Re-Mark based on
SRC or DST IP
addresses
• Works for
Centralized PSTN
and Conferencing
traffic (GNOC)
• Does not work for
peer traffic
scenarios
Sample Report
Media type
Per hop behavior
Queuing and
dropping
Notes:
Audio
EF
Priority Queue
Low loss, low latency, low jitter, assured bandwidth
Pair with WAN bandwidth policies on constrained links
Video
AF41
BW Queue + DSCP
WRED
Class 4. Low drop priority.
Pair with WAN bandwidth policies on constrained links
SIP Signaling
CS3
BW Queue
Class 3.
Bandwidth allocation should be sufficient to avoid drops
App Sharing
AF21
BW Queue + DSCP
WRED
Class 2. Low drop priority.
Pair with end user policy caps
File Transfer
AF11
BW Queue + DSCP
WRED
Class 1. Low drop priority.
Pair with end user policy caps
Sample Report
Usage Modeling and Planning
Bandwidth Estimations
Sample Report
Sample Report
Source: Industry accepted recommended maximum
Source: Industry standard
Sample Report
Small site
•
•
•
•
•
Between 50- and 100 Users
3 Users making peer calls
4 Users with Conference Audio
1 User with Conference Video
1 User with Peer Video added
Large site
•
•
•
•
•
Larger than 100 Users
1.5% Users making peer calls
3% Users with Conference Audio
0.5% Users with Conference Video
1% Users with Peer App Sharing
Sample Report
Wan link speeds
Wan link: busy hour average
Max over the last 3 months
Wan link: peak utilization
Max over the last 3 months
Sample Report
Overview and Background of
the Traffic Simulation
Traffic Simulation
Sample Report
Sample Report
Sample Report
Findings and Outcome
Traffic Simulation Results
Sample Report
Four calls between Phoenix and Tucson
Virtually no variation in delay or call quality
Sample Report
Two calls between Leeds and Tucson
Huge variable delay during local working hours
Unloaded link is suitable for UC traffic, but requires some type of WAN QoS implemented to deal with
traffic prioritization
Sample Report
Two concurrent calls simulated
Huge variable delay during local working hours
Sample Report
Region
Region XXX
Region XXX
Region XXX

Bandwidth



Delay



Jitter
average



Jitter(Max)



Sample Report
Even with QoS implemented, some links cannot carry RTC traffic volume required for rollout
Strong recommendation to implement reservation for RTC traffic
Random early detection in combination with RTC can lead to unnecessarily high packet loss
Sample Report