[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address pair exploration, flooding and state loss
El 27/05/2005, a las 17:22, Iljitsch van Beijnum escribió:
On 27-mei-2005, at 16:35, marcelo bagnulo braun wrote:
However, it gets even better if we also include ids and address pair
info for probes we recently sent or maybe even are about to send.
i don't see how this is useful... see below
So if A sends out 6 probes using 6 address pairs and puts a
"manifest" for the whole batch of probes into each of them, then B
can, after waiting a bit, determine that there is reachability from
A to B for 3 pairs and, presumably, unreachability for the other 3
pairs. B then includes this information in its replies to A and A
then knows exact reachability information for all address pairs in
the A -> B direction. (Well, probably want to send more than one
probe per pair when you need to be absolutely sure.)
the relevant information here is that B send A what probes B has
received. A informing B about whta probes A sent does not provide any
You're mostly right: it doesn't provide the benefits I thought it
would: B doesn't really need to know about reachability from A to B,
and A can already determine from what it knows it sent and what it
gets back from B what doesn't work in the A -> B direction.
However, if we assume that bidirectional connectivity is the most
common, the fact that A sent something and B didn't get it is a good
hint for B that this address probably won't work in the opposite
Since we want to arrive at one or two "good enough" pairs as quickly
as possible, such hints could be valuable.
ok, this is a choice that we need to make: do we think that the
bidirectional connectivity case will be common, so it makes sense to
provide an optimized support for it?
(because, this could also apply to the other threat that we are having,
about detecting outages, right?
Sometimes, the sender may want to receive a positive reply
immediately, while in other cases it may prefer that the other side
wait for a while and send a report that covers a number of probes.
Most likely: A sends some probes to B, and it wants an immediate reply
from B when B receives the first probe, and then a second reply for
all the other probes after sufficient time has passed for B to have
received them all.
It's probably useful to include a field that governs the reply
well, i guess i would always reply quite fast, but i would always
include info about past probes... but i guess i will be able to see
this point clearer once we have sketched a protocol