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

Re: about R1bis

Hi Pierre,

El 11/11/2005, a las 23:19, Pierre Baume escribió:


Marcelo,

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


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

[...]


  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


  Well, I'm not sure that I understand the scenarios.



i am not sure i understand the cases you are pointing out below... :-(
anyway, here is my interpretation


  If a server drops the context when it has nothing to send to a
client for a while, how can it resume communication, if needed?
i guess that the idea is that the server basically replies to queries performed by the client, so it is never the case where the server wants to initiate a communication without a prior contact by the client 



  If the above isn't a problem, what is the benefit for a client to
try and detect failures before it has something (else than a probe) to
send to a server?



i see it as follows:

Client C and server S
C establishes a communication with S
A shim context is created between C and S
S drops the context (so it reduces the amount of memory consumed by the shim) (i.e. because of the many clients) So far, there is no failures, so there is no translation being made, so, the server does not need the state to process packets. However, because S does not have any more shim state, it will not perform any failure detection for this communication. Failure detection is completely in the hands of C. In particular S won't send periodic probes to C to notify that the address pair is working ok Since S won't be sending periodic probes, C will need to verify that the address pair is working each time S is silent for while. This is performed through a reachability test of the current address pair. The problem is that as currently defined, a reachability test refers to a particular context, so this would trigger an R1bis, which would result in reestablishing the context that S has dropped on purpose. The point is that at this point there is no need to reestablish the context, since there is no failure yet. So the resulting behaviour is that we would be creating and tearing down contexts periodically, which doesn't seem to be the desired result. 

I can see two solutions for this problem:
- One would be that reachability test for current locator pair does not carry any context specific information. This afaict does not presents any security issues - the other is that the client should not try to reestablish the context upon the reception of an R1bis as a reply to the reachability test of the current locator pair. In this case, if the client knows that the server drops context on purpose, the client only need to find out if the current locator pair is working. Receiving a R1bis packet confirms that the current locator pair is working, so no need to reestablish the context at this point. I wonder if this is one option that needs to be negotiated or if this should be the default behaviour or we should leave this open to local policy? 



  Thanks for your patience. :-)



No, thank you for making interesting questions


Regards, marcelo


Pierre.