[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address pair exploration, flooding and state loss



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.