On 06/26/2010 10:57 PM, Martin Sustrik wrote: > Michael, > >> I believe that the common practice is to send two timestamped copies >> of every packet which are routed over two distinct network paths, i.e. >> not sharing circuits or routers, and then the receiver waits for both >> copies to arrive. If the delay between the two identical packets is >> too large, then the network is at risk, and you should assume the >> worst, i.e. the information is out of date and should be discarded. >> The timestamps are there to show you the variation in latency of the >> first packet in the pair to arrive. >> >> A couple of ways of sending two copies via two diverse paths are to >> use MPLS where you can set up two LSPs over different topological >> paths.or to use two different multicast trees which are routed >> differently by your cooperating network provider. >> >> Either SFTI or NYSE had published something about this which I >> downloaded and read about 6 years ago. Can't remember all the details >> but I remember that the intro talked about the transition from bisync >> to IP. You really should be asking this kind of question elsewhere >> where the financial types hang out. Latency is so important that even >> the guys who are primarily software developers tend to know a lot >> about how to do this. > > Thanks for the details! > > Now let me ask once again: Given there are thousands (or tens of > thousands) ad hoc heartbeat implementations out there, have there ever > been an effort to standardise it within IETF? The thing you seem to be missing is that applications or protocols have different requirements for measuring liveness or availability (to pick a couple of examples, http, imap, ospfv2 and bgp all have different keep alive semantics, the puprose and mechanism of which varies with the availability requirements. TCP keepalive is detailed way in rfc 1122, bfd is rfc 5880-5884 as a community we tend to favor the use of in-band signaling such that the application becomes aware of availability or lack-thereof rather than on bolt-on mechanisms. on the context of networks in-band signalling goes a long way towards avoiding the sorts of failures that can occur when there is not congreunce between the forwarding path and the control plane. > Martin > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf