Re: address pair exploration, flooding and state loss

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 17-mei-2005, at 20:15, marcelo bagnulo braun wrote:

> The next question is what is the form of the packet exchange  
> required for Address pair Exploration and what information need to  
> be included in those packets. The faildet draft defines a  
> mechanisms where nodes send multiple poll messages using different  
> address pairs. In each of those poll packets, the node includes  
> reachability information obtained from previously received poll  
> packets.
> So, what is the information that needs to be included in these poll  
> packets?
> It seems that the minimum required is to include enough information  
> to allow the node to identify which packet was received by the peer.

[...]

> So, each poll packet needs to contain the following information:
> - its own poll packet identifier
> - the poll packet identifiers of previously received poll packets,  
> in the case that this poll packet is issued as a reply to a poll  
> packet.

> Anything else? security stuff?

Security stuff? Just make room for TLV options.  :-)

I think including probe identifiers and address information for  
recently received packets from the other side is good. This way, out  
of (say) 6 probes sent, 3 received and 1 reply received back at the  
original sender, we get to know reachability information for 1  
address pair and unreachability for 2 address pairs.

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.

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

Additionally, there should be timestamps everywhere. This means that  
after receiving a second probe, it becomes possible to determine the  
relative unidirectional delay for each reachable address pair.

An important objective of this sub-protocol is to know when to stop  
probing, as the number of possible address pairs goes through the  
roof when both ends have more than a couple of addresses.