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: Ben Campbell <[email-masked]>
Date: Tue, 09 Sep 2003 12:50:12 -0500

The value of 1 minute was intended to be a strawman to get people to 
start talking about a reasonable value that balances bandwidth concerns 
against the desire to minimize state kept at a relay. So far, that has 
not occured. I am very open to any better approached to selecting the 
value.

I do note that a keepalive message can be quite small (less than 25 
bytes + lower layer overhead, depending on how you select your message 
ID value.) This means that if you stayed connected to a dormant chat 
room for 24 hours, you would only be using < 100k, or around 2 cents at 
SprintPCS's rate for "additional" data of $0.002 per kilobyte. (I make 
no claims to whether this is a representative rate.)

The idea of a non-negotiable value came out of the room consensus at the 
intermim meeting, and has been around for a while now. Negotiating the 
timer would add a lot of complexity in the 2 relay use case. The EXP 
time is used for a completely different purpose, and its value is never 
communicated to the visitor.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 09 Sep 2003 12:50:12 -0500

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 10 Sep 2003 11:48:08 +0300

Ben:

I mostly disagree with your analysis.

First, you say that the session timer value is never communicated to the 
visitor. This is not what the draft says, at least I can see in the 
examples that the EXP time is conveyed in the 200 OK answer for the 
VISIT method (see section 8.2 in the draft, steps 4 and 5). And I 
believe this is the right thing to do.

Second, I still don't find a difference between the session timer and 
the inactivity timer. You just mentioned that the session timer is used 
for a completely different purpose, without mention what the purposes of 
both timers are. IMHO having a session timer in place solves all the 
timing issues. If not, please, clarify what timing issue is the 
inactivity timer trying to solve.

Third, paying some cents for the inactivity timer is something we want 
to avoid. But depending on the network technology and the previous 
state, sizing resources to send this inactivity timer might be expensive 
for the network, not necessarily for the user. It may take some time, 
and use resources somewhere else. Certainly this is something we should 
try to avoid.

/Miguel

Ben Campbell wrote:

>> Just by reading the message session draft, I have found the 
>> description of a 1 minute session inactivity timer (see section 7.4.5)
>>
>> 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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 10 Sep 2003 11:48:08 +0300

Ben:

/Miguel

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2003 09:33:57 -0500

> believe this is the right thing to do.

The draft actually forbids this in the normative text. The presence Exp 
in the example VISIT responses is an error in the draft.

> inactivity timer trying to solve.

The Exp timer (refered to as the pre-visit timer in the draft) is only 
used to control how long a hosting relay will wait for a visit to occur.

For historical background, earlier versions of the draft required 
refreshing of BIND and VISIT, and Exp acted much like the Expires header 
in SIP. When we moved to an inactivity timeout, we demoted this to its 
present purpose. We discussed removing it entirely, but enough people 
thought it was useful in its current role.

> and use resources somewhere else. Certainly this is something we should 

This point was discussed extensively in the interim meeting, and the 
consensus of the room was that alternatives to this approach either 
required more resources, or added significant complexity. I still 
consider the 1 minute value as an open issue, though.

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?

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

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2003 09:33:57 -0500

Thanks!

Ben.