8 June 2005TNC2005 JANET QoS Development Project: IP Premium and LBE Trials across JANET Victor Olifer UKERNA Network Development Project Manager

8 June 2005TNC2005 Agenda JANET QoS Project history Test plan Test results Phase 1 recommendations Phase 2 objectives and structure QoS models to be explored

8 June 2005TNC2005 QoS on JANET 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 JANET is a multi-domain, hierarchical network –Backbone (SuperJANET) –Regional Networks (RBCs, RNOs) –Site Networks (LEAs, Universities, Colleges, Schools etc)

8 June 2005TNC2005 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 2005TNC2005 UKERNA dev.net Manches ter Lancaster Imperial Soton Swansea LBE (Elastic bulky GRID) Partners and QoS classes IP Premium (VC, VoIP) All ingress interfaces of BARs have 5% limit for IP Premium (DSCP 46) SSDN

8 June 2005TNC2005 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 2005TNC2005 UKERNA Manchester Swansea Lancaster Imperial College Southampton Application / Site Edge Router Collection Agent SAA- responder SQL Databa se Key Probes and responses between SAA probes and responders Results from SAA probes going to SQL database Applicatio n / Site Edge Router Reading SAA-probe SAA- responder SAA probe/responder SAA- responder SAA probe/responder Monitoring infrastructure

8 June 2005TNC2005 Router under test Application- generator Application- receiver SAA- responder SAA-probe (measures reflected traffic) IPERF-client IPERF-server Load2 Load1 Load- destination Hub/switch/router Database QoS MIB objects (every 1 min) An example of a test scheme Interface to be congested 23455

8 June 2005TNC2005 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 2005TNC2005 Preliminary trial of RUDE without VC session VC is served as BE, VoIP as EF, VC got frozen VC is served as EF, VoIP as EF, no degradation of both. IP Premium UKERNA – Manchester test, 16 th March 2004

8 June 2005TNC2005 LBE Southampton – Imperial test, 9 th March 2004 BE traffic LBE traffic

8 June 2005TNC % Average transmission delay Utilisation 100% Very bursty traffic Almost regular traffic Fixed delay (signal propagation etc) Explored window of QoS benefits Voice & video tolerance Overpovisioned area 10%-20% 80%-90%

8 June 2005TNC2005 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 2005TNC2005 JANET QoS Development Project Phase 2 ( ) QoS Architecture Group Interworking with other technologies: IPv6, Multicast, Firewalls Low Bandwidth Connections: new partners among FE Policy & Management Monitoring and Management Applications requirements

8 June 2005TNC2005 Types of DiffServ models, to be explored in Phase 2 Factors: –Destination awareness –Static vs. dynamic reservations –Trust relationships between domains

8 June 2005TNC2005 Static destination-unaware DifferServ model Domain B (Regional Network) SLA A-B SLA B-A Domain A (Campus Network) Domain J (SuperJANET, National Backbone Network) Domain F (Campus Network) Domain C (Campus network) ISP Domain G (GEANT, Pan-European Backbone Network) Domain E (Regional Network) SLA B-J SLA J-B User A1 User C1 User F1 R1 R2 - Only edge routers of domain do admission control and traffic policing: to protect domain form excess of privileged traffic - Neighbouring domains conclude SLA to process traffic classes in similar manner and according common marking, so called DSCP values (e.g. 46 for Premium) No reservation for flows! Each domain is responsible for proper processing of QoS classes (aggregates)

8 June 2005TNC2005 Pros and cons of static destination- unaware DiffServ model Pros and cons of static destination- unaware 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 2005TNC2005 Applications of static DiffServ model 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 2005TNC2005 Dynamic destination-aware DiffServ with Bandwidth Brokering -Admission control -- Traffic policing Domain B (Regional Network) BA-A Domain A (Campus Network) -Admission control -- Traffic policing Domain J (SuperJANET, National Backbone Network) Domain F (Campus Network) Domain C (Campus network) ISP Domain G (GEANT, Pan-European Backbone Network) Domain E (Regional Network) SLA B- J SLA J- B BA-E BA-G BA-B BA-J BA-C R2 1. Check of total throughput 2. Configure admission control to pass a flow -Admission control -- Traffic policing Relieve routers from counting and storing state information Bandwidth Brokers (BBs) do this job for routers Hybrid of IntServ and pure DiffServ Very new – GEANT2 is going to deploy it in next 4 years Needs re-configuring of policers for every flow – not scalable for high-level domains

8 June 2005TNC2005 The same + trust relationships between domains Domain B (Regional Network) BA-A Domain A (Campus Network) - Admission control - Traffic policing Domain J (SuperJANET, National Backbone Network) Domain F (Campus Network) Domain C (Campus network) ISP Domain G (GEANT, Pan-European Backbone Network) Domain E (Regional Network) BA-E BA-G BA-B BA-J BA-C trust Reconfiguring of policers and admission control tools happen only in origin domain – good scalability Additional risk of misconfiguring devices within low-level domains

8 June 2005TNC2005 Applications of dynamic destination- aware DiffServ model Applications of dynamic destination- aware DiffServ model Effective for long-lived flows, e.g. VC Non-effective for short-lived flows, e.g. VoIP conversations

8 June 2005TNC2005 A combination of static and dynamic DiffServ models is possible… A combination of static and dynamic DiffServ models is possible… However it needs different DSCP for marking static and dynamic flows

8 June 2005TNC2005 Any questions? Further Information: JANET QoS Development Project Manager: Victor Olifer,