[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: soft state (was Re: shim6 and bit errors in data packet headers
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
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
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
We can tolerate this in less common cases (depending on the amount of
test traffic), but not for the more common upper layer protocols.