[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
marcelo bagnulo braun wrote:
Why would we want to couple the state management aspects of shim6 but
the shim6 test protocol? To me any such coupling seems undesirable,
especially since the parameters for the test protocol (how quickly to
detect failures) might be a function of upper layer advise, as well as
upper layer hints of "working" or "not working".
Well, i guess that the situation when one of the nodes has lost the shim
state can be seen as a form of failure and my assumption is that failure
detection mechanisms will likely detect it first
But that's a circular argument for including the context state in the
failure detection mechanism. You are in effect saying that the test
protocol should test whether the context has been lost on the peer since
it can be made to test for a lost context on the peer.
FWIW the outline of a test protocol in section 5.4 of
draft-arkko-multi6dt-failure-detection-00.txt doesn't assume such a
thing. (But it does assume that B remember something about previously
received probes, so there are some issues about DoS opportunities.)
I think that the protocol behaviour would be something like this.
A communication is established between node A and node B
Later on, a shim context is created between those two nodes.
The parameters for that context are:
ULIDs: IPA1 and IPB1
Locators: for IPA1 (IPA1,...,IPAn)
for IPB1 (IPB1,...,IPBm)
And a context tag presumably.
Suppose that for some reason node B losses the shim context (and only
the shim context, i.e. the application and transport state about ongoing
communications is preserved)
I guess that at this point we have several scenarios to consider:
Scenario a): the communication between A and B is still using IPA1 and
IPB1 as locators.
This scenario has two subcases:
Scenario a.1) The communication is bidirectional and e.g.
TCP is providing ack of the progress of the communication
this means that no periodic reachability test
nor any other shim signaling is being exchanged.
In this scenario, a lost of SHIM context would remain
undetected until there is a failure and node A detects it
and tries to explore alternative paths. This is so because
data packets will carry ULIDs and will be passed successfully
to the upper layers.
If we assume that B (as well as A) will have a heuristic to create shim6
contexts (e.g. based on having received 50 packets for a locator pair),
then this heuristic might be trigger and cause B to try to establish a
context with A, at which point in time A will see that it already has a
context with B.
Once that there is a failure, then
reachability test packets won't be recognized as belonging
to any existent shim context and the problem can be detected.
Here you are already assuming that reachability test packets will not be
recognized, i.e. presupposing a particular interaction between the state
management and the test protocol.
Scenario a.2) The communication is unidirectional
In this case, periodic reachability test need to be
performed in order to verify that the path is still working
If the node B losses its shim state, it won't recongnize
the reachability test packets, and the lost of context can
Again, here you are presupposing a particular interaction.
Scenario b) the communication between A and B is using alternative
In this case, when node B losses the context, data packets won't be
properly delivered in node B, because it won't be properly demuxed.
At this point, the reachability test will be performed to verify the
locator pair being used
If you are using alternate locators and the working locator pair is
unidirectional, then it seems like you'd need to be able to re-discover
that working unidirectional locator pair, before you can re-establish
the context state on B.
Thus if A is sending using IPA1->IPB2 and B was replying using
IPB1->IPA2, and B looses the context state, what do you do?
Seems like solving this case requires that the test protocol is not tied
in with the state management.
I don't know if i am missing something, but AFAICS, all the situations
when the shim context is lost result in a reachability test exchange,
and that is why i was wondering if it wouldn't make sense to define a
"no-context" error message as a rply to a reachability test request packet.
That is one particular solution with strong coupling between the test
protocol and the state management.
But don't we want to retain the possibility to test locator pairs for
initial contact, i.e. before a context is established between the peers?
And handle the above case of unidirectional locator pairs?
But i fail to understand how the node that has lost the state can
identify that a data packet belongs to a non existent shim state....
By seeing that the <source locator, destination locator, context tag>
doesn't match any existing context?
I suspect we want that capability for robustness in any case.
I mean, i guess that a first element that is relevant here is where are
we going to carry the context tag.
If the context tag is carried in a extension header or dest option, then
i can see that if a node receives an packet with one of those, can
easily detect that there is no context associated. (note that in this
case, the context loss is only detected in the case where the locators
used for the communication differ from the ULIDs, i.e. the extension
header dst option is included in the packet)
If the context tag is included in the flow label, then i don't see how a
node that receives the data packet can determine that the packet is
associated to a shim context that is no longer there. At this point, i
gues that as you mentioned in a previous mail, the data packet would be
silently discarded, right?
If the context tag is carried as a flow label, I still think we need a
way to tell the receiver "this is a shim6 packet". For robustness
reasons I think the fact that the packet needs shim6 processing should
There has been proposals in multi6 which suggested doing this without
making the packets larger by defining a set of new nexthdr values with
Not having that "shim6" bit when the flow label is used as a context tag
can easily result in hard to diagnose errors. We might have errors due
to some middlebox messing with the data packets (a TCP relay for
instance), but that leaves the shim6 test packets alone. If the TCP
relay doesn't preserve the flow label, then the packets would be dropped
due to TCP checksum errors (since the ULID rewrite didn't happen), but
the test protocol would say that everything is fine.
I think that at this point is clear to me that if we define a no-context
error message, this message should be defined as a reply to a packet
that refers to that context and it should include enough information
about this initial packet to verify that is a reply to that packet.
The no-context error message cannot be issued spontaneously by a node.