On Sun, Apr 12, 2009 at 10:25 PM, Bruce Lowekamp <[email protected]> wrote: > On Fri, Apr 10, 2009 at 7:35 AM, Enrico Marocco > <[email protected]> wrote: >> Bruce Lowekamp wrote: >>> 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. >> >> The reason why you may want to consider hop-by-hop reliability in RELOAD >> is performance, just as in 802.11. >> > > Sure, everything ultimately comes down to performance. But that's > reduction to the absurd. Losses in wired networks mean there is > congestion and the senders should slow down. Losses in wireless > networks don't necessarily mean anything. > > There are certainly good reasons to consider overlay link level > retransmissions. (IMHO the best is that most sessions are short, so > the sender backing off means little.) But the issues need to be taken > beyond "802.11 has it, so we should too." > >>> 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. >> >> Or each hop forking a parallel route right after a few retransmissions >> of the same packet; that would take much longer if retransmissions were >> end-to-end (i.e. rather than constant, the time overhead would grow >> linearly with the _estimated_ path length). > > We've been avoiding having actual parallel forking used in the base > draft. What I think we could include is a simple approach that if A > is doing link-level retrans to B and believes it has failed, A should > replace B in its routing table with the next-best match and let the > fragment be retransed to the new entry. Meanwhile, continue trying to > re-establish with B and bring it back if it's still alive. > > However, this type of approach would be incompatible with any pure tcp > or tcp-over-udp overlay link layer.
Actually, I retract that last statement. We already have acknowledgements over tcp since its timeout is too high, so as long as that value is equal to the point where you want to fallback to the next best entry for the routing table, it's fine. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
