Subject: Re: [SIP] Issue with domain names in Via header

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Mar 2001 02:27:22 +0200

> >Yours is solved by ordering the servers in a certain order
> 
> >(alphabetical, for instance) before applying the process to choose
> one.
> 
> I don't see how this can be guaranteed to help. If the list of servers
> you get back has changed alphabetically the modulo N hash of the
> Call-ID can still pick the wrong server.

You get back the names from DNS, you order them, and then apply the
modelo N hash.

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]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Mar 2001 02:27:33 +0200

modulo N hash.

Gonzalo

---

From: "Neil Deason" <[email-masked]>
Date: Sun, 18 Mar 2001 21:30:42 -0000

>Hello,

>I am after a different issue.

It still effects you - even more so as you are trying to get a stateless proxy to always pick the same next hop for requests over a session, not just retranmsissions over a shorter lived transactions.

>(alphabetical, for instance) before applying the process to choose one.

I don't see how this can be guaranteed to help. If the list of servers you get back has changed alphabetically the modulo N hash of the Call-ID can still pick the wrong server.

This doesn't completely negate what you are trying to achieve but needs to be acknowledged where DNS SRV is being proposed for load balancing/failover solutions.

Cheers,

Neil.

>Regards,

>Neil Deason wrote:

> > This doesn't fix the open issue with SRV randomisation

> > messing up attempts by stateless proxies to pick the

> > same server.

> > http://lists.bell-labs.com/pipermail/sip/2000q4/003180.html

> > Cheers,

> > Neil.

> > Ubiquity Software Corporation, UK http://www.ubiquity.net

> > Gonzalo Camarillo wrote:

> > > Hello,

> > > > > Otherwise, if it is a receiver-tagged field (Section 6.47.2), send the

> > > > > response to the

> > > > > address in the "received" parameter, using the port indicated in the

> > > > > "sent-by" value, or

> > > > > using port 5060 if none is specified explicitly. If the sending the response

> > > > > results in

> > > > > failure (such as an ICMP port unreachable), send the response to address in

> > > > > the "sent-by"

> > > > > field.

> > > > > The result of this change is that we send the response to the place the

> > > > > request came from under normal conditions, but under failures, it can be

> > > > > routed to a backup. This change is backwards compatible, and will result in

> > > > > a nice feature, which is the reason usage of domain names was recommended in

> > > > > the first place.

> > > Very interesting addition. A stateless proxy will not be able to take

> > > advantage of this, since it will not catch ICMP notifications, but a

> > > stateful proxy will be able to bind the socket to the destination

> > > address and make use of the mechanism Jonathan suggests.

> > > I think after this addition there is just one missing piece in the

> > > SRV/load-banacing/fail-over issue. Actually, it has a lot to do with

> > > this.

> > > Last september we added the following text to section 1.4.2 of bis:

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

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

> > > I would suggest modifying this text to:

> > > "Within a transaction, a stateless proxy MUST always select the same

> > > destination within the set of hosts with the same priority. Within a

> > > session, a stateless proxy SHOULD 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

> > > Call-ID value as the uniform random number described in the weighting

> > > algorithm of RFC 2782. Here, N is the sum of weights within the

> > > priority class."

> > > The reasons for doing this are the following:

> > > Adding To, From, Cseq, Top Via and Request-URI to the hash just improves

> > > the randomization process within a session. However, within a session,

> > > it is most likely that you want all the requests to go to the same

> > > place. The call-Id is enough to randomize the selection for requests

> > > belonging to different sessions. Therefore, the addition of "some other

> > > combination of transaction-identifying headers " does not provide better

> > > randomization and it reads less clear in the RFC.

> > > With this addition we get a couple of features "for free".

> > > 1) There are several implementations that send a BYE instead of a CANCEL

> > > when the user makes a call attempt and then gives up before receiving an

> > > answer. If there are call stateful proxies in the network, they would

> > > like to see this BYE. This addition allows all the proxies in the path

> > > to see this BYE, although the Route header was not built yet.

> > > 2) I might send two instant MESSAGEs one after the other, very quickly

> > > to another user. If the followed different paths, the receiving

> > > application might be confused (the receiving application stores state

> > > information, such as Route, for the IM session). Besides, they might

> > > traverse different CPIM gateways (currently stateful). This addition

> > > resolves this issue as well.

> > > Therefore, I believe that with this addition everything we obtain is

> > > positive.

> > > Comments?

> > > A related issue is how stateful proxies handle this. I would suggest to

> > > have the same behavior as described above. This is very much related to

> > > what Jonathan suggested:

> > > Jonathan's suggestion for responses:

> > > A stateless proxy sends responses to the "received" address, and it will

> > > not be able to catch the ICMP notification. However, the stateful proxy

> > > will. It also sends responses to the "received" address, but if it

> > > receives an ICMP notification, it can then try the backup server.

> > > My suggestion for requests:

> > > If a stateful proxy is handling a particular trasaction and it receives

> > > another request within the same session, it SHOULD choose the same

> > > destination within the set of hosts with the same priority. If it

> > > receives an ICMP notification, it can then try the backup server.

> > > Comments?

>USA [email-masked]

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.