[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 help, AFAICT.

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 direction either.

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?



Something else:

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 immediacy.


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


regards, marcelo