ip bandwidth sharing paul ferguson consulting engineer internet architecture office of the cto...
TRANSCRIPT
![Page 1: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/1.jpg)
IP Bandwidth Sharing
Paul Ferguson
Consulting Engineer
Internet Architecture
Office of the CTO
1
![Page 2: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/2.jpg)
2P. Ferguson 2/99
2
Forbes Magazine July 7th, 1997
Technology Adoption
Internet
CellPhone
PC
TV
Radio
Microwave
VCR
Airplane
Telephone
Car
Electricity
![Page 3: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/3.jpg)
3P. Ferguson 2/99
What exactly is “bandwidth sharing”?
![Page 4: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/4.jpg)
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.
![Page 5: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/5.jpg)
5P. Ferguson 2/99
So what’s the problem?
![Page 6: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/6.jpg)
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).
![Page 7: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/7.jpg)
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.
![Page 8: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/8.jpg)
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.
![Page 9: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/9.jpg)
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.)
![Page 10: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/10.jpg)
10P. Ferguson 2/99
A Simplified Review of Options
![Page 11: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/11.jpg)
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.
![Page 12: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/12.jpg)
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….
![Page 13: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/13.jpg)
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.
![Page 14: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/14.jpg)
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.
![Page 15: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/15.jpg)
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.”
![Page 16: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/16.jpg)
16P. Ferguson 2/99
Architectural Overview
![Page 17: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/17.jpg)
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.
![Page 18: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/18.jpg)
18P. Ferguson 2/99
IP Differentiation: Two options
• Stateful
• IETF Integrated Services (Intserv)/RSVP
• Stateless
• IETF Differentiated Services (Diffserv)
![Page 19: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/19.jpg)
19P. Ferguson 2/99
The Building Blocks:
Diffserv:
• Classifier
• Shaper
• Policer
• Scheduler
• Dropper
Intserv:
• Classifier
• Shaper
• Policer
• Scheduler
• Dropper
• Resource Reservation
![Page 20: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/20.jpg)
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.
![Page 21: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/21.jpg)
21P. Ferguson 2/99
Building blocks (3):
• Scheduler: A (non-FIFO) queuing strategy.
• Dropper: A (non-taildrop) packet discarding scheme.
• Resource Reservation: RSVP
![Page 22: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/22.jpg)
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.
![Page 23: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/23.jpg)
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
![Page 24: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/24.jpg)
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.
![Page 25: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/25.jpg)
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….
![Page 26: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/26.jpg)
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.
![Page 27: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/27.jpg)
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)
![Page 28: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/28.jpg)
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”.
![Page 29: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/29.jpg)
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.
![Page 30: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/30.jpg)
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.
![Page 31: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/31.jpg)
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.
![Page 32: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/32.jpg)
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).
![Page 33: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/33.jpg)
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.
![Page 34: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/34.jpg)
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.
![Page 35: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/35.jpg)
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).
![Page 36: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/36.jpg)
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.
![Page 37: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/37.jpg)
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.
![Page 38: IP Bandwidth Sharing Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com 1](https://reader036.vdocument.in/reader036/viewer/2022062315/56649efb5503460f94c0d61e/html5/thumbnails/38.jpg)
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.