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

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?

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

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

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

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

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?

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

What’s Wrong with Traditional Performance Evaluations Tradition: “Given some network conditions, design the best protocol.” Input: Conditions Protocol Parameters

Input: Conditions Output: Best Solution What’s Wrong with Traditional Performance Evaluations Tradition: “Given some network conditions, design the best protocol.” Protocol Parameters

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

A more “practical” performance evaluation Don’t really know what the conditions will be when configuring the protocol Protocol Parameters Input: Conditions Output: (Best?) Solution Is Hard State best in this setting?

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

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

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 K 1, K 2, etc. = Various Costs (described later)

Refresh Cost Signaling plane Communication plane SenderReceiver Cost = 3K 1 Cost = K 1 Total Cost ~ L/R K 1 Cost = 2K 1 Cost to keep state consistent

(Re)Initialization Cost Signaling plane Communication plane SenderReceiver # of drops ~ pL/R, Cost = K 2 pL/R p Cost to recover from accidental timeout

Stale state cost Signaling plane Communication plane SenderReceiver Stale state lifetime ~ R, Cost = K 3 pR p State Removal Signal Cost of enacting an actual timeout

Total Cost C(R) = K 2 p L/R+ K 1 L/R + K 3 p R E[C(R)] = K 2 p E[L]/R+ K 1 E[L]/R + K 3 p R What is the optimal R to minimize total cost? K 2 K 1 >> K 3, R K 2 K 1 << K 3, R

Optimal R implications K 2,K 1 large  Performance emphasis –Fewer refresh pings, bad to tear down state accidentally K 3 large  Robustness emphasis –Bad to miss tearing down state Higher R, “Harder” the protocol, Lower R, “Softer” the protocol

Cost Comparison Results match previous robustness intuition

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

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

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

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

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

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

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 TTTT S R R R XXXXX

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

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

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

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