Ip bandwidth sharing
This presentation is the property of its rightful owner.
Sponsored Links
1 / 39

IP Bandwidth Sharing PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on
  • Presentation posted in: General

IP Bandwidth Sharing. Paul Ferguson Consulting Engineer Internet Architecture Office of the CTO [email protected] 1. What exactly is “bandwidth sharing”?. Bandwidth sharing:.

Download Presentation

IP Bandwidth Sharing

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

[email protected]

1


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.


So what s the problem

So what’s the problem?


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

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


A simplified review of options

A Simplified Review of Options


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


Architectural overview

Architectural Overview


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

IETF Integrated Services (Intserv)/RSVP

Stateless

IETF Differentiated Services (Diffserv)

IP Differentiation: Two options


The building blocks

Diffserv:

Classifier

Shaper

Policer

Scheduler

Dropper

Intserv:

Classifier

Shaper

Policer

Scheduler

Dropper

Resource Reservation

The Building Blocks:


Building blocks 2

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.


Building blocks 3

Building blocks (3):

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

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

  • Resource Reservation: RSVP


Major differences intserv diffserv

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.


Diffserv ef phb major points

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


Diffserv af phb major points

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.


What acronym have i thus far avoided

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


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:

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

  • 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

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

  • 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

  • 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

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.


Summary 2

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.


Summary 3

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.


Ip bandwidth sharing

Fin.

Thank you.

[email protected]


  • Login