Re: Failure Detection (was Re: soft state (was Re: shim6 and bit errors in data packet headers

[Erik Nordmark <erik.nordmark@sun.com>]

marcelo bagnulo braun wrote:

> My understanding of how such mechanism would work is the following:
>
> The shim layer observes the amount of traffic exchanged during the last 
> T seconds, being Tx the number of packets transmitted and Rx the number 
> of packets received during the last T seconds.
> If Tx>0 and Rx>0, then no problem
> If Tx=0, then no problem

In those two cases it is really "not my problem", since there might be a 
problem, but the peer will have to detect it.

> If Tx>0 and Rx=0, then perform a reachability test to verify the current 
> locator pair, and eventually a path exploration exchange
>
> Upon the reception of a path exploration by the peer, the node must 
> perform a reachability test to verify the current locator pair.

ok

> My opinion about these two are the following:
>
> About 1: i guess this mechanism would improve the efficiency of the 
> solution because it would reduce the number of reachability test 
> exchanged to verify the current locator pair in the case of and UDP 
> bidirectional flow (or any other bidirectional flow where the ULP does 
> not provide positive feedback)

Yes, I think it will reduce the number of probes in this case.

> About 2: this mechanism optimizes the case of bidirectional flow that 
> belongs to ULPs that not provide positive feedback (e.g. UDP)
> However, this mechanism only work in the case where at least one path 
> with bidirectional connectivity is available. This mechanism fails in 
> the case where the only paths available are two different unidirectional 
> paths. This means, that if we want to support such case (i.e. if we want 
> to be able to preserve the communication in this case), then we need to 
> be able to detect and overrule such case.

I don't understand why you think this is limited to the bidirectional 
locator pair case. If A is using <A1, B1> and B is using <B2, A1>, then 
the optimization to suppress probes works just as well as when B is 
using <B2, A1>. The probes just serve to verify the current locator 
pair, hence the response to a probe would presumably use the current 
locator pair in the reverse direction.

One other factor to take into account is that for the optimization to 
work the receiver has to count the Rx packets for a ULID pair. But, 
before there is any failure i.e. when the locators are the ULIDs, the 
receiver wouldn't otherwise have a need to lookup the locator pair; it 
would just like today's IP code
 - look at IP destination to determine if "packet for me"
 - look at IP nexthdr to see what to do (e.g., pass to UDP code)

Rx counting would add to that code path
 - lookup IP <src, dst> to find counter; increment Rx counter

[Note that once the locators are no longer the ULIDs the receiver have 
to find the shim context, thus there wouldn't be any additional lookup 
to count Rx packets. But assuming most packets arrive using 
ULIDs=locators, we need to worry about the performance of an 
implementation in that case.]

  Erik