Transcript Technology_adoption

IP Bandwidth Sharing
Paul Ferguson
Consulting Engineer
Internet Architecture
Office of the CTO
[email protected]
1
Technology Adoption
Radio
TV
VCR
Car
Microwave
PC
Telephone
Electricity
Internet
Airplane
Cell
Phone
Forbes Magazine July 7th, 1997
P. Ferguson 2/99
2
What exactly is “bandwidth
sharing”?
P. Ferguson 2/99
3
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.
P. Ferguson 2/99
4
So what’s the problem?
P. Ferguson 2/99
5
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).
P. Ferguson 2/99
6
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.
P. Ferguson 2/99
7
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.
P. Ferguson 2/99
8
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.)
P. Ferguson 2/99
9
A Simplified Review of Options
P. Ferguson 2/99
10
Avoiding congestion…
• Over-build. Throw bandwidth at it.
• Limit aggregate incoming traffic to
bandwidth of smallest link.
• Neither of these are necessarily
realistic.
P. Ferguson 2/99
11
Dealing with congestion…
• Allow queues to tail-drop packets.
• Or do something else. Several options
are available here. More on this later….
P. Ferguson 2/99
12
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.
P. Ferguson 2/99
13
So something…..
• …which provides traffic differentiation
in the face of congestion, and/or
• ….partition bandwidth to allow
protection for a subset of traffic.
P. Ferguson 2/99
14
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.”
P. Ferguson 2/99
15
Architectural Overview
P. Ferguson 2/99
16
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.
P. Ferguson 2/99
17
IP Differentiation: Two options
• Stateful
• IETF Integrated
Services
(Intserv)/RSVP
• Stateless
• IETF Differentiated
Services (Diffserv)
P. Ferguson 2/99
18
The Building Blocks:
Intserv:
Diffserv:
• Classifier
• Classifier
• Shaper
• Shaper
• Policer
• Policer
• Scheduler
• Scheduler
• Dropper
• Dropper
• Resource
Reservation
P. Ferguson 2/99
19
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.
P. Ferguson 2/99
20
Building blocks (3):
• Scheduler: A (non-FIFO) queuing
strategy.
• Dropper: A (non-taildrop) packet
discarding scheme.
• Resource Reservation: RSVP
P. Ferguson 2/99
21
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.
P. Ferguson 2/99
22
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
P. Ferguson 2/99
23
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.
P. Ferguson 2/99
24
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….
P. Ferguson 2/99
25
What about “hard guarantees” on
end-to-end delay and jitter?
• Well, RSVP gives you a bound on endto-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.
P. Ferguson 2/99
26
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)
P. Ferguson 2/99
27
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”.
P. Ferguson 2/99
28
What about “hard guarantees” on
end-to-end delay and jitter? (4)
• RSVP: Fairly hard guarantee on end-toend “maximal queuing delay”. No
guarantees on jitter, although
probabilistically good.
P. Ferguson 2/99
29
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.
P. Ferguson 2/99
30
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.
P. Ferguson 2/99
31
Jitter message (2):
• Probably the most effective method of
dealing with jitter is to adapt at the endsystem (e.g. RTP-based monitoring).
P. Ferguson 2/99
32
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.
P. Ferguson 2/99
33
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.
P. Ferguson 2/99
34
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).
P. Ferguson 2/99
35
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.
P. Ferguson 2/99
36
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.
P. Ferguson 2/99
37
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.
P. Ferguson 2/99
38
Fin.
Thank you.
[email protected]
P. Ferguson 2/99
39