Subject: [Sip] Open Issue #145: SRV Processing in stateless proxies part I

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 00:13:31 -0500

Issue:

Processing of SRV records in stateless proxies is hard, primarily because
the algorithm itself relies on state. One piece of state is the random
selection of a server amongst a set with equal weights. Bis-05 mandates that
this be done based on Call-ID, so that all requests with the same call-id
select the same server. Turns out that this is hard to do in a stateless
way. One approach is to choose the random number as a hash of the Call-ID.
That is needed, but not sufficient. The problem is that the result of this
hash generates an index, 1..N, where N is the number of servers with the
same priority. Using this index to select a server requires that the array
of N servers is ordered the same for each attempt. However, DNS resolvers
make no guarantee about the order of the results. Thus, you would need to
alphabetize them, or something, to establish an order.

Interestingly, this alphabetization would be required even for stateful
proxies! The reason is that if all requests with the same Call-ID go to the
same server, that spans multiple transactions, and thus a transaction
stateful proxy would not be sufficient for this reuqirement. 

The decision to use the granularity of Call-ID to select a server was to
assist in processing of overlap dialing; without that, an updated INVITE
with new digits could get routed to a different server than the original
request. Of course, that could happen anyway for any number of other
reasons... so, since overlap has this problem ANYWAY, and I hate to design
anything in baseline SIP to serve such an archaic methodology of signaling,
my proposal is:

Proposal:

1. We revert to requiring that all requests within a transaction, plus
CANCEL for that transaction, MUST all get routed to the same server. ACK-200
is a different transaction and thus need not go to the same place, but ACK
for non-2xx is.

2. For stateless proxies, they do whatever they need to do to meet
requirement 1. It is RECOMMENDED that they hash the transaction ID, and use
it as an index into a list of the servers, where the servers are ordered in
such a way that the order does not change across DNS queries, as long as the
DNS entry itself has not changed. This wouldn't mandate alphabetization, and
indeed, if you had a resolver that always gave you the results in the same
order, that would be sufficient.

-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: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 06 Dec 2001 14:14:36 -0500

> alphabetize them, or something, to establish an order.

Not quite. If I understand the SRV description correctly, there is an
ordering based on the weight (so that you can pick the right one). Thus,
if the weights are not equal, the order is indeed guaranteed, as long as
the resolver doesn't mess with the weights. For load balancing, it
doesn't matter if the weights are 1001, 1002 and 1003 instead of 1000,
so one could recommend that SRV entries for stateless proxies simply
avoid equal weights. This would be just a hint, not normative.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2001 23:04:34 +0200

Hello,

> avoid equal weights. This would be just a hint, not normative.

If, as Henning suggestes, we can resolve the alphabetization, the only
difference would be that a staless proxy would need to compute the
random number that is used to pick one server as a result of a hash of
some fields, whereas a stateful proxy could use any radom number
generator.

Is there much difference (regarding computational power and speed)
between computing the hash and generating a random number using a
standard random generator?

Regards,

Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Dec 2001 15:43:52 -0500

> standard random generator?

Since there are no cryptographic security requirements here, you can
probably get away with a pretty simple hash, but I suspect that even
MD2/4/5 are going to be plenty fast, given the small amount of material
to be hashed.

Yes, a regular random number generator as used for simulations (which is
what you would need here) can't be beaten in terms of speed, as its
roughly a few additions and multiplications, or something close to that
(details depend on the algorithm chosen). For concreteness, here's a
classical random number generator:

/*
  IBM 360/370 uniform multiplicative congruential random number
  generator, used in RESQ.
  (see Lavenberg, "Computer Performance Modeling Handbook", p. 227)
  Implemented as in Bratley et al., "A Guide to Simulation", p. 215.
  On a VAX 6310, one sample requires 10 us of CPU time.
*/
static double unif(unsigned long *s)
{
  long ix = *s;
  long k = ix/127773;
  ix = 16807*(ix - k*127773) - k*2836;
  if (ix < 0) ix += 2147483647;
  *s = ix;
  return ix * 4.656612875e-10;
}

In any event, I suspect that any difference is lost in the noise and
should certainly not guide our discussions here.