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. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
