[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 16:00, Iljitsch van Beijnum escribió:
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
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.
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
I mean, B will inform A that B has received 3 probes. A already knows
that a has sent 6 probes, so A knows which path are not working. What
is the pointing in allowing A to inform B about the probes that A has
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.