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

regular amounts of data emitted at regular intervals 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 ß Leaky bucket c data ß

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

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