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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2000 00:53:16 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, September 15, 2000 9:21 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [SIP] DNS SRV records in stateless mode
> 
> 
> 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.

Yes, I had forgotten about that.

One small change. As worded, it seems like this only applies to stateless
proxies, so that stateful ones could send to diffrent destinations. How
about:

Within a transaction, a proxy {\MUST} always select the same 
destination within the set of hosts with the same priority.  This can be
accomplished statelessly, 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.

All I did was remove stateless from the top line and add it into the third.

-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: "Brian Stucker" <[email-masked]>
Date: Mon, 18 Sep 2000 13:59:39 -0500

This wording concerns me. I'm afraid of what the term 'hash' may imply to
implementors down the road. Since Call-IDs do not need to be randomly
selected, a (poor) hash of non-random sequence may very well wind up not
being random either. This wouldn't be easily detectible in situations like
bake-offs, where a limited number of calls are made. But, if it were applied
to a much larger scale, with higher traffic, the problem could render the
spirit of the weighting algorithm of RFC 2782 moot. Instead of getting
random, weighted server selection; you're getting sort-of random, kind-of
weighted server selection. Imagine if a portion of a large IP backbone
provider was using SIP, and had a stateless proxy setup with DNS-SRV for
load balaning ran into this problem? 

I think more stress needs to be placed on ensuring that the hash is as
random as possible (to the point of suggesting a suitable hash algorithm,
such as diving by a small prime number then modulus that with the weight
total). A lot of algorithms qualify as hashing algorithms that may just
great for small numbers of data elements, but not for a high-traffic
environment. Example: let's just add up all the digits in the Call-ID, and
mod that with the weighting total (bad idea). I suspect that if we're having
issues with fixed length fields, that this sort of issue could easily creep
up as well to the detriment of the implementor.

Also, this poses another problem, one where we can get out-of-sync with our
record selection. Let's say we have an INVITE that DNS-SRV returns two
entries for, each at a different priority level (priority A, and B, A is
better). The proxy selects the entry with priority A, and tries to route to
the server listed in the SRV record. That routing attempt times-out, so it
fails over to the second entry at priority B. During this time a
retransmission of the INVITE is sent by the originating UA, and is going to
get hashed back to the records with priority A in the proxy. However, we now
know that route is bad. We shouldn't re-select it for this transaction, we
should go straight to B for the retransmission as well. 

There's ways around this for stateful proxies, but a stateless proxy can't
employ the same methods with your selection method. UNLESS you also
stipulate that you should remove an entry from the list of selectable SRV
entries left in the list once they're excluded due to a timeout, or whatever
other event the proxy implementor deems appropriate.

Thoughts?

Brian Stucker
Nortel Networks 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Sunday, September 17, 2000 11:53 PM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: [email-masked]'
Subject: RE: [SIP] DNS SRV records in stateless mode

-Jonathan R.
---

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 18 Sep 2000 19:34:51 -0500

I don't understand how would it seriously impact load balancing? That's what
the specification tells you to do for SRV, I think =).
 
If you try an entry, and it fails due to timeout, then you go to the next
guy on the list. Maybe I'm just not reading this correctly, or I just don't
understand your position correctly...
 
RFC-2782:
        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.
 
        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.
 
I read that to mean that you should go through the records in a particular
order if one times out, go to the next one that you've prioritized and
weighted to be next. Otherwise, if you weren't supposed to go through the
list on error scenarios, why apply the algorithm more than once? Pick your
one, be done with it. If that's the case, then why have different
priorities, because only those servers in the topmost priority would be
picked?
 
Since you don't want subsequent INVITES to get routed to a server you know
is bad, and since the logic for the stateless proxy is to treat all INVITES
(retransmitted or otherwise) to be one SRV transaction because we want to
"rig" the randomization process (which in itself would impact load balancing
at the SRV level, but not on the SIP perspective) so it picks the same guy
every time for all retransmittions. Therefore, it would make sense not to
try an IP that you just had a timeout on. Move on, go to the next record.
Next time you get a completely new session, it's a whole new ball-game. You
start all over expecting that all of the servers returned (even though you
just tried them for a different session, and may have found some that were
bad) are potentially ok to use again.
 
I would consider that an improvement on load balancing, especially given the
impact that the rigging for SIP is going to have (which will probably work
out to a big net gain in load savings at the end of the day).
 
Brian Stucker
Nortel Networks

-----Original Message-----
From: Howard Hart [mailto:[email-masked]]
Sent: Monday, September 18, 2000 6:08 PM
To: Stucker, Brian [RICH2:WI12:EXCH]
Subject: Re: [SIP] DNS SRV records in stateless mode

Brian Stucker wrote: 

Probably don't want to do that since it could seriously impact load
balancing. 

Howard Hart 
ipDialog, Inc.