On the Robustness of Soft-State Protocols

1. On the Robustness of Soft-State Protocols John Lui, CUHK Vishal Misra, Columbia U. Dan Rubenstein, Columbia U.

2. State • To operate correctly, network protocols require that communicating nodes share state, e.g., • Connection is “active” • The largest sequence # received was … • Q: In networks with a lossy/unpredictable control channel, how is state information kept consistent across nodes?

3. Keeping State Consistent • Two very different approaches / philosophies / mantras to how the signaling is performed: • Hard-state: The “Telephony Philosophy”? • Soft-state: The “Internet Philosophy” [Clark’89] • The difference: • Easy to describe philosophically • Hard to define precisely

4. Soft-state signaling Sender Receiver Signaling plane Communication plane • Best effort signaling • Refresh timer: state needs periodic refresh • State only removed by time-out • Failure to communicate  go to safe (default) state

5. Soft-state signaling Sender Receiver Signaling plane Communication plane • Best effort signaling • Refresh timer: state needs periodic refresh • State only removed by time-out • Failure to communicate  go to safe (default) state

6. Install removal ack error Hard-state signaling Sender Receiver X Signaling plane Communication plane • State is explicitly added and removed • Assumes very reliable communication channel • Failure to communicate  special recovery procedure

7. So Why is Soft State Design “Better”? Some common responses: • It’s more robust • To what? Packet loss? High delays? • It’s better at handling really bizarre network conditions • Like what? Really high loss rates? Really high delays? • Recovery is part of soft state’s normal operating process (no separate recovery operations needed) • So what?

8. Prior work examining Soft State • [Raman,McCanne ’99] • Queueing model of SS signaling system • Showed SS/HS hybrid improves protocol performance • [Ji et al ’03] • Performance comparison between SS, HS, and SS/HS hybrids • Conclusion: Hard State beats Soft State, but hybrid SS/HS protocols are best So Why is Soft State Design “Better”?

9. 1 1 1 1 1 2 2 2 2 2 8 8 8 8 8 7 7 7 7 7 3 3 3 3 3 1 1 1 1 1 6 6 6 6 6 4 4 4 4 4 5 5 5 5 5 What’s Wrong with Traditional Performance Evaluations • Tradition: “Given some network conditions, design the best protocol.” Input: Conditions Protocol Parameters

10. 1 1 1 1 1 2 2 2 2 2 8 8 8 8 8 7 7 7 7 7 3 3 3 3 3 1 1 1 1 1 6 6 6 6 6 4 4 4 4 4 5 5 5 5 5 What’s Wrong with Traditional Performance Evaluations • Tradition: “Given some network conditions, design the best protocol.” Input: Conditions Output: Best Solution Protocol Parameters

11. The “Traditional” Conclusion • For any network condition, hard state protocols can be configured for that condition to out-perform their soft state counterparts

12. 1 1 1 1 1 2 2 2 2 2 8 8 8 8 8 7 7 7 7 7 3 3 3 3 3 1 1 1 1 1 6 6 6 6 6 4 4 4 4 4 5 5 5 5 5 A more “practical” performance evaluation • Don’t really know what the conditions will be when configuring the protocol Input: Conditions Output: (Best?) Solution Protocol Parameters Is Hard State best in this setting?

13. Suppose protocols are “tuned” to operate most efficiently under “normal” conditions Claim: HS performance worsens more rapidly than SS as conditions vary from norm Performance-Oriented View of Protocol Designer Intuition Hard State Protocol bad Normal Operating Regime Soft State Protocol Performance good Network Condition

14. Our Comparison Study • We choose 3 network scenarios • DoS Attack • Correlated, Lossy Feedback Channel • Broadcast Communication Environment • For each scenario: • Pick a HS and SS protocol used in the scenario • Choose protocol parameters (timeout lengths, # attempts) to work well for “expected network conditions” • Vary the network conditions • Watch how the protocol performs (w/o rechoosing protocol parameters!!)

15. A Generic Signaling Protocol Model • L = Lifetime that a “state” should exist • R = Refresh interval • T = Timeout interval (e.g., 3R for SS many protocols) • p = Channel loss probability • K1 , K2 , etc. = Various Costs (described later)

16. Cost= 3K1 Cost = 2K1 Cost= K1 Total Cost ~ L/RK1 Refresh Cost Sender Receiver Signaling plane Communication plane Cost to keep state consistent

17. p (Re)Initialization Cost Sender Receiver Signaling plane Communication plane Cost to recover from accidental timeout # of drops ~ pL/R, Cost = K2 pL/R

18. p State Removal Signal Stale state cost Sender Receiver Signaling plane Communication plane Cost of enacting an actual timeout Stale state lifetime ~ R, Cost = K3 pR

19. K2 K1 >> K3 , R K2 K1 << K3 , R Total Cost C(R) = K2 p L/R+ K1 L/R + K3 p R E[C(R)] = K2 p E[L]/R+ K1 E[L]/R + K3 p R What is the optimal R to minimize total cost?

20. Optimal R implications • K2 ,K1 large Performance emphasis • Fewer refresh pings, bad to tear down state accidentally • K3 large  Robustness emphasis • Bad to miss tearing down state • Higher R, “Harder” the protocol, Lower R, “Softer” the protocol

21. Cost Comparison Results match previous robustness intuition

22. Resource Blocking (DoS) Attacks • Good Traffic: uses and releases resource • Attacker: doesn’t release resource until timeout Hard state more susceptible to attacks

23. Correlated, Lossy Feedback Channel • Client connects to a server • If loss rate from server too high, client chooses to disconnect • Soft State: receiver stops sending refresh messages • Hard State: receiver tries to push a “disconnect” message through the lossy channel • Channel losses (in both directions) are equal

24. The Hard-State Dilemma STOP! STOP! STOP! Feedback loop: Inability to terminate induces greater losses, making it more difficult to terminate

25. Results of Markov Model Formulation As session expected lifetime (1/μ) decreases, HS zombie sessions grow large Soft State has many fewer zombie sessions

26. Robust Multicast Feedback • Scenario: sender broadcasts transmission as long as some receiver listening • Q: How does sender know if a receiver is listening?

27. I’m interested I’m interested I’m interested I’m no longer interested Hard State Approach • Each “interested” receiver explicitly notifies sender of join and leave R R S R

28. X X X X X Soft State Approach • Some receiver must ping sender about interest within time period T or broadcast stops • receiver pings randomly delayed and broadcast so other receivers can suppress their pings • propagation delays can induce multiple pings per interval R R S R T T T T

29. Optimized Versions • Prefix-matching methods [Bolot’93] can be used to reduce receiver communication costs • Hard-state: used to choose a leader • Soft-sate: used to reduce feedback rate

30. Heavy Arrival Rate Comparison  = arrival rate of interested clients Soft State designs exhibit better scalability with large  for both versions of polling protocols

31. Heavy Departure Rate Comparison μ = departure rate of interested clients Soft State designs exhibit better scalability with large μ for both versions of polling protocols

32. Conclusions • Hard state protocols can often outperform soft state protocols when network conditions are known • What makes soft state “better” design is its ability to provide “acceptable” performance over a larger variety of network conditions