RE: draft-ietf-mmusic-sip-session-timer-00.txt

["Dean Willis" <[e-mail]>]

Jonathan wrote:
> Dean Willis wrote:
> >
> > How about renewing at 1/2 T, where T is the minimum time unit on the
> > proxy chain. If T is greater than 1 minute or so, this
. . .
>
> I'm not sure we need to specify anything for this. Sending at
> 1/2T, then
> 3/2T, 5/2 T, etc., only delays the problem by T. What I mean
> is lets say
> each proxy starts its timer when the response comes down the proxy
> chain, at t=0. Now, the client resends at 1/2 T, which is
> fast enough to
> refresh things. Now, each proxy expects to see the next before 3/2 T.
> THe client sends at 3/2 T, but because of timing
> inconsistencies, packet
> loss, clock skew, and latencies, it comes too late for some servers.

Not quite what I meant.

If we have duration T, then refresh interval is 1/2 T -- so client
refreshes at 1/2 T, 2/2 T, 3/2 T, 4/2 T, and so on -- always starting
1/2 T before expiration of the current timers.


> Instead, the interval should be treated as the frequency the
> client will
> refresh at. Servers really should not time out a session unless no
> refresh is received for 3/2 to 2 times this amount of time.
> Its like the
> RTCP refresh interval. A user is not timed out in RTP unless
> they don't
> send an RTCP packet for 5 times the interval. You need this to account
> for losses, skew, and so on.

Only problem -- if you are dealing with 50,000 or so connections through
a stateful proxy, you want to close sessions as soon as technically
feasible. If we extend the session life to multiple T after the session
termination, then the base value of T must be fairly small, thereby
making for lots of refresh cycles.

If on the other hand the timeout is 2T with a reasonably large value of
T, then the behavior is identical to my original suggestions except by a
constant of 2. That is, a given value t of T under the first proposal
would behave exactly as value 1/2t under the counterproposal. No real
difference there.

--
Dean