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

Re: Shim6 failure recovery after garbage collection

Hi Scott,


El 27/03/2006, a las 23:54, Scott Leibrand escribió:
In a private discussion at IETF in Dallas, I was discussing with someone 
the impact on a content provider's server of implementing shim6.  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. 



Exactly...
This point was proposed by Iljitsch in the Manchester design team meeting and the protocol was kind of designed to support this feature
If such behavior is supported by the protocol, we're much more likely to be able to convince potential implementors to turn on basic shim6 support 
by default, with the understanding that implementors can aggressively
discard shim6 context state (and not initiate shim6 context negotiation) if the implementation doesn't have multiple locators or otherwise doesn't need the capabilities shim6 provides. This would (properly, IMO) push the 
responsibility for context tracking, failure detection and reachability
exploration to the multihomed host that stands to benefit most from shim6 
and wants to run it in the first place.

My understanding after re-reading of the protocol, particularly the
R1bis/I2bis message exchange sections, is that context re-establishment
can occur (within approx. 2 RTTs of failure detection) even if the
original ULID-ULID connection has failed and one side has discarded the
context state.  Does that match others' understanding of the process?



exactly


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.
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?
OTOH, it may make sense to explicitly state in the draft what a payload packet is... 

Regards, marcelo



-Scott