Transcript Quality of Service on JANET

JANET QoS Development
Project:
IP Premium and LBE Trials across
JANET
Victor Olifer
UKERNA
Network Development Project Manager
8 June 2005
TNC2005
Agenda
•
•
•
•
•
•
JANET QoS Project history
Test plan
Test results
Phase 1 recommendations
Phase 2 objectives and structure
QoS models to be explored
8 June 2005
TNC2005
QoS on JANET
• JANET is a multi-domain, hierarchical network
– Backbone (SuperJANET)
– Regional Networks (RBCs, RNOs)
– Site Networks (LEAs, Universities, Colleges, Schools etc)
• Increasing volume of traffic leads to an
increased probability of congestion
– This could impact real-time services such as VoIP,
Videoconferencing and Content Delivery over JANET
• The JANET QoS Development Project was
established to address these challenges
8 June 2005
TNC2005
JANET QoS Development
Project
• Work in the QoS area commenced in 2001, with
the formation of the QoS Think Tank
– QoS Think Tank Report produced (stress on DiffServ)
• JANET QoS Development Project commenced in
2002
– Define the prototype framework and QoS services
– Call for project partners
– Configure backbone and partner networks with QoS
(2003)
– Conduct testing on the production network with real
applications (the first half of 2004)
8 June 2005
TNC2005
Partners and QoS classes
SSDN
All ingress interfaces of BARs have
5% limit for IP Premium (DSCP 46)
Lancaster
IP Premium
(VC, VoIP)
Manches
ter
UKERNA
dev.net
Imperial
Swansea
8 June 2005
TNC2005
Soton
LBE
(Elastic bulky GRID)
Test Highlights
• Aim of testing
– To compare the behaviour of applications when
they are served as BE and non-BE (Premium or
LBE)
• Comparison criteria
– Subjective (observed quality of VC and VoIP
sessions during periods of congestion)
– Objective (RTT, jitter and loss measured by the
monitoring infrastructure deployed)
8 June 2005
TNC2005
Monitoring infrastructure
Manchester
SAA
probe/responder
Applicati
on / Site
Edge
Router
SAA
probe/responder
Collection
Agent
SAA-probe
Imperial
College
SAAresponder
SAA
probe/responder
Key
Probes and responses between SAA
probes and responders
UKERNA
Application
/ Site Edge
Router
Applicatio
n / Site
Edge
Router
Southampton
SAAresponder
Results from SAA probes going to
SQL database
8 June 2005
Applicatio
n / Site
Edge
Router
Reading
Swansea
SQL
Databa
se
Lancaster
Application
/ Site Edge
Router
TNC2005
SAAresponder
Applicatio
n / Site
Edge
Router
An example of a test
scheme
Load1
Loaddestination
Load2
Interface to be
congested
SAAresponder
Router
under test
SAA-probe
(measures
reflected
traffic)
23455
IPERF-client
IPERF-server
Applicationgenerator
CISCO IP PHONE
7940
1
2
ABC
3
messages
5
JKL
directories
i
DEF
services
4
GHI
settings
6
MNO
7
8
9
PQRS
TUV
WXYZ
*
0
#
OPER
CISCO IP PHONE
7940
QoS MIB objects
Hub/switch/router
1
2
ABC
3
messages
5
JKL
directories
i
DEF
services
4
GHI
settings
6
MNO
7
8
9
PQRS
TUV
WXYZ
*
0
#
OPER
Applicationreceiver
(every 1 min)
Database
8 June 2005
Hub/switch/router
TNC2005
Test Results
• In most cases both VC and VoIP traffic benefited
from IP Premium service
• LBE unicast traffic received allocated percent of
bandwidth during BE bursts
• Observed peculiarities:
– POS OC3 interfaces of Cisco 6500: Premium traffic
had increased delays and loss during BE congestion
– LBE + BE multicast traffic (Access GRID) behaviour
was unpredictable – LBE behaved like something
better than BE, audio and video sessions failed
8 June 2005
TNC2005
IP Premium UKERNA – Manchester test, 16th March 2004
Preliminary trial of RUDE
without VC session
8 June 2005
VC is served as BE, VoIP
as EF, VC got frozen
TNC2005
VC is served as EF, VoIP as EF,
no degradation of both.
LBE Southampton – Imperial test, 9th March 2004
BE
traffic
LBE
traffic
8 June 2005
TNC2005
Explored window of QoS
benefits
Average
transmission
delay
Almost regular
traffic
Overpovisioned
area
Very bursty
traffic
Voice & video
tolerance
Fixed delay
(signal
propagation
etc)
Utilisation
10%-20%
50%
8 June 2005
TNC2005
80%-90%
100%
JANET QoS Development Project Phase 2
• Recommendations of Phase 1 participants:
–
–
–
–
QoS benefits were noticeable, it works!
Establish Phase 2
Define production QoS Service Model for JANET
Conduct large scale piloting activities
• Some technical areas need to be further
investigated
• Guidance documentation requirements
• We should keep pace with GEANT2
8 June 2005
TNC2005
JANET QoS Development Project Phase 2
(2005- 2007)
QoS Architecture Group
Interworking
with other
technologies:
IPv6, Multicast,
Firewalls
8 June 2005
Low
Bandwidth
Connections:
new partners
among FE
Policy
&
Management
TNC2005
Monitoring
and
Management
Applications
requirements
Types of DiffServ models,
to be explored in Phase 2
Factors:
– Destination awareness
– Static vs. dynamic reservations
– Trust relationships between domains
8 June 2005
TNC2005
Static destination-unaware DifferServ
model
No reservation for flows!
Each domain is responsible for
proper processing of QoS classes
(aggregates)
Domain G
ISP
Domain J
(SuperJANET,
National
Backbone
(GEANT,
Pan-European
Backbone
Network)
Network)
Domain B
(Regional
R2
Network)
R1
Domain A
(Campus
Network)
User
A1
8 June 2005
- Neighbouring domains conclude
SLA to
Domain E
(Regional
process traffic classes in similar
manner
Network)
and according common marking, so called
DSCP values (e.g. 46 for Premium)
Domain C
- Only(Campus
edge routers of domain do
network)
admission control and traffic policing:
to protect domain formUser
excess
of
C1
privileged traffic
TNC2005
Domain F
(Campus
Network)
User F1
Pros and cons of static destinationunaware DiffServ model
•
•
•
•
Scalability – excellent!
Flexibility – excellent!
Maintainability - excellent!
Guarantees – poor
– Clash of flows in some output interface is allowed
(flows’ routes are not under control)
– Reasonable hierarchical design of a network
decreases the clash probability
8 June 2005
TNC2005
Applications of static DiffServ model
• A few well-known sources of IP
Premium traffic (e.g. VC studios) which
are allowed to communicate only with
each other
• Restriction of a number of egress flows
from origin domain at application level:
– E.g. by VoIP gatekeepers
8 June 2005
TNC2005
Dynamic destination-aware DiffServ with
Bandwidth Brokering
BA-G
BA-J
Domain G
ISP
Domain J
(GEANT,
Pan-European
Backbone
(SuperJANET,
National
Backbone
Network)
Network)
-Admission control
-- Traffic policing
BA-B
Domain B
(Regional
Network)
R2
1. Check of total throughput
BA-E
Domain E
(Regional
Network)
-Admission control
-- Traffic policing
2. Configure admission control
to pass
a flow routers
BA-A
•Relieve
BA-C
from
counting and storing state information
Domain A
C
•BandwidthDomain
Brokers
(BBs) do this job for routers
(Campus Network)
(Campus network)
•Hybrid of IntServ and pure DiffServ
Domain F
(Campus Network)
-Admission control
-- Traffic policing
•Very new – GEANT2 is going to deploy it in next 4 years
8 June 2005
•Needs re-configuring ofTNC2005
policers for every flow – not scalable
for high-level domains
The same + trust relationships between
domains
BA-G
BA-J
Domain G
ISP
Domain J
(SuperJANET,
National
Backbone
(GEANT,
Pan-European
Backbone
Network)
Network)
BA-B
BA-E
Domain B
(Regional
Domain E
Network)
(Regional
Network)
BA-C
BA-A
Domain A
•Reconfiguring
Domain C of policers and admission control tools happen
Domain F
only in(Campus
originnetwork)
domain – good scalability
(Campus Network)
(Campus Network)
•Additional risk of misconfiguring devices within low-level
domains
- Admission control
- Traffic policing
8 June 2005
TNC2005
Applications of dynamic destinationaware DiffServ model
• Effective for long-lived flows, e.g. VC
• Non-effective for short-lived flows, e.g.
VoIP conversations
8 June 2005
TNC2005
A combination of static and dynamic
DiffServ models is possible…
• However it needs different DSCP for
marking static and dynamic flows
8 June 2005
TNC2005
Further Information:
JANET QoS Development www.ja.net/development/qos
Project Manager: Victor Olifer, [email protected]
Any questions?
8 June 2005
TNC2005