Ip bandwidth sharing
1 / 39

IP Bandwidth Sharing - PowerPoint PPT Presentation

  • Uploaded on

IP Bandwidth Sharing. Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO ferguson@cisco.com. 1. What exactly is “bandwidth sharing”?. Bandwidth sharing:.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IP Bandwidth Sharing' - makana

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ip bandwidth sharing

IP Bandwidth Sharing

Paul Ferguson

Consulting Engineer

Internet Architecture

Office of the CTO



What exactly is bandwidth sharing

What exactly is “bandwidth sharing”?

Bandwidth sharing
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.

Well there actually might not be a problem
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).

Bandwidth management
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.

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.

In all cases
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.)

Avoiding congestion
Avoiding congestion…

  • Over-build. Throw bandwidth at it.

  • Limit aggregate incoming traffic to bandwidth of smallest link.

  • Neither of these are necessarily realistic.

Dealing with congestion
Dealing with congestion…

  • Allow queues to tail-drop packets.

  • Or do something else. Several options are available here. More on this later….

Do nothing
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.

So something
So something…..

  • …which provides traffic differentiation in the face of congestion, and/or

  • ….partition bandwidth to allow protection for a subset of traffic.

A brief note on the most common denominator
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.”

Congestion we all know what happens when you do nothing
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.

Ip differentiation two options

Stateful nothing…..

IETF Integrated Services (Intserv)/RSVP


IETF Differentiated Services (Diffserv)

IP Differentiation: Two options

The building blocks

Diffserv: nothing…..












Resource Reservation

The Building Blocks:

Building blocks 2
Building blocks (2): nothing…..

  • 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.

Building blocks 3
Building blocks (3): nothing…..

  • Scheduler: A (non-FIFO) queuing strategy.

  • Dropper: A (non-taildrop) packet discarding scheme.

  • Resource Reservation: RSVP

Major differences intserv diffserv
Major differences: Intserv & Diffserv nothing…..

  • 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.

Diffserv ef phb major points
Diffserv EF PHB: Major points nothing…..

  • 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

Diffserv af phb major points
Diffserv AF PHB: Major points nothing…..

  • Packets are simply marked with relative priority.

  • The service provider can interpret handling at-will.

  • Provides soft or “squishy” differentiation.

What acronym have i thus far avoided
What acronym have I, thus far, avoided? nothing…..

  • QoS, or Quality of Service. I suggest that “QoS” and “bandwidth management” are intrinsically one and the same in the world of IP.

  • Further….

What about hard guarantees on end to end delay and jitter
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.

What about hard guarantees on end to end delay and jitter 2
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)

What about hard guarantees on end to end delay and jitter 3
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”.

What about hard guarantees on end to end delay and jitter 4
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.

What about hard guarantees on end to end delay and jitter 5
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.

Jitter: jitter? (5)

  • 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.

Jitter message 2
Jitter message (2): jitter? (5)

  • Probably the most effective method of dealing with jitter is to adapt at the end-system (e.g. RTP-based monitoring).

Topological significance
Topological significance jitter? (5)

  • Tools (components) used at only the nodes they are needed.

  • Classify/Mark/Shape packets close to the “edge”, not in the network core.

Where s the architecture
Where’s the architecture? jitter? (5)

  • 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.

Perception problems
Perception problems jitter? (5)

  • 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).

Summary jitter? (5)

  • 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.

Summary 2
Summary (2): jitter? (5)

  • 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.

Summary 3
Summary (3): jitter? (5)

  • 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.

Ip bandwidth sharing

Fin. jitter? (5)

Thank you.