Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)

From: "Christian Huitema" <[email-masked]>
Date: Wed, 4 Apr 2001 15:11:14 -0700

The session timer belongs to the category of "safety belts" tools. It
should be though as a last resort tool, to wipe up sessions that are
left open after both clients die, or one single client dies and the
other is too dumb to notice. (If any of the client is up and notices,
e.g. through absence of RTP and RTCP traffic, that client sends a BYE,
and the problem is solved; same is true if there is a human listening to
a phone through a gateway.)

Let's first consider the standard RTCP interval of 5 seconds. I would
not want to drop a session just because I lost one RTCP packet, so I
would wait for at least 10 seconds, or more likely 30 seconds, before
raising an alarm. Setting a session timer to less than 30 seconds should
be a protocol violation, causing some 4xx error. 

Let's then consider the average duration of a business call, typically
between one or a few minutes. Enforcing a heartbeat creates an extra
load on the proxies. If the timer is of the same duration as the average
call, the extra load is about 33% -- add a heart beat + response to a
typical exchange of INVITE/180/200/ACK/BYE/200. I personally find 33% a
bit large for the added value; I would rather aim for a few percents,
i.e. a session timer of at least 10 minutes.

-- Christian Huitema 

> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]]
> >
> > Yes, but if each of the proxies along the path knows what its
> > safe "lower
> > bound" on retransmits is and refuses to pass a session timer
> > with a value
> > lower than the safety threshold, the attack can be avoided.
> > This isn't a
> > protocol change.
> 
> No, thats not true. Consider the case of:
> 
> UA1 -> P1 -> P2 -> P3 -> UA2
> 
> UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it
too
> low. P2 increases it. Now the request goes to P3, which reduces it to
an
> even lower value. This is forwarded to UA2, which reflects it in the
> response, and its forwarded upstream towards UA1. I guess P2 could
discard
> the response, but thats not really a good thing, since the transaction
> will
> end up timing out. Even then, rogue P1 could reduce the timer value in
the
> response once its passed P2.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> [email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 9 Apr 2001 18:45:57 -0500

Christian's analysis is excellent, where session-timer is used by devices
supporting telephony applications.

But that's not all SIP does -- and I suggest that the proxies in the middle
really shouldn't care about or be bounded by the limits of the telephony
application.

What are the implications if the negotiated session is a DOOM game? What if
it's a one-frame-per-hour security camera? What about ten-second
microvideos? What happends when we apply SIP to interplanetary traffic,
where Speed-of-Light assures some really long delays? (Yes, I know Vint is
working with JPL on Interplanetary Internet -- I hope to use SIP to call
somebody on Mars within my lifetime -- and I hope we have IPv6 by then . .
.).

The real questions are, what is the shortest reasonable period that one can
expect SIP signaling to complete within, and for how many of multiples of
this  time periods do we wish to hold state in stateful devices?

I argue that minimum session-timer timer values would be more appropriately
derived from the fundamental timers of SIP signaling, not from
application-specific timers.

One might envision a chain of 100 stateful proxies between two endpoints.
Assuming that the maximal response-reply cycle period of roughly 20 seconds
results at each hop, one might have to hold state for quite a long time
before one decided on giving up on the call . . .

However, I suspect any such estimation method would still end up with
minimal timers for ANY network topology in the roughly one-minute range . .
.

One could readily prevent Session-Timer from being used in a fashion
exceeding this value by using only realtive time descriptions and expressing
those times in mutiples of the "minimum" value. For example, assuming we use
minutes, the smallest expressible timer  is 1 minute, which fiys within the
bounds I assumed earlier in this message. Or we could use 100s of seconds .
. .

On the other hand, history shows that protocols that assume "slowness" in
the world often have to be "sped up" to deal with the
multiple-order-of-magnitude changes that occur in the environment every few
years. Perhaps in a few years we'll be dealing with proxies handling a
billion calls per second and only 10ms of  state capacity . . .

--
Dean

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; "Dean Willis"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 04, 2001 5:11 PM
Subject: RE: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)