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

Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)

On 12 dec 2007, at 17:15, Alberto García wrote:


First, my understanding of the specification is that Probe Exploring
messages do not carry neither "probe received information source address" 
nor "probe received information destination address", etc.
In the specification it's required for probe packets to contain the source and destination addresses that are used to send the current probe as well as "probe nonce" and "probe data" fields. It is allowed, but not required, for a probe to also contain the source/dest/nonce/ data values from probes that were sent earlier. The reason to include this is because that way, the receiver knows which address pair combinations were tried by the sender in previous packets, and if the probes with those address pairs didn't make it to the receiver, that's a hint that those address pairs won't work in the opposite direction either.
It's also allowed but not required to copy back the source/dest/nonce/ data fields from one or more received probes. This tells the receiver which probes it sent previously were successful so it can select a working address pair. Without this information, it's probably hard for a receiver to draw definitive conclusions about which address pairs work.
Would you say that we should require that at least the set of source/ dest/nonce/data fields from the last successfully received probe is included in outgoing probes?
If this is true, I wonder if it is possible that the exploration process could not find two valid unidirectional paths (on each direction) even if 
they exist. Suppose that a node A in Exploring state receives a Probe
Exploring, so it moves to Inbound_OK.


Ok.


For the next Probes it sends, it
includes the information about the valid locators for its incoming paths (B to A), but it is not able to find a working path from A to B for some time. 

Hm, if there is a unidirectional path, wouldn't A find it at some point?
And if A inclues source/dest/nonce/data fields from B's probe then B knows which address pair from B to A works, so both unidirectional paths will be found.
The trouble would be when A doesn't include information from pobes it received from B, so that by the time that B sees a successful packet from A, B has already moved on to a new pair so both ends think there is working connectivity but there is only connectivity from A to B but not from B to A.
In B, the Retransmission Timer of B expires because a valid path from A to B 
was not found, so B starts testing other paths that are not working.
Retransmission timer = a new probe is sent? Note that we don't explicitly use this terminology in REAP. Think of each probe as a new probe without relationship to earlier ones. 


Then, A
stops receiving data from B, so the Send timer expires (I don't find any 
reason why all the possible paths should be explored in less than Send
Timeout time, so A could not test all possible paths from A to B in this 
time).
The Send Timeout keeps track of when to send a keepalive. This is part of the failure detection mechanism, which runs when data is flowing. Only when there has been no incoming traffic (but there is outgoing traffic) the reachability exploration procedure is started, which doesn't use the Send Timeout. In practice, data traffic will continue to be generated concurrently with the reachability exploration, but the two types of packets don't interact. 


Then, A falls to the Exploring state, and (in the supposition of the
previous paragraph) forgets about the working path from B to A.
A host should only enter the Exploring state when it has been sending outgoing packets but isn't seeing incoming packets. So it SHOULD be impossible to get into the Exploring state when there is working reachability in both directions. 


May be now A
sends a probe to B through a working path. but in B happens the same (it tries now with different paths from B to A that are no valid, so A tries another paths from A to B abandoning the good one...). In this case, two valid unidirectional paths existed, one from A to B, and other from B to A, but the protocol could not find them, because they not were known at the 
same time by both nodes.
I'm missing something?
I'm thinking something like this could happen if one end doesn't copy back the other's probe information, but not in any other circumstance.