Subject: Re: Proxy Server Inconsistencies

From: Sean Olson <[email-masked]>
Date: Fri, 29 Jan 1999 10:23:11 -0600 (CST)

> 
> Jonathan Rosenberg wrote:
> > 
> > Sean Olson wrote:
> > >
> ...
> > > Both options require approximately the same complexity. The PING method
> > > has the advantage of potentially making things easier for the client
> > > since the client would only need to respond to PING requests and would not
> > > need to maintain an internal session timer ( though there are good reasons
> > > for doing so anyway ).
> > 
> > I'm not sure about the complexity issue. I think using PING with caching
> > (other proxies cache the keepalive state and respond with it instead of
> > forwarding the PING) will probably in the end be more complex. We'll
> > have to deal with cache consistency and invalidation issues. I think
> > these will be quite hard in the end - consider the following:
> > 
> 
> If the question is where to put the complexity, I'd vote for putting it
> in the client/user agent. The reason for this is that a proxy probably
> will handle more calls per second than the client, and thus has pretty
> much to do anyway. Also, a proxy that keeps state for the duration of a
> session rather than a SIP transaction is probably the most resource
> demanding implementation of SIP, hence we should try to remove instead
> of add burdon into it.
> 
> I think, for example, an ISP that has a SIP billing proxy server can
> have _many_  customers in calls simultaneously. This will require a call
> record for each on-going call, which then requires liveness test, say
> once a minute. With the PING approach and 6000 on-going calls, the proxy
> has to initiate a PING transaction 100 times per second, besides the
> normal proxy tasks.
> 
> The less complex the proxy is, the larger number of sessions can be
> handled.
> 
> /Lars
> 
> -- 
> Lars Berggren       <[email-masked]>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414

I agree that we should remove as much complexity from the proxy as possible.
The INVITE approach, however, requires as much complexity: timers, caching,
and validation. The primary difference I see between the two approaches is that
with the PING method, we can simplify the client. Not much we can do for
the stateful proxy. This isn't a simple problem. A greater problem with the
PING approach is that it can require double the number of messages unless
a "Frequency:" header can be associated with the PING request.

Sean

-----------------------------------------------------------------
Sean Olson                             Ericsson Inc.  
E-mail: [email-masked]

---

From: Tim Dorcey <[email-masked]>
Date: Fri, 29 Jan 1999 14:07:19 -0700

>with the PING method, we can simplify the client. Not much we can do for

I am not familiar with all of the functions of the proxy, but I can't see
how the re-INVITE introduces additional complexity.  The proxy needs to
handle repeated INVITEs at the session initiation phase anyway.  The only
change to the existing spec is to say the state created by an INVITE has a
finite lifetime.  We are creating less state, not more.  End systems also
must already be designed to send and receive repeated INVITEs at session
initiation.  Entering the "in session" state just changes the timing of
their generation on the initiation side, and short cuts to an immediate
response on the recipient side.

My instinct says that using the same mechanism to maintain state as was
used to create it will be robust across a wide range of unforeseen
circumstances.

Tim

Tim Dorcey
iXL-Los Angeles
[email-masked]
(310) 235-3928

---

From: Lars Berggren <[email-masked]>
Date: Mon, 01 Feb 1999 10:38:36 +0100

Sean Olson wrote:
...
> a "Frequency:" header can be associated with the PING request.

Well, if the complexity of the proxy is independent of the keep-alive
mechanism used, we could at least choose the one which requires the
minimum of messaging in order to reduce the load for the proxy.

I understand that it is desirable to simplify the client, however I
think reducing the load for the proxy is a greater benefit.

/Lars

---

From: [email-masked] (Adam B. Roach)
Date: Mon, 1 Feb 1999 10:06:13 -0600 (CST)

>think reducing the load for the proxy is a greater benefit.

I maintain that a PING approach takes fewer messages, and less overall
handling, than re-INVITEs. I'll demonstrate.

   link A    link B
C1---------P--------C2

Sequence of messages per refresh period for re-INVITE:

1) INVITE on link A
2) INVITE on link B
3) 200 on link B
4) 200 on link A
5) ACK on link A
6) ACK on link B

(Under certain circumstances, steps 5 and 6 can be collapsed
into one step; this still leaves us with five messages.)

Sequence of messages per refresh period for PING:

1) PING on link A
2) 200 on link A
3) PING on link B
4) 200 on link B

Some have proposed that the ACKs in the re-INVITE solution are
not strictly necessary. As I've mentioned before, this confuses
the issue of INVITE final response handling to include some very
confusing rules. For example: "Don't send an ACK when you receive 
a final response for an INVITE request involving a currently 
ongoing session, but ONLY if none of the session parameters have 
changed."

In any situation, removal of the ACK from the re-INVITE solution
merely brings it down to four messages total: the *same* number of 
messages as the PING solution.

Given that the message overhead is the same or worse for a
re-invite; that re-invites without the ACK impose additional
complexity on all SIP nodes; that PING is less complex to
implement in the client; and that both solutions are about
as much as a load in the proxy, it seems like PING may be a
better solution.

/a

---

From: Lars Berggren <[email-masked]>
Date: Wed, 03 Feb 1999 10:05:28 +0100

> as much as a load in the proxy, it seems like PING may be a

I agree that the PING method seems to add as much load in the
_stateful_proxy_ as the re-INVITE. But, I believe it's a option for a
proxy to be stateless for certain SIP transactions, e.g. those received
via UDP. I think being stateless for a SIP transaction makes the proxy
more efficient and reduces the load on it since it does not need to
remember anything about the transaction ( retransmissions, TCP
connections, timeouts... ).

Now, consider a proxy that keeps a call record for the duration of the
session and thus wants to know when it ends. To be efficient, it acts
like a stateless proxy per SIP transaction if possible. When the proxy
receives a SIP message it can act stateless on it just updates its call
record if the session has changed and then forwards it forgetting
everything about the SIP transaction the message is part of.

A re-INVITE SIP transaction will not force the proxy to become stateful,
but the PING transaction will since the proxy itself initiates it.

Hence, I think the PING method adds more load in a proxy that tries to
be stateless per SIP transaction.

/Lars

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Feb 1999 01:54:08 -0500

Adam B. Roach wrote:

> Sequence of messages per refresh period for PING:

This presumes a single proxy. With multiple proxies, the PING method is
more unless you use caching, and I still maintain that the caching is
going to be a real pain. Invalidation issues, synchronization issues,
etc. The re-INVITE approach is the least change, most in line with the
SIP model of peer to peer signaling, and most likely to work with
proxies that don't understand (new methods are always risky). Same is
true for user agents.

> not strictly necessary.

Not doing ACK's for re-INVITEs is a *bad* idea. If the UAS crashes and
reboots and then receives a re-INVITE, it thinks its an original INVITE,
not a re-INVITE, and then things get really confusing. Whats nice about
re-INVITE is its nothing different - an idempotent invitation to a
session. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: [email-masked] (Adam B. Roach)
Date: Thu, 4 Feb 1999 10:21:00 -0600 (CST)

>> handling, than re-INVITEs. I'll demonstrate.

[demonstration removed]

>proxies that don't understand (new methods are always risky). Same is

True. 

However, the caching issue doesn't seem to be much of a concern for
resource release; while it may take some time for caches to update,
the resources allocated in all of the SIP devices will *eventually*
become aware of a failure and shut down the call. This is exactly
the model that, for example, telephony IN nodes use (at a higher
level) to detect this sort of failure (eg the CS1 ActivityTest
operation). For any type of session where this type of failure needs
to be indicated faster, it is almost certain that one can detect
this as an interruption in a media stream.

At any rate, should we start putting together a description of
the semantics for periodic re-INVITEs, both client and proxy-initiated,
to ensure keepalive? Is there sufficient interest in *this* solution?

>re-INVITE is its nothing different - an idempotent invitation to a

An excellent point.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Feb 1999 21:56:01 -0500

> this as an interruption in a media stream.

It makes me worried when we design a protocol for keepalives with known
cache inconsistency problems, under the presumption its use is limited
to resource release. The mechanism is fairly general; I'd rather not
eliminate its use for other things (whatever they may be). Now, we could
simply deal with it; this might require some additional headers for
indicating when the state was last verified with the client, and some
headers for allowing a proxy to indicate it wants an official answer now
rather than a cached one (basically, many of the http caching headers).
Once we do this, I think we have a solution which is quite a bit harder
than re-INVITEs.

> to ensure keepalive? Is there sufficient interest in *this* solution?

Sure - write it up as an I-D. You don't even need consensus or interest
for that, but I think there is interest anyway.

-Jonathan R.