[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shim6 failure recovery after garbage collection
El 27/03/2006, a las 23:54, Scott Leibrand escribió:
In a private discussion at IETF in Dallas, I was discussing with
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
detection and initiate context re-establishment if a failure is
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
be able to convince potential implementors to turn on basic shim6
by default, with the understanding that implementors can aggressively
discard shim6 context state (and not initiate shim6 context
if the implementation doesn't have multiple locators or otherwise
need the capabilities shim6 provides. This would (properly, IMO) push
responsibility for context tracking, failure detection and reachability
exploration to the multihomed host that stands to benefit most from
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?
I was also concerned whether REAP (as defined in
draft-ietf-shim6-failure-detection-03.txt) would require frequent
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
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
to better define "payload packet" to differentiate between data packets
(which IMO should both set and reset the keepalive timer) and ACK
(which IMO should only reset the keepalive timer, not start it, or it
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
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