Re: Shim6 failure recovery after garbage collection

[Scott Leibrand <sleibrand@internap.com>]

On 03/28/06 at 9:06am +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> El 27/03/2006, a las 23:54, Scott Leibrand escribió:
>
> > I expressed the opinion that it would be nice if a heavily loaded
> > server could aggressively garbage collect shim6 state after initial
> > context establishment, and rely on the client to perform failure and
> > reachability detection and initiate context re-establishment if a
> > failure is detected.
>
> This point was proposed by Iljitsch in the Manchester design team
> meeting and the protocol was kind of designed to support this feature

Good, good.

> > I was also concerned whether REAP (as defined in
> > draft-ietf-shim6-failure-detection-03.txt) would require frequent
> > context re-establishment if one side were to garbage collect.
> > However, if I assume that TCP ACKs are considered "payload" packets in
> > the context of resetting the REAP keepalive timer, then that is not an
> > issue, because that timer will only be started upon sending a TCP data
> > packet, and will be reset by that data packet's ACK.
>
> yes, this i my understanding. TCP ACKs do reset the REAP timer
>
> > In any event, I think that draft-ietf-shim6-failure-detection-03.txt
> > needs to better define "payload packet" to differentiate between data
> > packets (which IMO should both set and reset the keepalive timer) and
> > ACK packets (which IMO should only reset the keepalive timer, not
> > start it, or it will cause unnecessary context re-establishment).
>
> I am not sure about this point...
> I mean, as i understand it, payload packets for the shim are any packet
> generated by any ULP, it doesn't matter if these contain ULP signalling
> information or actual user data information. As far as the shim is
> concerned any packet generated by a layer that is above the shim are
> payload packets.
> I mean, i don't think the shim should try to understand ULP.

I can see the virtue in that approach, particularly in terms of layer
separation...

> So, for me a TCP ACK is just another payload packet that is processed
> as any other, i.e. set and reset timer
>
> 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.

> 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.

-Scott