Subject: RE: [Sip] Handling of duplicate requests with differing request p aths.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 23:02:40 -0500

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 10:13 AM
> To: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [Sip] Handling of duplicate requests with 
> differing request
> paths.
> 
> 
> Hello,
> 
> > Jo is correct. A stateless LB is, according to the 
> > specification, just a
> > stateless proxy. A stateless proxy has to send 
> > retransmissions to the same
> > place as the original request. This means, effectively, that routing
> > decisions can ONLY be combinatoric functions of the request 
> > received plus
> 
> As I stated in my previous mail, the discussion of load balancer has
> been side tracked. What you said above is true in a perfect world. But
> there is no way you can guarantee a retransmitted INVITE is sent along
> the same path when a stateless proxy goes down and its backup has a
> slightly different view of the network topology. 

Well, service providers should beware to not purchase products like that.

That said, of course there can be failure cases and all, but the
specification doesn't define behavior for every conceivable failure case.

> > STATIC configuration data. You need to even be careful of 
> > configuration data
> > that can change in the middle of a transaction! The solution 
> > for these cases
> > is that the proxy becomes stateful for long enough to 
> ensure that any
> > stateless transactions have cleared.
> > 
> 
> Where is this requirement stated in bis-05 that a stateless proxy must
> route retransmitted INVITEs onto the same path?

Line 2464 of rfc2543bis-05:

 A stateless proxy MUST choose one and only one destination from the
destination set. This choice 2464
MUST only rely on fields in the message and time-invariant properties of the
server. In particular, a 2465
retransmitted request MUST be forwarded to the same destination each time it
is processed. Further- 2466
more, CANCEL and non-Routed ACK requests MUST generate the same choice as
their associated 2467
INVITE. 2468

> Are you saying that
> stateless proxy does NOT exist in practice? 

No, I'm merely saying that they need to forward retransmissions to the same
place. However, it is not trivial to make sure you always do that, even
through configuration changes. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Shan Lu" <[email-masked]>
Date: Thu, 8 Nov 2001 09:49:19 -0500

Hi,

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, November 07, 2001 11:03 PM
> To: 'Shan Lu'; Jonathan Rosenberg; [email-masked]
> differing request paths.

Ok, I've stolen the thread and changed the subject. 

To quote bis-05, line 2458, "They (stateless proxies) do not have the
ability to distinguish a retransmission from the original message" and
Line 2466, "a retransmitted request MUST be forwarded to the same
desitnation each time it is processed".

Assume that a stateless proxy uses the request-uri to look up a location
DB and make routing decisions. Given these two lines, does it mean that
all INVITEs with the same request-uri have to be routed to exactly the
same destination for as long as the proxy is running, regardless of
database changes? Can you provide some ideas how line 2466 can be
accomplished without the proxy going stateful?

Regards,

Shan Lu
sentitO Networks

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 08 Nov 2001 21:52:01 +0200

Hi,

> accomplished without the proxy going stateful?

A stateless proxy typically calculates a hash of some header fields
present in a request. Thses header fields will be the same in the
retransmission. This hash is used as an input for the algorithm you use
to choose different alternatives (different URIs or different IP
addresses if SRV is used).

As Jonathan said already, if something external changes (like you update
the database), you need to go stateful to be sure that you do not
re-route ongoing dialogs.

Stateless proxies are very useful as load distributors, and in this case
the database you are referring to only changes when some server goes
down... and as Jonathan already said, bis-05 does not cover any possible
failure scenario you can think of.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Shan Lu" <[email-masked]>
Date: Thu, 8 Nov 2001 16:10:55 -0500

Hello,

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2001 2:52 PM
> To: Shan Lu
> Cc: 'Jonathan Rosenberg'; [email-masked]
> Subject: Re: [Sip] How does Stateless Proxy handle Retransmission
> 
> 
> Hi,
> 
> Shan Lu wrote:
> > 

If this is the case, then the proxy MUST be stateful ALWAYS. How can the
proxy be certain that all INVITEs have finished their retransmissions
and therefore it's "safe" to update database? Wait for 32s of no
activity? 

> failure scenario you can think of.

I am afraid this view of stateless proxy is very restrictive. SL proxy
can be used as more than LB and can connect to a location database which
may be updated for reasons other than server failure. When this happens,
unless the proxy has been operating stateful since the initial INVITE,
you can't ensure that retransmissions will be routed to the same path.

I can't find similar text in bis-04 that talks about how retransmission
should be handled by a stateless proxy. So is the intension to deprecate
SL proxy in bis-05?

Regards,

Shan Lu
sentitO Networks

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 09 Nov 2001 03:10:55 +0200

Hello,

> and therefore it's "safe" to update database? Wait for 32s of no

As folks have said multiple times. If you intend to change your "routing
tables" often, do not implement a stateless proxy.

And if you have a stateless proxy and make a change in the "routing
table", you have to go stateful for max (T1*64, T3). Then you change the
"routing table", and go stateless again. You have simply to stay
stateful for all the transactions that were initiated during your timer.

You have changed everything is 1 minute. Is this a big deal? As cannot
stress enough that stateless proxies are not used when "routing tables"
change very often.

> should be handled by a stateless proxy. So is the intension to deprecate

I really wonder what makes you think that...

Regards,

Gonzalo