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

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 05 Sep 2003 10:37:52 +0300

Hi:

Just by reading the message session draft, I have found the description 
of a 1 minute session inactivity timer (see section 7.4.5)

I am a bit shocked with this requirement. So does it mean that if I 
establish an MSRP session to a chat room that is in dormant state, I 
will have to send empty SEND primitives every minute just to refresh the 
state??? Sounds weird... Specially if I am paying for the bytes that I 
send and if I have to seize resources for sending this timer... it 
sounds completely unefficient.

If I understand correctly (correct me if I am wrong), MSRP provides two 
timers: the session timer negotiated in the Exp header and the 
inactivity timer harcoded to 1 minute.

The question is do we really need both timers??? Why isn't the session 
timer enough for the purpose of supervising the session???

/Miguel

-- 
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

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 10 Sep 2003 16:11:30 +0100

<<see comments in-line>>

>
>So, this brings up a couple of questions for the list in general:
>
>1) Do others agree with Miguel that we should make the inactivity
>timeout negotiable?

[Chris Boulton] I must admit that I do have reservations regarding a one
minute session timer.  Yes, this may only produce a minimal amount of
extra chargeable bytes BUT it does indicate a slight deficiency in the
solution.   

>
>2) If not, can anyone suggest a better way to choose the standard
value?

[Chris Boulton] As mentioned earlier, negotiation maybe increase
complexity BUT I will throw this into the pot as a potential solution.
On receiving the 200 OK to the SIP INVITE the initiator of the session
will send a SIP ACK - It will also send an MSRP SEND which contains a
new header 'sess-timer' (*Note - it can use this header at any time
during the session).  This new header has a default value so that if
this method is not used, the default will apply (e.g. 1 minute).  On
receiving the SEND (whether it be at the start of the session or mid
session), the receiving MSRP client can either respond positively to the
MSRP SEND request, indicating that it accepts the timer OR it rejects
with a new MSRP error response code.  The new response code will
indicate the range of seconds that the client is willing to accept (max
+ min values in a header).  If the initiator does not like this range it
terminates the session, sending a SIP BYE ELSE it retransmits the send
request with an alternative value in the 'ses-timer' header which falls
into the range.  There probably should be a limit on the number of times
the client retries to avoid DOS attacks.  

>Thanks!
>Ben.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 11 Sep 2003 10:45:21 +0100

<<See comments>>

>-----Original Message-----
>From: Ben Campbell [mailto:[email-masked]]
>Sent: 10 September 2003 16:41
>To: Chris Boulton
>Cc: Miguel A. Garcia; [email-masked]
>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP
>
>This appears to be an e2e negotiation that would work fine if the
>endpoints are the only stakeholders. However, I think that any relays
>would want a say in this as well. In order to do that, we would need to
>negotiate someting in the BIND request. That value could be sent to the
>visitor in the sdp, or as the return code from the visit request.

[Chris Boulton] Ben, I might be missing something here so feel free to
SHOUT.  I personally don't see why relays should be a stakeholder in a
predominantly e2e solution.  The only reason for the introduction of
relays was to overcome the case where clients could not connect TCP
sockets.  As it stands, the client currently is responsible for
refreshing + terminating state using BIND requests at a relay unless the
'Exp' header expires.  I don't see anything wrong with allowing the end
client to be responsible, as I proposed.  If an implementer wishes to
restrict a MAX time that a state can be alive at a relay, then it could
introduce a local policy to terminate once the threshold is reached THEN
respond with a 481 response.

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Sep 2003 11:31:35 -0500

> 1) Do others agree with Miguel that we should make the inactivity 

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

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 11 Sep 2003 19:08:25 +0100

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.

J)��隊X��X��(��W�z��m��?�0�'�~���f��f��X��)ߣ�"��^

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 17 Sep 2003 09:33:29 +0100

I thought the main driver fot this were networks where carriers are charging on a 'per-byte' basis.  Yes I agree the impact would be minimal BUT there should be no real charging impact.
 
Chris.

	-----Original Message----- 
	From: Cullen Jennings [mailto:[email-masked]] 
	Sent: Tue 16/09/2003 20:02 
	To: Chris Boulton; Ben Campbell; Adam Roach 
	Cc: Miguel A. Garcia; [email-masked] 
	Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP

	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.
	>
	>
	> J)

¢š™^™¨¥Šx%ŠËRŠjez'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËb�ú?²)©•

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 17 Sep 2003 09:33:29 +0100

Chris.

	-----Original Message----- 
	From: Cullen Jennings [mailto:[email-masked]] 
	Sent: Tue 16/09/2003 20:02 
	To: Chris Boulton; Ben Campbell; Adam Roach 
	Cc: Miguel A. Garcia; [email-masked] 
	Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP

	
	Cullen