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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Sep 2000 11:48:03 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2000 8:36 PM
> To: Igor Slepchin
> Cc: Gethin Liddell; [email-masked]
> Subject: Re: [SIP] DNS SRV records in stateless mode
> 
> > > <...> if you always select a server based on some
> > > deterministic heuristic you have broken the SRV lookups.
> > 
> > We've only broken load balancing and failover pieces of it. 
> The other
> > important aspect of using SRV records - service specific 
> host definition
> > - is still used. The load balancing piece may be partially 
> preserved if
> > we require that stateless servers use a random but constant 
> throughout
> > the lifetime value for ordering SRV records. That is, each stateless
> > server will always choose the same host for a domain but different
> > stateless servers will end up using different hosts. Thus, the load
> > balancing is done across multiple upstream hops.
> 
> If you want the true stateless reliability that allows 
> fail-over in mid
> call, you need to synchronize whatever backend state anyway across
> servers, so I'm not sure that imposing this restriction is 
> particularly
> useful. It is also very likely to be a brittle requirement 
> which is hard
> to enforce, unlikely to be implemented universally and unlikely to be
> detected if not done correctly (since most tests are not going to use
> the load balancing feature). Thus, it seems dangerous to have servers
> rely on the fact that retransmissions will go to the same 
> place. If you
> can't handle this state distribution, don't advertise multiple
> equal-priority hosts and use a "web director"-style approach.

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 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.

How about 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: Thu, 14 Sep 2000 21:25:22 -0400

Jonathan Rosenberg wrote:

> 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 think it is not unreasonable to define the SRV

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.

I have to admit that I'm still a bit concerned that a proxy would rely
on this somewhat obscure aspect of correct upstream behavior. If
anything like billing depends on it, it offers opportunities for
"creative" upstream proxies to see if they can't "improve" the behavior
by ignoring this little rule. If a bug in an outbound proxy creates
double billing downstream, you're going to have a very hard time
explaining this to the customer. ("Mrs. Daisy, unfortunately your ISP
doesn't randomize properly, so you're being billed twice for every tenth
call.")

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs