IP Bandwidth Sharing

Paul Ferguson

Consulting Engineer

Internet Architecture

Office of the CTO

ferguson@cisco.com

1

2P. Ferguson 2/99

2

Forbes Magazine July 7th, 1997

Technology Adoption

Internet

CellPhone

PC

TV

Radio

Microwave

VCR

Airplane

Telephone

Car

Electricity

3P. Ferguson 2/99

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.

ferguson@cisco.com