Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt

From: [email-masked] (Patrice Calhoun)
Date: Wed, 17 Feb 1999 05:24:03 -0800

>Patrice Calhoun wrote:
>> 
>> I am sure that we will get to that one day :). However, I would like to
>> understand why this would not work.
>> 
>> Here is an example:
>> 
>>     SC1 ------> SS1 --------> SS2 -------> SC2
>> 
>> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
>> Sip Server (SS1). The server adds some timeout information to the request
>> and passes this along to SS2. If SS2 is satisfied with the timeout
>information
>> added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
>> SS2 will modify the timeout value and pass the INVITE to SC2.
>> 
>> SC2 must response with an ACK. This ACK could include the timeout period, and
>> could be checked by either SIP Server to ensure that it meets its local
>> policy. The Sip Servers will assume that the session is destroyed within the
>> timeout period, unless SC1 re-sends another INVITE message.
>
>Thats pretty much whats specified in the Donovan draft. THe difference
>is that the timeout doesn't get reflected in the ACK. THis is not
>needed, though. The timeout should be echoed in the response, which will
>be seen by both servers. I think this works just fine. The only issue
>has to do with backwards compatibility - knowing that SC1 will
>understand the timer in the response.

ok, but what is a client sends a timeout of infinity, and the server's policy
does not allow it to maintain soft state that long for a single session?

PatC
>
>-Jonathan R.
>
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: [email-masked]
>URL: http://www.cs.columbia.edu/~jdrosen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Feb 1999 10:24:21 -0500

> does not allow it to maintain soft state that long for a single session?

I'm not sure what it says in the draft; in a prior email I suggested
that each proxy along the chain can decrease (but not increase) the
value of the timer. The result is that the timer in the response
represents the minimal refresh interval needed by all servers. By
definition, this means that every server will receive a refresh in time
(not true if servers are allowed to increase the interval).

-Jonathan R.

---

From: Lewis McCarthy <[email-masked]>
Date: Wed, 17 Feb 1999 15:40:57 -0500

Jonathan Rosenberg writes:
> in a prior email I suggested

Would there be a need in this approach to account for the delay 
introduced by the length of the chain?  Suppose the proxy farthest down 
the chain from the refreshing client happens to want the smallest 
timeout period T of all the proxies.  If the client waits about T time
before sending the refresh to the nearest proxy, the distant proxy's
timer may expire before it receives that refresh. 

-Lewis				http://www.cs.umass.edu/~lmccarth
-- 
"we have to yet really seriously debate the constitutional issues and 
whether or not we're willing to give up more freedom in order to have 
more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 Feb 1999 18:05:01 -0600

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 should preclude
accidental expirations as the renewal propagates. As T increases, this
gives us a nice backoff on renewals . . .

--
Dean

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Lewis McCarthy
> Sent: Wednesday, February 17, 1999 2:41 PM
> To: MMUSIC WG List
> Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Feb 1999 23:39:32 -0500

> gives us a nice backoff on renewals . . .

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.

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.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 18 Feb 1999 10:53:54 -0600

Jonathan wrote:
> > proxy chain. If T is greater than 1 minute or so, this
. . .
> 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.

> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Feb 1999 15:42:33 -0500

> 1/2 T before expiration of the current timers.

Sorry for my misunderstanding. I believe this is pretty much what I was
suggesting. Whether the client sends at a lower rate than the
Session-Timer value, and servers timeout using the Session-Timer value,
or clients send at Session-Timer, and serves timeout with an interval
larger, is 6 on one hand, 1/2 a dozen on the other. It just needs to be
consistent.

-Jonathan R.