Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP

From: Ben Campbell <[email-masked]>
Date: Wed, 08 Oct 2003 16:55:41 -0500

(Waking up a sleeping thread...)

Okay, I will attempt to at least rationalize a number:

The purpose of this timeout in the first place is to allow a hosting 
device to shed "stale" sessions. This is primarily important to relays, 
since they are likely to be hosting a whole bunch of sessions at any one 
time. The lower the timer value, the more efficiently they can do this.

_But_, in the normal use case, the hosting endpoint will explicitly 
destroy the session. So "stale" sessions only really happen when the 
hosting endpoint screws up for some reason. Hopefully, we can assume 
this is at least uncommon, if not rare. Therefore the timer does not 
need to be particularly agressive.

We currently have 2 votes for 12 minutes, which I find reasonable based 
on this rationale. I propose 10 minutes to the inevitable headscratching 
on why we chose 12 rather than 10 or 15. Of course, if someone would 
really like something like 12 minutes and 11.23 seconds, feel free to 
make the argument.

This, however, brings up another issue. It occurred to me this 
afternoon, that while we do explicitly tell a hosting relay to destroy a 
session, we do not explicitly tell a _visiting_ relay. A visiting relay 
can infer this from the host closing the TCP connection. Is this good 
enough?

Cullen Jennings wrote:

> I think things between 1 and 60 sound pretty good but ...
> 
> What we really need here is an argument why some number x is a good number.
> 
> Cullen
> 
> 
> On 9/11/03 11:08, "Chris Boulton" <[email-masked]> wrote:
> 
> 
>>ok - If it must be his method I'll see Adams bid of 12 (and maybe even raise
>>it ;-) .  I think that it is a good compromise of traffic vs session clean up.
>>
>>Chris.
>>
>>
>>-----Original Message-----
>>From: Ben Campbell [mailto:[email-masked]]
>>Sent: Thu 11/09/2003 18:16
>>To: Adam Roach 
>>Cc: Miguel A. Garcia; [email-masked]
>>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP
>>
>>
>>
>>On reflection, I think I agree that a higher value than 1 minute makes
>>sense. One use case I expect to see a lot for message sessions is the
>>chat room, or text conference, where it will be common for one
>>participant to receive a lot more than they send.
>>
>>Of course, at the same time, larger numbers reduce the ability of a
>>relay to prune dead sessions.
>>
>>So I bid 5 minutes.
>>
>>Adam Roach wrote:
>>
>>>Ben Campbell [mailto:[email-masked]] writes:
>>>
>>>
>>>
>>>>1) Do others agree with Miguel that we should make the inactivity
>>>>timeout negotiable?
>>>
>>>
>>>Having tried to go down this path several times, I want to
>>>emphasize that I am very strongly opposed to any mechanism
>>>for negotiation of this timeout.
>>>
>>>
>>>
>>>>2) If not, can anyone suggest a better way to choose the
>>>>standard value?
>>>
>>>
>>>Nope. One minute sounds good. One hour sounds good. I don't
>>>think I'd want to go much outside that range.
>>>
>>>However, it sounds like there's some objection to something
>>>as small as one minute, so we need to negotiate an arbitrary
>>>value here on the list. I'll start the bidding at twelve
>>>minutes.
>>>
>>>/a
>>
>>
>>_______________________________________________
>>Simple mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>>
>>J)
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Wed, 08 Oct 2003 16:55:41 -0500

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 09 Oct 2003 01:55:49 +0300

Hi Ben:

I believe something on the order of 10 minutes sound better than the 
current 1 minute. So I wouldn't mind go for it.

However, I have an alternative proposal. I would apologize if you 
already discuss it.

Currently, as you mentioned previously, there are two timers: the 
pre-visit timer that controls the maximum time the MSRP relay will wait 
for a VISIT, and the session timer that controls the inactivity time 
after the BIND/VISIT procedure.

I am not convinced that these two timers are different. What the MSRP 
relay is interested on is to get some activity from any of the endpoints 
so that the MSRP relay is aware that the session is still alive. Whether 
the data is a VISIT or SEND is irrelevant for the MSRP relay. So my 
proposal would be to simplify the timer management in the MSRP relay and 
go for a single timer, negotiatedin the Exp header (similar to the 
expiration timer of a registration in SIP). As a side effect, we could 
use the current Exp header, and send it to the visitor in a 200 OK for a 
VISIT. So the visitor is aware of the timer and (if not dead) will be 
able to refresh the session.

I am pretty sure that this proposal will create a flare... but I feel 
provocative today ;-)

Regards,

            Miguel

Ben Campbell wrote:

>>> To: Adam Roach Cc: Miguel A. Garcia; [email-masked]

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 514 0002

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 09 Oct 2003 01:55:49 +0300

Hi Ben:

Regards,

            Miguel