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

On the Robustness of Soft-On the Robustness of Soft-State ProtocolsState Protocols

John Lui, CUHKVishal Misra, Columbia U.

Dan Rubenstein, Columbia U.

StateState

• 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 ConsistentKeeping 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 signalingSoft-state signaling

Signaling plane

Communication plane

Sender Receiver

• 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 signalingSoft-state signaling

Signaling plane

Communication plane

Sender Receiver

• 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 signalingHard-state signaling

Signaling plane

Communication plane

Sender ReceiverInstall

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 So Why is Soft State Design “Better”?“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 StatePrior 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 So Why is Soft State Design “Better”?“Better”?

What’s Wrong with Traditional What’s Wrong with Traditional Performance EvaluationsPerformance Evaluations

• Tradition: “Given some network conditions, design the best protocol.”

12

6 1

5 43

8

7

12

6 1

5 43

8

7

12

6 1

5 43

8

7 12

6 1

5 43

8

7

12

6 1

5 43

8

7

Input: Condition

s Protocol Parameters

12

6

1

5

43

8 7

1

2

6

1

5

43

8

7

1

2

6

1

5

4 3

8

7

1 2

6

1

5

43

87

12

6

1

5

4 3

87

Input: Condition

sOutput:

Best Solution

What’s Wrong with Traditional What’s Wrong with Traditional Performance EvaluationsPerformance Evaluations

• Tradition: “Given some network conditions, design the best protocol.”

Protocol Parameters

The “Traditional” ConclusionThe “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 A more “practical” performance evaluationevaluation

• Don’t really know what the conditions will be when configuring the protocol

12

6

1

5

43

8 7

12

6

1

5

43

8

7

1

2

6

1

5

4 3

8

7

1 2

6

1

5

43

87

12

6

1

5

4 3

87

Protocol Parameters

Input: Condition

sOutput: (Best?) Solution

Is Hard State best in this setting?

Performance-Oriented View of Performance-Oriented View of Protocol Designer IntuitionProtocol 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

Perf

orm

an

ce

Normal Operating Regime

Hard State Protocol

Soft State Protocol

good

bad

Our Comparison StudyOur 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 ModelA 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)

Refresh CostRefresh Cost

Signaling plane

Communication plane

Sender Receiver

Cost = 3K1 Cost = K1 Total Cost ~

L/R K1 Cost = 2K1

Cost to keep state consistent

(Re)Initialization Cost(Re)Initialization Cost

Signaling plane

Communication plane

Sender Receiver

# of drops ~ pL/R, Cost = K2 pL/R

p Cost to recover from accidental timeout

Stale state costStale state cost

Signaling plane

Communication plane

Sender Receiver

Stale state lifetime ~ R, Cost = K3 pR

p

State Removal Signal

Cost of enacting an actual timeout

Total CostTotal 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 What is the optimal R R to minimize to minimize

total cost?total cost? K2 K1 >> K3 , R

K2 K1 << K3 , R

Optimal Optimal RR implications 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

Cost ComparisonCost Comparison

Results match

previous robustness

intuition

Resource Blocking (DoS) AttacksResource 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 ChannelCorrelated, 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 DilemmaThe Hard-State DilemmaSTOP!

STOP!

STOP!

Feedback loop: Inability to terminate induces greater losses, making it more difficult to

terminate

Results of Markov Model FormulationResults of Markov Model Formulation

As session expected lifetime (1/μ) decreases,

HS zombie sessions grow

large

Soft State has many fewer

zombie sessions

Robust Multicast FeedbackRobust Multicast Feedback

• Scenario: sender broadcasts transmission as long as some receiver listening

• Q: How does sender know if a receiver is listening?

Hard State ApproachHard State Approach

• Each “interested” receiver explicitly notifies sender of join and leave

S

R

R

R

I’m interested

I’m interested

I’m interested

I’m no longer interested

Soft State ApproachSoft 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

T T T T

S

RR

R

X X X X X

Optimized VersionsOptimized 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 ComparisonHeavy 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 ComparisonHeavy Departure Rate Comparison

μ = departure

rate of interested

clients

Soft State designs exhibit better scalability with large μ for both versions of polling protocols

ConclusionsConclusions

• 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