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

From: [email-masked]
Date: Thu, 9 Oct 2003 16:29:16 +0300

That's not a bad idea. The only drawback I see is that if, for some currently unforeseeable reason, the policy at the Relay requires the 2 timers to be different. Eg: the relay is willing to only wait a very short time to receive the VISIT but is willing to wait the full 10 mins for inactivity.

Another related question: Can someone remind me why those timer values are not left as Relay policy? If not, why isn't the pre-visit timer a default value of x mins like we have for the inactivity timer?

Regards,
Hisham

> -----Original Message-----
> From: ext Miguel A. Garcia [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 1:56 AM
> To: Ben Campbell
> Cc: Cullen Jennings; Chris Boulton; Adam Roach; [email-masked]
> Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP
> 
> 
> 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:
> 
> > (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
> > 
> > 
> 
> -- 
> 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
> 
> 
> _______________________________________________
> 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: [email-masked]
Date: Thu, 9 Oct 2003 16:29:16 +0300

Regards,
Hisham

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Oct 2003 10:48:27 -0500

We went over the scenarios involving negotiated timers
for several hours in Ottawa. With up to four interested
parties involved (two endpoints, up to two relays), it's
a nearly intractable problem. The consensus at that meeting
(which, if I recall correctly, was validated on this mailing
list) was that the additional complexity required to
negotiate a timer (as opposed to using a fixed value) wasn't
even close to being justified by the miniscule flexibility
that it provides.

In my experience, the most effective way to kill progress
is to continually revisit decisions that have already been
made.

Please don't.

/a

> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: Wednesday, October 08, 2003 17:56
> To: Ben Campbell

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Oct 2003 10:48:27 -0500

Please don't.

/a