Re: Possible modification to the shim6 base spec (was:Re: Shim6 failure recovery after garbage collection)

[Scott Leibrand <sleibrand@internap.com>]

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 server
> > that aggressively garbage-collects shim6 context to a multihomed shim6
> > client. 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 the
> > last packet.  Since the server has no more data to send, the keepalive
> > timer 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?

> 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 proto
> spec)

Wherever it is we define behavior based on payload packets, we should
define such packets.  I don't recall which draft that's in...

-Scott