1 / 30

Design Principles: Hard vs Soft State

1-2. . Maintaining network state. updated when network conditions" changestored in multiple nodesoften associated with end-system generated call or sessionexamples:RSVP router maintain lists of upstream sender IDs, downstream receiver reservationsATM switch maintains list of VCs: bandwidth all

minty
Download Presentation

Design Principles: Hard vs Soft State

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. 1-1 Design Principles: Hard vs Soft State

    2. 1-2 Maintaining network state updated when network “conditions” change stored in multiple nodes often associated with end-system generated call or session examples: RSVP router maintain lists of upstream sender IDs, downstream receiver reservations ATM switch maintains list of VCs: bandwidth allocation, VCI/VPI input-output mapping TCP: Sequence numbers, timer values, RTT estimates

    3. 1-3 State: senders, receivers sender: network node that (re)generates signaling (control) msgs to install, keep-alive, remove state from other other nodes receiver: node that creates, maintains, removes state based on signaling msgs received from sender

    4. 1-4 Hard-state state installed by receiver on receipt of setup msg from sender state removed by receiver on receipt of teardown msg from sender default assumption: state valid unless told otherwise in practice: failsafe-mechanisms (to remove orphaned state) in case of sender failure e.g., receiver-to-sender “heartbeat”: is this state still valid ? examples: Q.2931 (ATM Signaling) ST-II (Internet hard-state signaling) TCP [Q: retranmission of data or ACK if no activity?]

    5. 1-5 Hard-state signaling

    6. 1-6 Soft-state state installed by receiver on receipt of setup (trigger) msg from sender (typically, an endpoint) sender also sends periodic refresh msg: indicating receiver should continue to maintain state state removed by receiver via timeout, in absence of refresh msg from sender default assumption: state becomes invalid unless refreshed in practice: explicit state removal (teardown) msgs also used examples: RSVP, RTP, IGMP

    7. 1-7 Soft-state signaling

    8. 1-8 Soft-state signaling

    9. 1-9 Soft-state signaling

    10. 1-10 Soft-state: claims “Systems built on soft-state are robust” [Raman 99] “Soft-state protocols provide .. greater robustness to changes in the underlying network conditions…” [Sharma 97] “obviates the need for complex error handling software” [Balakrishnan 99]

    11. 1-11 Soft-state: “easy” handling of changes Periodic refresh: if network “conditions” change, refresh will re-establish state under new conditions example: RSVP/routing interaction: if routes change (nodes fail) RSVP PATH refresh will re-establish state along new path

    12. 1-12 Soft-state: “easy” handling of changes L6 goes down, multicast routing reconfigures but… H1 data no longer reaches H3, H3, H5 (no sender or receiver state for L8) H1 refreshes PATH, establishes new state for L8 in R1, R3 H4 refreshes RESV, propagates upstream to H1, establishes new receiver state for H4 in R1, R3

    13. 1-13 “recovery” performed transparently to end-system by normal refresh procedures no need for network to signal failure/change to end system, or end system to respond to specific error less signaling (volume, types of messages) than hard-state from network to end-system but… more signaling (volume) than hard-state from end-system to network for refreshes Soft-state: “easy” handling of changes

    14. 1-14 refresh msgs serve many purposes: trigger: first time state-installation refresh: refresh state known to exist (“I am still here”) <lack of refresh>: remove state (“I am gone”) challenge: all refresh msgs unreliable would like triggers to result in state-installation asap enhancement: add receiver-to-sender refresh_ACK for triggers e.g., see “Staged Refresh Timers for RSVP” Soft-state: refreshes

    15. 1-15 Signaling spectrum

    16. 1-16 How do we model/evaluate? Metrics inconsistency ratio - fraction time participating nodes disagree signaling overhead – average # of messages during session lifetime measures of robustness? convergence time complexity?

    17. 1-17 Single hop model sender, receiver single state variable state lifetime, exp(m) updates – Poisson(l) timers – exponentially distributed refresh - 1/T state expiration – 1/X link: delay exp(1/D) ,loss prob. p Transient Markov model

    18. 1-18 Model for SS (Ji03)

    19. 1-19 Model for SS

    20. 1-20 Model for SS

    21. 1-21 Model for SS

    22. 1-22 Model for SS

    23. 1-23 Model for SS

    24. 1-24 Model for SS

    25. 1-25 Model for SS

    26. 1-26 Performance metrics (SS) inconsistency ratio – d = 1 – p= signaling overhead ?= (1+l +1/T) /m

    27. 1-27 Parameter settings mean lifetime – 30 min. refresh timer, T=5sec state timer, X = 15 sec update rate – 1/20sec signal loss rate – 2% Motivated by Kazaa

    28. 1-28 Impact of state lifetime

    29. 1-29 Q: How to set refresh/timeout timers state-timeout interval = n * refresh-interval-timeout what value of n to choose? will determine amount of signaling traffic, responsiveness to change small timers: fast response to changes, more signaling long timers: slow response to changes, less signaling ultimately: consequence of slow/fast response, msg loss probability will dictate appropriate timer values Soft-state: setting timer values

    30. 1-30 Impact of state timeout timer Inconsistency ration of SS+RT is optimal at the point of X=T. This is because of the following. SS+RT employs a notification mechanism in which the signaling receiver informs the sender about state removals and signaling sender recovers from a false removal by sending another trigger message. Since SS+RT is the most sensitive to the process of removing orphaned state and its notification mechanism reduces the penalty of false removal, it works best with a timeout timer value that is just slightly larger than that of the state-refresh timer. Inconsistency ration of SS+RT is optimal at the point of X=T. This is because of the following. SS+RT employs a notification mechanism in which the signaling receiver informs the sender about state removals and signaling sender recovers from a false removal by sending another trigger message. Since SS+RT is the most sensitive to the process of removing orphaned state and its notification mechanism reduces the penalty of false removal, it works best with a timeout timer value that is just slightly larger than that of the state-refresh timer.

    31. 1-31 Hard-state versus soft-state: discussion Q: which is preferable and why? hard state: better if message OH really high potentially greater consistency system wide coupling -> difficult to analyze soft state: robustness, shorter convergence times easily decomposed -> simpler analysis

More Related