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 server that aggressively garbage-collects shim6 context to a multihomed shim6 client.The client at some point establishes shim6 context, which the serverpromptly 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 the last packet. Since the server has no more data to send, the keepalive timer expires. This promptsthe 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 anyadditional state on their servers, especially if it happens repeatedly andprevents 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 finnish 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. 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...
Do you think this would be a good approach?
OTOH, it may make sense to explicitly state in the draft what a payloadpacket is...Yeah, I think we need to at least talk about it there, as it seemed ratherambiguous to me.
In the failure detection draft you mean, right? (not in the shim6 proto spec)
regards, marcelo
-Scott