El 04/04/2006, a las 18:46, Scott Leibrand escribió:
On 04/04/06 at 1:17pm +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:El 30/03/2006, a las 21:42, Scott Leibrand escribió:Do you see any problems with this behaviour?Yes, I do. Say you have a one-way data transfer, from a busy serverthat aggressively garbage-collects shim6 context to a multihomed shim6client. The client at some point establishes shim6 context, which the server promptly discards. The client requests a bunch of data, which the server sends. The last data packet from the server clears the keepalive timer, but it is restarted again when the client ACKs thelast packet. Since the server has no more data to send, the keepalivetimer expires. This prompts the client to send a shim6 keepalive, which in turn generates an R1bis message and re-establishes the context. IMO this unnecessary context re-establishment could pose a problem for sites who can't afford any additional state on their servers, especially if it happens repeatedly and prevents the server from garbage-collecting the state a second time.yes, i remember Jari commenting something about this issue, that it seems that a couple of additional packets were needed to finish the process... And yes, this seems to have bad impact on this case where server's aggressively garbage collect So i agree this is an issue... I wonder if it would be ok not to send R1bis as reply to keepalive message, (but send it as a reply to probe messages) In this case, the reception of a keepalive wouldn't trigger a R1bis, which would deal with this case.But wouldn't the lack of a keepalive cause the keepalive timer on the sending side to time out?
ok let me recap the scenario here. We have a client C and a server S. The establish a communication and the establish a shim6 context S rapidly discards the state while C keeps itSuppose that this was a TCP connection so that the packet exchenge is such that there is no need for additional keepalive messages during the communication.
The problem that you pointed out was about what happens when the communications ends, that it would require some keepalive exchange.
Let's first consider the case where the last TCP ack was sent by the Server. In this case, S doesn't do anything because it doesn't have any context, but C, upon the reception of this packet, starts the timer to send a keepalive. since C has no more data traffic to send, then it generates a keepalive. When S receives the keepalive, It would simply drop it (if we asume the modification proposed above), and the communication ends gracefully without need of re establishing the lost context.
However, if we consider the other scenario, where it is the client who sends the last TCP, the situation is different. C sends the last TCP ACK and starts the timer, waiting for incoming traffic. S receives the TCP ACK but doesn't send a keepalive, because it doesn't have any shim6 state. C doesn't receives any traffic so it starts the full exploration procedure, which would result in restoring the lost context.
So, not replying a R1bis to keepalive messages only solves one half of the problem, when the last packet was generated by the server.
I don't know how to deal with the other case though... any ideas?
In the case that the lost context needs to be recovered, the impact is that this is delayed until the peer decides to perform an exploration...And wouldn't the expiration of the keepalive timer trigger an exploration?Do you think this would be a good approach?OTOH, it may make sense to explicitly state in the draft what a payload packet is...Yeah, I think we need to at least talk about it there, as it seemed rather ambiguous to me.In the failure detection draft you mean, right? (not in the shim6 protospec)Wherever it is we define behavior based on payload packets, we should define such packets. I don't recall which draft that's in...
well, been rereading the faildet draft and it states that: This document defines the protocol mechanisms only for the third task. We employ a technique called Forced Bidirectional Detection (FBD). Reachability for the currently used address pair in a shim context is determined by making sure that whenever there is data traffic in one direction, there is also traffic in the other direction. This can be data traffic as well, but also transport layer acknowledgments or a REAP reachability keepalive if there is no other traffic. This way, it is no longer possible to have traffic in only one direction, so whenever there is data traffic going out, but there are no return packets, there must be a failure, so the full path exploration mechanism is started. wouldn't this be enough? regards, marcelo
-Scott