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. > 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). -- Ciao, Enrico
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
