Comparative Performance Analysis of RSVP and RMD

Transcription

1 Comparative Performance Analysis of RSVP and RMD András Császár and Attila Takács HSNLab, Budapest University of Technology and Economics TrafficLab, Ericsson Telecommunication Hungary

2 Outline Introduction Goals Protocol operation RSVP (Resource reservation Protocol) RMD (Resource Management in DiffServ) Performance evaluation Conclusion

3 Introduction Quality of Service (IP) Admission Control Delay requirement Bandwidth requirement Bandwidth requirement Resource management Resource = Bandwidth

4 Resource Management Centralised, de-centralised (hop-by-hop) Measurement-based, reservation-based Per-flow states (IntServ), per-class states (DiffServ) RSVP RMD Reservation-based: RODA

5 Goals Unicast environment Comparative performance evaluation of RMD-RODA with RSVP as a reference protocol To introduce some methods of performance evaluation To prove that: The reduction of complexity does not entail loss in performance or what is the price of simplicity?

6 RSVP IETF RFC 2205 Receiver initiated to support multicast The upstream and downstream paths need to be the same Per-flow states in core routers (IntServ) Not scalable RSVP aggregation: less states but still topology dependent

7 RMD and RODA IETF drafts Lightweight, sender initiated, unicast only The upstream and downstream paths can be different Per-class states in core routers (DiffServ) Scalable Topology independent

8 Example: Successful Phone Call Setup Ingress Conn Req Path Succ Resv Resv Conf RSVP Core Path Resv Resv Conf Core Egress Path Resv Resv Conf Conn Req Accept Resv Conf Ingress Conn Req Succ RMD Core Core Egress Res Res Res Req Req Req Res Rep Conn Req Accept

9 Performance Evaluation Normal operation Notification times Protocol overhead Resource efficiency connection blocking Failure recovery Improper signalling Node or link failure Re-routing

10 Protocol Overhead I. Computational and storage overhead Correlated through the complexity of searching algorithms RSVP implementations create a new IP packet on every interior node Ingress Conn Req Path Succ Resv Core Path Resv Core Path Resv Egress Conn Req Accept Conn Req Succ Ingress Res Req Core Res Req Res Rep Core Res Req Egress Conn Req Accept

11 Protocol Overhead II. Bandwidth overhead of signalling messages

12 Connection Blocking Blocking ratio as a measure of network efficiency RMD achieved the same network utilisation! Without per-flow states

13 Improper Signalling What happens if some flows terminate without proper release procedures? Soft-state refresh procedure RSVP and RODA: similar behaviour

14 Node or Link Failure Re-routing OSPF, RIP On the new path, these re-routed flows did not reserve bandwidth May degrade the QoS of previous flows May need to get terminated Difference RSVP recognises re-routed flows RMD does not recognise individual flows

15 Re-routing Example

16 Re-routing and Severe Congestion 1. No congestion CAC threshold 2. Congestion but not no reaction (priority of QoS traffic) CAC threshold 3. Severe congestion CAC threshold CAC threshold Absolute overload Scheduling/policy

17 Slow Severe Congestion Handling Soft state refreshes RSVP and RODA similar

18 Fast Severe Congestion Handling I. RSVP: The re-routing node immediately forces refreshes for all affected flows (because it has per-flow information) RMD: The severe congested node quickly detects the overload Proportional to the overload it marks leaving packets to indicate congestion to the egress The egress counts marked and not-marked packets and terminates the proper amount of flows Delayed feedback loop: over-reaction Simple control theory idea: dampen the feedback signal with alpha

19 Fast Severe Congestion Handling II

20 Conclusion We have demonstrated that a simpler protocol can achieve the same performance during normal operation as the reference RSVP protocol RMD: optimised to unicast traffic only RSVP: good performance, wider functionality (multicast) but complex (IntServ) The price of simplicity shows itself after re-routing: RSVP offers a trivial solution but RMD needs some simple tricks to handle severe congestion

21 Thank you!

22 Sliding Refresh Window Flow 1 terminates without release (Max Timeout = 2 R) Timeout Res 1 Res 2 Ref 1 Ref 2 Ref 1 Ref 2 Refresh Window 1 Refresh Window 2 Sum=2 Refresh Window 3 Sum=2 Sum=1 Res 1 Res 2 Ref 1 Ref 2 Ref 1 Ref 2 Sliding Window 1: Sum=2 Sliding Window 2: Sum=2 Timeout (Max Timeout = R+R/c) Sliding Window 3: Sum=2 Sliding Window 4: Sum=2 Sliding Window 4: Sum=

23 VBR traffic Not protocol dependant but CAC algorithm dependant! We analysed protocols! Effective bandwidth, measurement-based operation, statistical multiplexing, etc. Question: Can one make a more efficient effective bandwidth calculation if one knows the traffic descriptors of every single flow one-by-one instead of only some aggregate descriptors? Theoretically: maybe