Traffic Shaping

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

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.