IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO 1

2P. Ferguson 2/99

3 What exactly is “bandwidth sharing”?

4P. Ferguson 2/99 Bandwidth sharing: It can be called the “thing” that TCP/IP does to allow bits of information originating from (and destined to) various sources to utilize the same pathways. IP has been this doing this since Day 1.

5P. Ferguson 2/99 So what’s the problem?

6P. Ferguson 2/99 Well, there actually might not be a problem: Is there congestion? If “Yes”, then there’s definitely a problem. This is where “bandwidth management” comes into the picture. If “No”, then there might be a perception or expectation problem (more on that later).

7P. Ferguson 2/99 Bandwidth Management: Ensure that the network provides an adequate “appropriate environment” for applications, some of which may have “special” requirements. Ensure that the network doesn’t melt down.

8P. Ferguson 2/99 Problem/Objective: Avoid congestion, or Provide an “appropriate environment” for applications which have “special” requirements -- “traffic protection”. Provide an environment which provides the least amount of end-to-end delay.

9P. Ferguson 2/99 In all cases…. Ongoing capacity monitoring and planning is required. If you do not know how much traffic is in your network, then this is a problem (e.g. peak/avg. rates, traffic source/dest.)

10P. Ferguson 2/99 A Simplified Review of Options

11P. Ferguson 2/99 Avoiding congestion… Over-build. Throw bandwidth at it. Limit aggregate incoming traffic to bandwidth of smallest link. Neither of these are necessarily realistic.

12P. Ferguson 2/99 Dealing with congestion… Allow queues to tail-drop packets. Or do something else. Several options are available here. More on this later….

13P. Ferguson 2/99 Do nothing... Tail-dropping packets can have an adverse impact on all traffic traversing the router, resulting in poor performance for a larger percentage of traffic. No control for which packets get dropped during congestion events.

14P. Ferguson 2/99 So something….. …which provides traffic differentiation in the face of congestion, and/or ….partition bandwidth to allow protection for a subset of traffic.

15P. Ferguson 2/99 A brief note on “The most common denominator” The End-to-End KISS theory of working within the Most Common Denominator -- IP. “An IP packet may traverse any number of link-layer mediums (e.g. Ethernet, FDDI), so any differentiation done at the link-layer is lost in the end-to-end problem.”

16P. Ferguson 2/99 Architectural Overview

17P. Ferguson 2/99 Congestion: We all know what happens when you do nothing….. It just gets worse. And people complain. And sometimes, heads roll when the performance is intolerable.

18P. Ferguson 2/99 IP Differentiation: Two options Stateful IETF Integrated Services (Intserv)/RSVP Stateless IETF Differentiated Services (Diffserv)

19P. Ferguson 2/99 The Building Blocks: Diffserv: Classifier Shaper Policer Scheduler Dropper Intserv: Classifier Shaper Policer Scheduler Dropper Resource Reservation

20P. Ferguson 2/99 Building blocks (2): Classifier: Classifies packets individually, or as belonging to a flow. Shaper: Compares incoming traffic to a profile and drops/remarks packets which exceed a threshold. Policer: Compares incoming traffic to a profile and drops/remarks packets which exceed a threshold.

21P. Ferguson 2/99 Building blocks (3): Scheduler: A (non-FIFO) queuing strategy. Dropper: A (non-taildrop) packet discarding scheme. Resource Reservation: RSVP

22P. Ferguson 2/99 Major differences: Intserv & Diffserv State, or no state. RSVP has some minor scaling concerns, when individual flows using RSVP grow beyond a few hundred (or perhaps a few thousand). This concern may be somewhat alleviated in the near future with an RSVP reservation aggregation scheme.

23P. Ferguson 2/99 Diffserv EF PHB: Major points Strict use of shaping to conform incoming EF traffic to available capacity. aggregate EF ingress <= % of link capacity set aside for this “service” in core Packets marked as EF get priority transmission. Fairly good data protection

24P. Ferguson 2/99 Diffserv AF PHB: Major points Packets are simply marked with relative priority. The service provider can interpret handling at-will. Provides soft or “squishy” differentiation.

25P. Ferguson 2/99 What acronym have I, thus far, avoided? QoS, or Quality of Service. I suggest that “QoS” and “bandwidth management” are intrinsically one and the same in the world of IP. Further….

26P. Ferguson 2/99 What about “hard guarantees” on end-to-end delay and jitter? Well, RSVP gives you a bound on end- to-end maximal queuing times which basically bound delay for flows. But it really doesn’t provide for jitter control. It does, however, “protect” flows and guarantee bandwidth. Diffserv’s EF PHB, I believe, parallels the Intserv controlled-load service.

27P. Ferguson 2/99 What about “hard guarantees” on end-to-end delay and jitter? (2) Remember: TDM and Packet technologies are fundamentally and intrinsically different. Jitter is an issue within the packet world that is generally uncontrollable at an absolute level. (Think: RTP)

28P. Ferguson 2/99 What about “hard guarantees” on end-to-end delay and jitter? (3) Comparison note: TDM -- Remember what TDM stands for? There really is no delay or jitter in a TDM world -- everything is timing and timing rates. Basically, this has become an unrealistic (my opinion) standard for VoIP -- hard delay & jitter “guarantees”.

29P. Ferguson 2/99 What about “hard guarantees” on end-to-end delay and jitter? (4) RSVP: Fairly hard guarantee on end-to- end “maximal queuing delay”. No guarantees on jitter, although probabilistically good.

30P. Ferguson 2/99 What about “hard guarantees” on end-to-end delay and jitter? (5) Diffserv EF & AF PHB: No guarantees on delay or jitter. Semi-soft and squishy “guarantees” on delay, respectively. Jitter still elusive insofar as guarantees are concerned, but with EF jitter is less of a concern. AF jitter probability is directly related to priority ordering.

31P. Ferguson 2/99 Jitter: There are no real control mechanisms within the network to control end-to-end jitter. Sure, a consistent queuing scheme might help to make it predictable, but it can never guarantee it.

32P. Ferguson 2/99 Jitter message (2): Probably the most effective method of dealing with jitter is to adapt at the end- system (e.g. RTP-based monitoring).

33P. Ferguson 2/99 Topological significance Tools (components) used at only the nodes they are needed. Classify/Mark/Shape packets close to the “edge”, not in the network core.

34P. Ferguson 2/99 Where’s the architecture? That’s it. Before you can effectively design the architecture, you must define it. Once that is done, you can look at applications and topologies, and decide which method is appropriate.

35P. Ferguson 2/99 Perception problems What happens when there is no congestion, and you want to differentiate traffic? What happens, and what would you do? Huge problem. There is also the problem of UDP (and other non-responsive traffic).

36P. Ferguson 2/99 Summary Remember: There are two worlds. One is the global Internet, and the other is private organizational networks. PATH and RESV state are not always evil, depending on what you really want. Jitter control is an extremely hard problem to solve in the network.

37P. Ferguson 2/99 Summary (2): Jitter is sometimes more easily dealt with by the host, who can readily adapt when using a real-time protocol (e.g. RTP). Voice is very sensitive to delay & jitter. Jitter is sometimes very difficult (if not altogether impossible) to remove from packet networks.

38P. Ferguson 2/99 Summary (3): It’s generally not practical (or possible) to over-build the network. Low or No Delay and Jitter are very important for some applications, not for others. It’s generally very difficult to maintain a balance of economies of scale and sustain network performance.

39P. Ferguson 2/99 Fin. Thank you.