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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 31-mei-2005, at 19:36, Erik Nordmark wrote:

> > What I'm getting at is that one end says "hey, can you still hear   
> > me?" and then the other end says "sure, and can you still hear  
> > me?".  The first party then replies with "yes" and we know that  
> > there is  reachability in both directions.

> Yes, one can verify that bidirectional reachability exists (when it  
> does exist) by using 3 packets instead of the naive approach which  
> would result in 4 packets.
> But that doesn't necessarily help when reachability does not exist  
> for some subset of the address pairs.

While I think that we want to save this fourth packet, my real point  
was that when one end suspects there is a reachability problem, this  
in itself should be enough for the other side to become suspicious as  
well. I.e., the situation where one end detects a failure but the  
other keeps sending packets into the void in blissful ignorance would  
be suboptimal if the first end's suspicions were correct and there  
was a failure, and (as would be common) a bidirectional one.

> > > Thus I think we'd want a packet driven trigger of reachability   
> > > testing (much like NUD). When A sends a ULP packet to B, it  
> > > checks  whether it has current reachability information for B,  
> > > and if not  it triggers reachability testing.

> > Disagree. I think we should assume reachability until we get a  
> > hint  that there is none. So if A sends a packet to B, B does  
> > nothing and  will 99% likely in due course send a packet back  
> > because transports  tend to work in both directions. However, if A  
> > doesn't get a reply  and the packet it sent earlier isn't one that  
> > is known to go  replyless (i.e., TCP ack-only or fin packets, A  
> > triggers reachability  testing.

> This is the debate about positive vs. negative advise from the ULPs.

Hm, in a binary world saying no or not saying yes are the same  
thing... Not sure if there is a big difference here.

> You are advocating that the ULPs provide negative advise.

Actually I want the shim to monitor ULP progress rather than depend  
on the actual ULP to provide feedback. The problem with that would be  
that in many cases (= 99% of the time when UDP is the payload), the  
"real" ULP is implemented in the application.

> But that isn't sufficient to trigger in all cases of failures.

> Take the case when the TCP on A is sending data to B, hence B is  
> only sending ACK packets back to A.
> The TCP on A can easily generate negative advise when it has  
> retransmitted a few times and doesn't receive a response.

So far so good.

> But things are problematic on B, because there isn't an (efficient)  
> strategy for the TCP on B to generate negative advise - it doesn't  
> run a retransmit timer.

Ah, but if A can detect the failure in this case, then that would be  
good enough if A can tell B about it at some point.

A long time ago in a galaxy far away, I thought it would be important  
to handle the case where only one end has the knowledge to repair the  
failure. However, I don't think this applies to the shim as all  
addresses for both sides are communicated during the shim negotiation  
so the possibility of a successful repair shouldn't depend on which  
end detects the failure.

So IMO, it is good enough when just one side is able to detect the  
failure.

> Thus when something fails it will always be up to A to initiate the  
> exploration of alternate locator pairs. Also, the time at which the  
> exploration of alternates start is a function of the retransmit  
> behavior of the ULP, which makes it harder to tightly control the  
> failover time.

No, in my plan the shim wouldn't know about retransmissions, it only  
looks for return traffic. So either the timeout is relatively long to  
accommodate ULPs that don't send traffic in the low-traffic direction  
very often (I think streaming A/V protocols send an ack every 10  
seconds or so) or relatively short but then there would be almost  
continuous reachability probes in at least one direction.

What kind of failover time do you imagine, BTW?

Current BGP is around the 2 minute mark for severe failures.

> It is easier to have the ULPs generate positive advise ("the  
> traffic to this destination is making forward progress") at both  
> ends. The fact that an ACK for new data has been recently received,  
> or that a data packet which advances the sequence number has been  
> recently received, are both easy indications of forward progress.

Doesn't this require changes to all transports?

> With such a strategy the shim implementation can do a check after  
> sending a ULP packet: "how long time ago since some positive advise?"

AFter every packet...?

> The positive advise approach has the benefit that it works even if  
> the ULPs don't generate any advise; in this case the shim would,  
> when ULP packets are being sent, revert to periodically sending a  
> test packet.

We can tolerate this in less common cases (depending on the amount of  
test traffic), but not for the more common upper layer protocols.