IST IP NOBEL Next generation Optical network for Broadband European Leadership

1. IST IP NOBEL Next generation Optical network for Broadband European Leadership A revision of the QoS principles April 11th 2005 Antonio J. Elizondo (ajea@tid.es) Telefónica I+D

2. Internet was designed for survivability… • The original Internet was designed for military survivability. • In this way, the Internet was supposed to be unreliable in nature • applications running on either end had to be prepared to recognize data loss, retransmitting data as many times as necessary to achieve its ultimate delivery. • This principle of unreliable delivery means that the Internet only makes a Best Effort attempt to deliver packets: • the network can drop a packet without any notification to sender or receiver. • With the fast success and exponential growth that Internet had, the idea of extending packet switching protocols to support Integrated Services within a single network infrastructure soon arose • audio, video, real-time, and classical data traffic

3. …but QoS could not be guaranteed with the original Internet model • The IETF Integrated Services (IntServ) Working Group • with the goal of expanding the Internet service model to better meet the QoS necessities of these diverse applications • proceeded to specify this enhanced service model • and then to define and standardize certain interfaces and requirements necessary to implement the new service model. • However, the IntServ model soon showed its lack of scalability, mainly due to: • Resources reservation per flow had to be done across the whole end-to-end path. • Identification of flows in all the nodes had to be performed. • Application of personalised scheduling per flow had to be done.

4. A more scalable architecture was proposed for supporting QoS • The IETF Differentiated Services (DiffServ) Working Group • designed a new model with the philosophy of having • a simple and scalable core • intelligence shifted to the edges • by means of • Instead of focusing the QoS problem on a per flow basis, a reduced set of QoS classes was proposed as a way to achieve the scalability of the model. • policing in the edge (on a per flow basis) • few classes (aggregated traffic) • There was no more connection state in the core network, and forwarding behaviour would be based on packet markings indicating the QoS class only. • differentiated queuing/scheduling (per class)

5. Trying to satisfy every different necessity has resulted to be not feasible… • The Integrated Services (IntServ) architecture aimed to deliver personalised QoS per flow. • Resources reservation had to be performed for each flow in all network elements in the path • Network elements had to be able to guarantee QoS per flow • Identification of flow • Personalised scheduling per flow • It is not scalable!! • The Differentiated Services (DiffServ) architecture aims to deliver a reduced set of QoS classes • Aggregating flows in classes • Identifying classes with a label (DSCP) • DiffServ Philosophy • Simple core (Per Hop Behaviour) • Intelligence (complexity) shifted to the edge (flow/traffic/class policing)

6. So far, the DiffServ model has not succeeded… • Because of: • The per domain (intra-domain) behaviour is heterogeneous • No agreements have been reached for guaranteeing inter-domain requirements • Traditional telcos feel the “uncontrolled” necessity of controlling every single QoS call/flow • MPLS was designed for allowing the traditional “circuit” traffic engineering • By means of establishing paths from the origin • (a sort of circuit oriented model, that Telcos knew how to manage) • However, IP routing advantages are (partially) lost • Resilience, scalability, load balancing, autonomous work • new techniques are envisioned - FRR for resilience - but the solution is more complex. • So, MPLS is interesting for specific flows, but not for all the traffic

7. Nowadays the IMS model (3GPP) is being claimed as a potential solution for QoS • Lot of effort is being made in developing this model or similar ones, as the TISPAN model of the ETSI. • The MUSE architecture is also based on these models (IMS, TISPAN) • According to MUSE, the principles on which the QoS control architecture of the IMS model is based are: • A central view is kept of all network resources in the access network. • A central view is kept of all resources that are currently in use. • Requests for network resources are accepted or denied individually and on request. • Requests are only accepted if the network resources available at the time of the request are sufficient to meet the requested QoS. • Requests for network resources can be made by end users and by application service providers. • Resources are reserved after a request has been accepted and released after the session has finished. • Requests, acceptance and reservation of network resources can be handled independently for the upstream and downstream directions. • For example, the upstream and downstream directions can have different delays and packet loss.

8. 3GPP Terminals TISPAN NGN Architecture R1 Overview Applications PSTN / ISDN emulationMultimedia Components(Core IMS, Streaming, etc.) User Profile PSTN / ISDN Network Attachment FunctionalityNASS Resource and Admission ControlRACS Other Networks TGW AccessTransport Network AccessTransport Network IPEdge Node Core TransportNetwork IPEdge Node EdgeRouter EdgeRouter CPN 3GPP IP-CAN IPEdge Node IP-CAN Connectivity Access NetworkTGW Telephony Gateway

9. TISPAN RACS Key Aspects CPE configuration and authentication multi-access support? IMS and other systems user location and access capabilities info Inter-domain reference point access network specific functions per IP micro-flow AF Application FunctionC-BGF Core Border Gateway FunctionNASS Network Attachment Subsystem RACF Resource and Admission Control SubsystemRCEF Resource Control Enforcement FunctionSPDF Service-based Policy Decision Function

10. However, an analysis of the IMS approach seems to show some problems… • The model contemplates the possibility of applying differentiated queuing per class, as in the DiffServ model. • However, the IMS/TISPAN model has important similarities with the IntServ approach: • Resources reservation per flow across the whole path • Identification of flows in all nodes is made easier by means of using tokens (scalability problems are lightened but not completely solved) • As a consequence, IMS shows almost the same lack of scalability that IntServ model did. • In this way, IMS is interesting when QoS traffic is a reduced portion of the whole, as is currently in 3G networks, but not for deploying QoS in a massive way. A revision of the QoS principles is needed!!

11. 1st Premise: QoS is end-to-end oriented • For the end user, only end-to-end QoS is relevant • End users must agree on the QoS • Recipients must authorise the reception of a given QoS traffic • If not, DoS attack can be produced • However, this does not imply that QoS be connection oriented!! • Resources reservation has not reason to be done along the whole path • Services platform intermediation has not reason to be needed if QoS classes have been previously subscripted • QoS can be reached through specific peering agreements • All the complexity can be shifted to the network edge with the user • In MUSE, the Access Multiplexer • In NOBEL, the Edge Node

12. 2nd Premise: QoS mechanisms are not necessary when resources are unlimited • At least, if one does not want to differentiate QoS on purpose for different services • that is, making worse the QoS received by a specific service or set of services • (e.g. routing all best-effort traffic from Madrid to London through Alaska). • When resources are very scarce (e.g. wireless media) dynamic resources reservation is very recommended • So that an authorised and established QoS session do not suffer starvation (retainability with good enough QoS) • The lack of resources problem becomes an accessibility problem • Dimensioning of access points is needed in order to be able to guarantee the availability of QoS services. • E.g. In wireless communications, this is solved by an appropriate dimensioning of the cells (number and coverage area).

13. 3rd Premise: Tight QoS controls are not enough for providing QoS • Tight QoS control mechanisms (on demand admission control and resources reservation per flow) + underprovisioned network = blocking (not availability) = not satisfying QoS • In case of network congestion, users cannot access their QoS services • The goal is to avoid the network congestion • And this is not achieved by means of tight QoS control mechanisms • So, provided that network dimensioning is suitable performed, why not using looser QoS control mechanisms? • On demand admission control per flow could be avoid • On demand resources reservation per flow could be avoid

14. The loose QoS approach consists on trusting more in classical operational TE • Foreseeing the demand of every traffic class • Including their statistical distributions and the origin/destination matrixes • Dimensioning the network according to that demand • Including the dimensioning of the interconnections (and reaching QoS SLAs) with other network/service/application providers • Tracking and monitoring the performance and the usage of resources • Generation of reports, alarms, checking whether resources usage is as previously foreseen • Identification of SLAs that need to be modified and resources that must be increased and provided inside the own domain

15. Subscription based CAC is a way to make easier the network dimensioning • The subscription of a given set of services can be seen as a sort of static (fixed) resources reservation, provided a suitable dimensioning of the network • Signalling with the network would not have to be necessary • Signalling with the end user is necessary to agree on the used (yet subscribed) capabilities

16. Scalable peering agreements • Peering agreements must be rather static • Even although they can be reached with automated processes • So, peering agreements are based on aggregates with specific QoS • The network can be properly dimensioned, based on aggregated classes and aggregates SLAs.

17. As a conclusion: more complex QoS mechanisms are needed as resources are more scarce • As a consequence, complexity can be shifted to the network edge with the user, that is, the Access Multiplexer, letting the backbone more simple for scalability reasons. • This is the DiffServ philosophy • And that is the reason of proposing that more QoS classes could be implemented in the access than in the core network. • QoS could be achieved by means of a mix of loose and tight QoS control mechanisms. • Loose control for the vast part of the QoS traffic (residential oriented) • Tight control for QoS mission critical (business oriented) traffic. • These tighter control mechanisms could follow a similar approach to IntServ/IMS/TISPAN. the "golden mean" is the desirable middle ground between any two extremes

18. Next steps for QoS studies in NOBEL

19. A flexible scheme of QoS classes is desired • To take into account: • Different market constraints, costs, interconnection and feasibility • Reduced number of mandatory classes • For making easier the interconnection • Trying to be aligned with the different standardization processes • Optional classes • Networks with different needs (emergency services, network control, etc) • Less stringent classes should be assured by more stringent ones • More classes in the access than in the core

20. Defining traffic classes • A natural way to group telecommunication services seems to be in function of the traffic profile and requirements. • Elasticity level (inelastic, elastic) • Interactivity level (interactive, non-interactive) • Service availability (standard, high) • Traffic asymmetry (symmetric, asymmetric) • Bandwidth (low or narrowband, high or broadband) • Traffic variability (CBR, VBR) • Two levels for each parameter are distinguished for simplicity • Minimum solution • Binary tree • A hierarchical traffic classes tree can be designed • Outer branches are less important characteristics

21. NOBEL reference applications can be classified

22. Recommended implementation Best effort class Background class (3GPP) Non-critical class (ITU) non-interactive Transactional class Interactive class (3GPP) Responsive class (ITU) elastic interactive Streaming class Streaming class (3GPP) Timely class (ITU) non-interactive inelastic Real-time class Conversational class (3GPP) Interactive class (ITU) interactive With the potential inclusion of an emergency class if this is required by regulation constraints

23. Traffic classes are not QoS service classes... • Although traffic classes can be mapped directly into QoS service classes, these ones are the way of a network provider to satisfy the QoS requirements of previous traffic classes • What kind of QoS mechanisms have are available for the (optical) core network operator? • (virtual) switching vs. routing? (MPLS vs. IP routing?)(connection oriented vs. connectionless?) • Switching for tight QoS, routing for loose QoS • Differentiated forwarding (DiffServ) • Differentiated routing • Resilience mechanisms

24. Table 2/Y.1541- Guidance for IP QoS Classes Let us review the convenience of every identified mechanisms for the core network, and which traffic classes can be directly mapped into them

25. EF (Premium) HOL / WFQ AF1 NODE AF2 AF3 AF4 WFQ / HOL BE DropProbR> DropProbY>DropProbG DiffServ architecture Not standardised Not standardised

26. HOL or WFQ (WRR)? (I) • Head Of Line (HOL, a.k.a. strict priority) is a mechanism normally recommended for servicing real-time traffic • Weighted Fair Queuing (WFQ) or similar mechanisms (WRR, GPS, …) can be used to isolate traffic flows • Literature shows us that each one has important advantages and disadvantages. So, nowadays, there is not a clear position. • HOL advantages & disadvantages: • Most priority traffic is easily QoS guaranteed (+) • But low priority traffic can suffer starvation if misbehaviour of priority users, or not so well calculated demands (-) • WFQ advantages & disadvantages: • It helps to isolate traffic classes from each other (+) • So a misbehaviour of one does not affect to the rest • But inelastic traffic must wait its turn (-)

27. HOL or WFQ (WRR)? (& II) • In bottlenecks (relative low capacity links), HOL is necessary to guarantee maximum delays to inelastic traffic. • For elastic traffic, WFQ (WRR) could be better. We are not interested in causing starvation to best effort traffic. • In high capacity links, WFQ (WRR) is a potential solution for all the classes. • Analogy with the vehicle traffic rules of Gent: • In low capacity streets (the centre town), strict priority is assigned to the bicycles. In high capacity streets, there are marked roads for bicycles, so that “less priority” traffic (cars) do not starve. • However, not all countries (operators) have the same rules…

28. Strategy to get the so desired per-hop/per-node values per traffic class (I) • End-to-end values are the total budget • How is budget spent? (example, end2end delay budget) • At the application layers: • Transmission • Frame length (sample size) • Lookahead delay (certain codecs as G.729A, G.723.1) • Coding delay – Normally negligible • Reception • Dejitter buffer delay • Decoding delay – Normally negligible • At every node (CPN, RGW, AM, AN, EN, CN)? • Serialisation delay (forwarding delay) – Negligible in high capacity links • Processing delay (switching, headers interpretation) – Normally negligible • Propagation delays? – Negligible at local distances • To distinguish between local/ (national/) international traffic • Which budget is spent at the CPN? • Which budget is spent at the core? • Queuing delay (the bone!!)

29. Strategy to get the so desired per-hop/per-node values per traffic class (& II) • So, the remaining budget can be spent at the queues • How many queues are in our network? • How do we distribute budget? • Uniform allocation of budget • A fixed value (per class) is obtained for every node • simple, but very restrictive • Not uniform allocation of budget • More budget in the bottlenecks to allow more multiplexing gain • How many? To be studied • Conclusion: • The so expected values for the node behaviour must not be fixed. • A range of values must be provided so that a given operator can properly dimension its network.