CS514: Intermediate Course in Operating Systems

1. CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 19 Oct. 31

2. QoS via RSVP, Diffsrv • Recall concept from last lecture • Flow pre-specifies its goal • Network reserves resources • Goal is that if reservation is accepted, properties will hold • But as we saw, network can mess up flow QoS properties • Today: look at RSVP, Diffsrv: proposals for implementing QoS

3. Reservé, s’ils vous plait • Idea is that user will request connection properties when opening TCP session • Rate of data link will carry • Acceptable amount of jitter, loss • Perhaps other properties • Routers need to participate to provide desired behavior

4. RSVP concept     Reserve 50 msgs/sec? 

5. RSVP concept      Reserve 50 msgs/sec?

6. RSVP concept      Reserve 25 msgs/sec? Reserve 50 msgs/sec?

7. RSVP concept     Reserve 25 msgs/sec? 

8. RSVP concept Reserve 25 msgs/sec?      Success!

9. RSVP concept  Success!    

10. Router issues • Router will need to set aside resources on behalf of the flow • Identify flow by (src,dst,ports) • Router may also need a special scheduling policy • And must always reserve enough bandwidth for possible requests

11. For how long? • Internet should be stateless, oblivious to patterns of use • RSVP suggests a new kind of dependency on endpoint information • Developers responded with idea of a “lease”

12. Leases • A lease is a temporary reservation • Resources set to the side for this user or application • When lease expires, resources return to the pool automatically • RSVP operates using leases of a few seconds at a time

13. Leases • A lease needs to be renewed before it expires • Intention is that there should be ample time to do so • Will need to look at this more carefully

14. Basic RSVP assumptions • Routes are assumed to be stable • While routes are changing, all bets are off • But in modern network, routes don’t change very often • Will mobility change this? • Lease requests are assumed not to experience packet loss • Idea is that packet loss is intentional (RED) • So we can treat lease requests as a special category of operations and not drop them

15. RSVP protocol • Request to create a connection carries desired request profile • Route is determined by the usual Internet routing scheme • But hop by hop, routers set aside resources for this flow • Router that can’t allocate resources sends back a NAK • Else endpoint sends an ACK • If successful, lease will be refreshed a little before it expires

16. RSVP is criticized • Many practical problems • What if a lease message is lost? • How should router do packet queuing to ensure that if the input flow is within profile, the router respects the desired QoS behavior • How can ISV charge for resource use?

17. What if lease req. lost? • Issue is that leases must be refreshed • But messages can be lost in the Internet • If so, QoS properties will be lost for this flow, perhaps without warning

18. Packet queuing • Internet is a store-and-forward network • QoS is on a per-flow basis and is a contract • I’ll send 50 packets / sec • You’ll forward them • Unless routers maintain flow properties hop by hop, the sender-side of the contract can be violated • We saw this in the last lecture • Best queue mgt. scheme is unknown

19. ISV charge issue • A typical network path might be 25 hops long • Perhaps, 3 are road-runner, 10 are MCI, 7 are Pacific Bell, 5 are within local area networks • Who sets the prices for connections with QoS properties? • How are fees apportioned?

20. Pricing issues • If MCI sets aside 250kb in each of 10 routers, shouldn’t it be paid more than RR, with 250kb in only 3 routers? • What if MCI routers are higher performance machines where resources cost more? • How will billing work, mechanically? Can MCI trust RR?

21. Security issues • Denial of service attack • User reserves lots of router space • Perhaps uses fake charge info • Causes resource exhaustion in router

22. Wasted space • Router wants resources to be busy • But will typical QoS user actually need the worst case bandwidth reserved? • If not, resources are wasted • Router would love to reuse them • But can it safely do this?

23. Performance issue • Mostly a worry in heavily loaded big routers (“Internet backbone”) • Must classify each packet based on (src,src-port,dst,dst-port) • This could be very costly! • Worst case: QoS could become common in which case load grows as O(n2) in endpoints!

24. RSVP: Doomed? • RSVP is an IETF standard now • But seems unlikely to be deployed in real networks • These many issues are just too hard to overcome • Creates pressures for other options

25. Diffsrv • This proposal tries to offer RSVP-like properties without the drawbacks • Focus is to • Let routers operate as they do now, hence no change in cost model • But must avoid classification problem within the network

26. Diffsrv • Proposal: use edge marking • Pretend: • we have reservation for desired resources • reservation granted only if resources available • On packet admission, check to see if packet matches user profile • If not, or if no reservation, mark as “out of profile” else mark as “in profile” • Borrows one bit from IP header

27. IN IN IN IN IN IN IN Diffsrv concept Profile Checker      out

28. RIO: RED with I/O bit • Within the network, routers run a modified version of RED • But where RED discards any packet • RIO discards out of profile packets first, in profile packets have “higher priority” • Idea is that we only degrade QoS flows after running out of other flows to degrade • Revisit this in a minute…

29. How does Diffsrv simulate leases? • One idea: • RSVP-like protocol but router doesn’t really lease resources • Instead it pretends to do so • It tracks reservations but doesn’t really set reserved resources to the side • Point is that it could have reserved the resource

30. How to do leases? • Another idea: • We could have a central service to handle reservations • It watches routing tables hence knows route packets will take • Basically emulates this “abstract” lease idea using a graph of network resource uses and needs

31. IN IN IN IN IN IN IN Simulated Leases Profile Checker      out Resource Res. Service

32. Issues with Diffsrv • If network routes change, will this invalidate the reservation? • Yes! But who can tell? • Should a RED policy apply to a QoS connection? • What about our old concern about network dynamics?

33. Network flow dynamics • Recall that network can be a distorting influence on flows • With Diffsrv, guarantee was based on a stochastic picture • This distortion could mean that load surges occur where router sees clients “out of profile” and yet all packets marked as “in profile”! • Guarantees of Diffsrv are probabilistic

34. QoS gotchas • None of the proposals deals with • How to pay ISVs • Failure and dynamic route changes • Distorted flow dynamics due to normal route updates • Multicast (needed for collaboration) • As a result, all schemes give fairly weak QoS guarantees

35. Other options? • Leased lines • Company can lease line equivalent of a dedicated network link • In effect: build your own Internet • This is how Island Media works • They offer a dedicated Internet • But cost is high! • Companies like Akamai use them

36. Other options? • Run over telephone lines • Common and cheap • But capacity is tiny • Multimode applications • Idea is to glue telephony, Internet, perhaps radio or other media together to obtain desired behavior

37. Emerging issues? • Mobility is changing the picture • Mobile users have dynamic routes • They often will need QoS • Leads to vision of a resource-aware world • PDA tracks surroundings • Adapts behavior based on available QoS and loads

38. Emerging issues? • Growth in multicast • Multicast technology is taking off • But QoS proposals all treat multicast as secondary • Issue arises mostly when dealing with degradation of a flow • If there are n processes downstream from me, will a packet loss count as n lost packets or just one?

39. Emerging issues? • How to present QoS to end user • Application is object oriented • Should object interfaces include some form of QoS contract? • “I need x to operate correctly” • “When given x I guarantee y” • Some applications will have multiple QoS domains of behavior

40. Example: video • When streaming video we use MPEG compression • It produces • Index frames • One or more levels of difference frames • For best quality need all of them

41. Example: video • Suppose that process • Has limited bandwidth • Wants to receive a video MPEG stream • How can it get just what it needs?

42. Example: video • Idea is to send each type of frame in a separate stream • Could be point to point or multicast • Could even do special streams for devices with small screens… • Subscribe to those streams you can afford to receive • Very popular with multimedia community! • In multicast case lets receiver select the quality; sender doesn’t need to know

43. Layered video streams time Index Frame L0 Diff Frame Index Frame L0 Diff Frame L1 Diff Frame Index Frame Streaming video (MPEG)server

44. Layered video streams time Index Frame Index Frame Index Frame L0 Diff Frame L0 Diff Frame L1 Diff Frame Streaming video (MPEG)server

45. Layered video streams time Index Frame Index Frame Index Frame L0 Diff Frame L0 Diff Frame L1 Diff Frame Streaming video (MPEG)server Sender emits multiple streams

46. Layered video streams Low-power user subscribesto just one stream… high poweruser subscribes to multiple streams Streaming video (MPEG)server Sender emits multiple streams

47. Issues? • Receiving process might later move into a better-connected environment • So want a way to sense QoS properties of network • Could join and leave dynamically • But a process is many objects • All of them might need to reconfigure in a coordinated manner • Issue of synchronization looms large…

48. Summary • Many proposals for QoS • RSVP, Diffsrv, layered streams… • None is terribly convincing • None likely to emerge anytime soon • Leased networks, e.g. Island Media or Akamai probably most popular • But costs very high to build such networks • QoS on the Internet would be worth zillions! But how to work-around Internet challenges?)