Subject: RE: [SIP] DNS SRV records in stateless mode

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2000 01:52:27 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 9:25 PM
> To: Jonathan Rosenberg
> Cc: 'Igor Slepchin'; 'Gethin Liddell'; [email-masked]'
> Subject: Re: [SIP] DNS SRV records in stateless mode
> 
> 
> Jonathan Rosenberg wrote:
> > 
> 
> > 
> > This seems like a major burden. Basically, if I implement 
> more than on SRV
> > record with equal priority (which I will want for load 
> balancing), I am
> > forced to handle the case that any transaction can now be 
> spread across
> > multiple hosts. This is quite hard - forcing, as you say, 
> back end state
> > sharing for normal operation where otherwise it would only 
> be needed in
> > event of failure. 
> 
> I'm still not sure what "normal" operations need this type of state.
> Billing was mentioned, but there, you need it anyway in case 
> of failures
> and other strange cases. 

I'm not talking about billing. What I mean is that if a stateless proxy
randomizes for each request retransmission, you are going to see requests
for the same transaction sprayed across many servers. Effectively, the
stateless proxy has forked. Now, lets say stateless proxy A sends one
request for the transaction to B, and then the next request for the same
transaction to C. B and C both do their thing, and in all likelihood,
forward to the same next hop proxy, D. D detects a merged request, and
rejects one of them (say, the one from C), with a 400. To the other, B, it
responds with a 300. Now, both B and C forward their respective responses
upstream, resulting in a 300 forwarded to A in addition to a 400. A, being
stateless, proxies both upstream. Now, the poor UA or proxy in front of A
doesn't know which one to look at or ACK. 

All these extra messages and extra confusion are what I wish to avoid. I
agree that a proxy should not count on requests always coming to the same
proxy for billing. Thats a separate issue.

> 
> > I think it is not unreasonable to define the SRV
> > "contract" that the particular SRV host used for the same 
> transaction, in
> > the case of a stateless proxy, remains unchanged for all 
> requests in that
> > transaction.
> > 
> > Doing so is quite easy by making the randomization process 
> depend on an
> > invariant in the request; in particular, the transaction 
> ID. So, I would
> > compute a transaction ID by hashing to To, From, Call-ID, 
> CSeq, top Via,
> > R-URI, and then, if there are N equal priority records, 
> choose one by using
> > the top CEILING(log(N)) bits as a selector. The result is 
> still significant
> > randomization, but gives you the caching you asked for 
> anyway, without any
> > state.
> 
> If all you want is randomization, hashing just the Call-Id is probably
> easiest to implement and describe, since you'd rather want subsequent
> requests to go to the same place and I see no large load-sharing
> advantage in randomizing across requests.

OK. Thats fine. It seems that the finer the better, since we want to achieve
the same behavior we would see from a stateful server, which would send all
requests in the same transaction to the same next hop server, but otherwise
be randomized across transactions. My proposed hash accomplishes exactly
that.

-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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2000 21:21:23 -0400

To address the random routing problem, I've tentatively added the
following wording to the section on SRV usage (1.4.2):

Within a transaction, a stateless proxy {\MUST} always select the same 
destination within the set of hosts with the same priority.  This can be
accomplished, for example, by using the modulo $N$ of a hash of the
\header{Call-ID} value or some other combination of
transaction-identifying headers as the uniform random number described
in the weighting algorithm of RFC 2782.  Here, $N$ is the sum of weights
within the priority class.

This is somewhat messier than just taking bits, in order to satisfy the
non-even weighting rules.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs