[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
So, what is the information that needs to be included in these poll
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
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.