Enrico, My comment was that the reason 802.11 has reliability isn't the same as the reason we may or may not need reliability in an overlay link protocol. 802.11 is irrelevant, the loss characteristics of overlays is not.
But in your example, the overlay link protocol having reliability doesn't solve the problem either, if your application is real-time communication. If the failure detection time is 1 minute, 8% of your queries are going to take an average of 30 seconds to complete (assuming they succeed on the second try). So you need to rely on another mechanism to try to complete the query more quickly. Whether that is each hop replacing the failing peer in their routing table before they officially fail it and stop trying to re-establish (after 1 minute) or the querying peer trying alternative routes or replicas, you need to find an alternative route faster. Bruce On Thu, Apr 9, 2009 at 6:36 PM, Enrico Marocco <[email protected]> wrote: > Bruce Lowekamp wrote: >> The principle I was trying to apply a few messages ago was that if >> loss in the overlay link layer is caused by congestion, and end-to-end >> protocols react to loss by backing off, we have the same property as >> TCP. Your suggestion that if 802.11 needing reliability implies that >> an overlay link protocol only makes sense if you believe that the >> overlay link protocol experiences losses that are not due to >> congestion. I don't believe that is likely to be true, so 802.11 is a >> bad example. > > Uh?? In a ring based DHT with 1000 nodes, failure detection time of 1 > minute, if peers fail on average every 60 minutes every query has a 1 - > (1 - 1 / 60) ^ (log2(1000) / 2) =~ 8% probability to find a failed hop > on its way. YMMV, but that's hardly irrelevant, especially if compared > to the inherent packet loss rate of 802.11 (which, IIRC, should be less > than 10%). > > -- > Ciao, > Enrico > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
