1. Traffic Shaping Why traffic shaping? Isochronous shaping
Isochronous shaping with Priority schemes
Shaping Bursty Traffic Patterns
Conclusions

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

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

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

5. regular amounts of data emitted at regular intervals
2. Isochronous Shaping
regular amounts of data emitted at regular intervals

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

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

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

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

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

11. 4. Shaping Bursty Traffic Patterns
Token Bucket
Token Bucket with Leaky Bucket Rate Control

12. 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 ≤ ρ

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

14. 4.2. Token Bucket with Leaky Bucket Rate Controlρ
Token bucket ß
Leaky bucket c
data ß

15. 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 ρ

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

17. Flow Setup and Routing

18. Flow Setup and Routing The Host’s role in flow setup
Protocols to establish a flow - ST II
Routing - Multicasting flow

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

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

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

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

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

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

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

26. 4.1. Routing Bellman-Ford Dijkstra’s alg.
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

27. 4.2. Multicasting and Multiobjective Routing
not only finding a path but finding a delivery tree
sender or receiver based routing ?
Q.E.D.