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

Re: about R1bis




El 11/11/2005, a las 17:16, Pierre Baume escribió:

Hi Marcelo,

On 11/10/05, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
[...]

2 - Do we want that the failure detection probes trigger a context
recovery mechanisms i.e. R1bis?

In the considered scenario, when the initial path between the ulids is
working fine, the transmission of probes to verify that the current
path is working may result in triggering the context recovery
mechanisms i.e. the transmission of a R1bis packet. Such behaviour may
not be the optimum for dealing with the case of the server that wants
to discard the clients contexts, in order to let the clients to handle
fault tolernace (the scenario suggested by Iljitsch in the ams
meeting). A possibility for dealing with this would be that probes that verify that the current path is working do not contain context specific
information (as oposed to probes used for exploring the alternative
paths, that in order to be used for flooding prevention must carry
context specific information). I know that this would imply a change in
the failure detection protocol in Jari's draft, but maybe it would be
worth to consider this issue.

Regards, marcelo

PS: agree that interaction with context confusion mechanisms needs to
be be clearly understood in order to get the full picture about this
R1bis thing
[...]

  Maybe it would help to have a message for servers to indicate that
they wish to go quiet and drop the context. This could also interrupt
probing.


But in this case, the client wouldn't be able to use the probing for detecting failures, right? I guess that the optimal would be that the server reply to probes, but that it does not verify that they belong to a given context. IMHO this present no security issues, as long as these are probes to verify that the current path is still working. It is completelly different story if these are reachability tests perfromed before a rehoming

regards, marcelo


Pierre.