Transcript Traffic Shaping

Traffic Shaping
•Why traffic shaping?
•Isochronous shaping
•Isochronous shaping with Priority schemes
•Shaping Bursty Traffic Patterns
•Conclusions
1.Why traffic shaping?
• Network knows what traffic to expect
• Network can determine if the flow should
be allowed to send
• Network monitor the flow’s traffic - confirm
the flow’s behavior as promised
1.Why traffic shaping?
1. Regulating traffic
- 100 MB / 1 s vs 1 KB / 10 µs
2. Deciding weather to accept the flow’s data
- can buffer 100 MB ?
3. Policing a flow
- detect misbehaving flows
1.Properties of good traffic
shaping scheme
• Shaping scheme should describe wide range
of schemes
• Shaping rules should make it easy to
describe traffic patterns
• Shaping scheme should be easy to police
2. Isochronous Shaping
regular amounts of data emitted at regular
intervals
2.1. Simple Leaky Bucket
• Each flow has its own bucket
– send rate ρ
– bucket size β
• Cell & datagram traffic
• Easy to implement & to describe.
– ex: FIFO + Timer
2.2. (r,T) Smooth Traffic
• Based on stop and go algorithm
– Send no more than r bits in any T time period
• Limitation 2r sized datagram can’t be sent
• Implementation -simple
• Bit counter, refreshed every T bit times
2.3. Limitations of Isochronous
Shaping
• Easy to implement
• Easy description & traffic policing
• The range of behavior limited to fixed rate
data flow. Var. rate flows request the peak
rate -> wasting network capacity - peak
values occurs rarely
3. Isochronous Shaping with
Priority Schemes
• Uses bit patterns for priority
• How prioritizing is done:
– application: knows less important data
– network: marks the incoming cells at exceeding
rates
3. Isochronous Shaping with
Priority Schemes
• Limitations of priority schemes:
– low priority packets don’t get through
• bandwidth reservation for low priority traffic
– selectively discard packets
• many com. devices uses FIFOs - continuous
memory
~ sufficiently flexible
~ used in first generation cell switches
4. Shaping Bursty Traffic
Patterns
• Token Bucket
• Token Bucket with Leaky Bucket Rate
Control
4.1. Token Bucket
• Tokens inserted at rate ρ into bucket
• if bucket is full -> token is dropped
• send allowed if there are b tokens in bucket,
b*size ≥ packet-size
• β+τ/ρ tokens worth data at any τ time
interval
• long term transmission rate is ≤ ρ
4.1. Token bucket - limitations
• No need for discard & priority policy
• discards tokens and leaves to the flow the
managing transmission queue if the flow
overdrives the regulator
• easy to implement (counter + timer)
• policing -> bit more difficult - possibility
for cheating in data rate
4.2. Token Bucket with Leaky
Bucket Rate Control
ρ
Token bucket
ß
data
Leaky bucket
ß
c
4.2. Token Bucket with Leaky
Bucket Rate Control
• Token bucket combined with a simple leaky
bucket
• C >> ρ
• behaves like token bucket:
– permits bursty traffic - but regulates max.
traffic to rate C
– long term transmission rate is ρ
5. Conclusions
• More accurate description of flow’s rate help
network to effectively manage its resources
• Simplest shaping - leaky bucket - for fixed data
rates
• priority schemes - more general, combines H/L
priority traffic in the same flow
• token bucket (with leaky bucket) -> more diverse
traffic patterns
Flow Setup and Routing
Flow Setup and Routing
• The Host’s role in flow setup
• Protocols to establish a flow - ST II
• Routing - Multicasting flow
1. The Host’s role in flow setup
• Some mechanism/ protocol/data structure
needed to ask the network for particular
performance guarantees
• Two main ways:
– few variables identify a general class of req.
• video, voice, big file transfer flows
• routers preconfigured - new apps -> new classes
– multivalued explicit specification of flow spec.
• bustiness, delay requirements, sensitivity to loss etc.
2. Network answers to requests
Three main modes:
• simply yes / no answer
• establish the best service available currently
- if the best case is not acceptable the
application can end the flow
• negotiations should be interactive complexity at network & application
3.Protocols to establish a flow
• General requirements:
• setup protocol should accommodate multiple
receivers for a single flow
• set up flows quickly
• result in robust reservations
• change the flow properties after flow is established
• support advance reservations
3.1. Strawman proposal
• Enhance an existing internet protocol like IP
by adding a flow ID field, and a flow spec
option that can be sent as part of IP header
• Routers forward IP datagrams as before,
only if flow id is set forward based on
information about flow requirements.
• If has no info forwards normally & ask
sender for information
3.2. Version 2 of the Stream
Protocol
• Most sophisticated / complex /complicated
flow setup protocol
• Two protocols:
– a datagram forwarding protocol ST
– connection management protocol ST Control
Message Protocol SCMP
• 17 SCMP messages
• flow setup is done hop-by-hop
3.3. RSVP
• Resource ReSerVation Protocol
• not the sender is managing the flow but each
reciever
• filters are used:
• provide support for heterogeneity - receivers with
slow links still can participate on flows
• dynamic filtering allows receivers to modify flow
properties - switching btw. listening of A and B
• try to reduce load & improve bandwidth
management.
4. Routing
• Historically routing: determining if path
exists btw. two points in a network
• Routing supporting flows (more difficult):
determining if a path exists so to achieve a
flow’s requirement
4.1. Routing
Bellman-Ford
• tries to minimize routing
information by requiring
routers to pass along
information only about
best routes
• Implemented in: RIP
Dijkstra’s alg.
• distributes complete
routing information to all
routing agents
• Implemented in: OSPF,
IS-IS
4.2. Multicasting and
Multiobjective Routing
• not only finding a path but finding a
delivery tree
• sender or receiver based routing ?
Q.E.D.