1 / 21

Causal Delivery

Causal Delivery. (Thomas) Matt Guinn CS523, Spring 2006. Research Basis. Causal Delivery Protocols in Real-time Systems: A Generic Model Paulo Verissimo University of Lisboa 1996 Available at library (not electronically) or from TA 004.3305 RE. Purpose – Multicast Reliability.

eman
Download Presentation

Causal Delivery

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. Causal Delivery (Thomas) Matt Guinn CS523, Spring 2006

  2. Research Basis • Causal Delivery Protocols in Real-time Systems: A Generic Model • Paulo Verissimo • University of Lisboa • 1996 • Available at library (not electronically) or from TA • 004.3305 RE

  3. Purpose – Multicast Reliability • Clock-driven • Require a global time basis or reference • Considered most suitable for real-time systems • Timer-driven • “Clock-less” • Acknowledgement based relying on local timers (e.g. relative references) • Asynchrony led to doubts on applicability

  4. Purpose (continued) • To show that clock-based protocols are not absolutely necessary to maintain a cause-effect ordering • Ensuring causal delivery in a timer-based protocol accomplishes this • Allows for more effective protocol development by providing more options in the search for a “best fit”

  5. Outline • Basic definitions and assumptions • Key concepts of causality • Three theorems for proving causal ordering

  6. Causal Delivery – Defined • Given a distributed system where messages are being passed back and forth, causal delivery ensures that they are all delivered in precedence order • More formally: “Consider two messages, m1, m2, sent by p, resp q, to the same destination participant r. Causal delivery ensures that if sendp(m1)→sendq(m2), then deliverr(m1)→deliverr(m2), i.e. m1 is delivered to r before m2”

  7. Assumptions and Notations • Systems in question are synchronous • Known bounds on CPU speed, message transmission delay, clock rate drift • Events • Basic event - eip – either internal or external, it is the “i-th” event of “participant” p • Action – ACTp(a) – participant p takes some external action (i.e. I/O or sending message) • Our “send” event • Observation – OBSp(a) – participant p observes an external event a such as an environmental observation, or delivery of a message sent by another participant • Our “deliver” event

  8. Precedence • In order for an event to precede (→) another event, at least one of the following must hold true: • for j > i, eip → ejp • for p != q, eip → ejq if eip is an external event ACTp(a) and ejq is an external event OBSq(a) • for p != q, eip → ejq if there exists an event e such that eip → e and e → ejq

  9. Previous work – Logical Ordering • Logical ordering • Causality controlled by protocol itself • A message m1 logically precedes m2 if: • m1 is sent before m2, by the same participant • or m1 is delivered to the sender of m2 before it sends m2 • or there exists a message m3 such that m1→m3 and m3→m2

  10. Logical Ordering Continued • Oddly similar…why cover again? • Logical ordering works naturally in environments where only that protocol is in use • Environments which include any type of data transmission which goes unnoticed or unaffected by the protocol can generate failures • These conditions are known as “hidden channels” or “clandestine” information • Almost all modern distributed environments have multiple protocols and any number of hidden channels • Would be represented in our system as an ACT or OBS in a chain of causally related events which do not correspond to sends or deliveries of a logical ordering protocol

  11. Temporal Ordering • Common sense tells us that in order for an event to cause an effect in another, it must precede it in time • “a message m1 precedes m2 temporally if the send event of m1 physically occurs before that of m2, in a Newtownian time-frame” • t(send(m1)) < t(send(m2))

  12. Temporal Ordering Failings • Time-stamping indeed helps maintain causal order under optimal circumstances • Fails to account for real-world timing constraints • The time required for data to travel from one participant to another, execution time at a node, etc • A minimum, finite amount of time is required in order for one event to cause an effect in another • δ is our notation for this minimum amount of time • Only messages separated by at least this (δ) amount of time can be considered “causally related”

  13. Fixing Temporal Ordering • To accommodate the shortcomings of temporal ordering, we introduce three more concepts • δ – precedence • An event e is said to δt-precede an event e` (e → e`), if t(e`) – t(e) > δt • Synchronism metrics • Delivery time of a message, tpd(m) is the interval between send(m) event and deliverp(m) event at p • t(dliverp(m)) – t(send(m)) • Tpdmax = maximum delivery time for participant p • Tpdmin = minimum delivery time for participant p

  14. Steadiness • Steadiness is the greatest difference across all possible participants between their maximum and minimum delivery times and is symbolized by σ • σ = maxp(Tpdmax – Tpdmin) • We these fundamentals, we can now state the first of three theorems that support causal delivery

  15. Theorem 1 • A protocol with σsteadiness delivers messages m1 and m2, such that send(m1) -> send(m2), in temporal order • This proves precedence, but not necessarily causality since messages may still precede each other, but not be ordered causally due to the steadiness delay

  16. Two additional concepts • Local granularity – The minimum delay between any two events in a given participant • Symbolized as μt • Propagation Delay – The minimum delay between an Action event and its corresponding Observation event between two participants • Symbolized as μs

  17. On hidden channels… • Adverse environments – “Those where channels external to the protocol can deliver information faster than the protocol itself” • μs < minp(Tpdmin) • Propagation delay is now defined by fastest hidden channel • Favourable environments – “Those where the channels external to the protocol are slower than or as fast as the latter, or do not exist…” • μs = minp(Tpdmin) • Propagation delay is defined by the fastest execution available from the protocol

  18. Theorem 2 -Adverse and Favourable • A system with local granularity μt and propagation delayμs can ensure causal delivery ifμt >maxμ(Tμdmax) - μs • Valid for either adverse or favourable environments • Says that as long as your local time between events is greater than the largest transmission time minus the propagation delay, you can ensure causal delivery

  19. Theorem 3 - Favourable • A system with local granularity μt, propagation delayμs, a protocol with steadiness σ and an absolute minimum delivery time of minμ(Tμdmin), can ensure causal delivery ifμs =minμ(Tμdmin) and μt >σ • This is given since in favourable conditions, it lowers the allowed minimum value of μt

  20. Conclusion • Precedence, temporal order, synchronicity, δ – precedence, steadiness, local granularity, and propagation delay are all quantities which must be known in order to have a provably causal system • Together they support the preceding three theorems which, when applied to a protocol in development, allow one to maintain the requirements for causal delivery if it is so required • Forms the basis for much future work which we see everyday in distributed applications

  21. Thanks! • Direct questions to: • tguinn2@uiuc.edu

More Related