Subject: [SIP] DNS SRV records in stateless mode

From: Igor Slepchin <[email-masked]>
Date: Tue, 12 Sep 2000 14:44:53 -0400

The 2543bis draft is silent about using SRV records in stateless mode
and I think the subject may be worth some discussion.

As far as I can tell, the best approach seems to be to just use the
highest priority SRV records for the protocols supported that doesn't
result in the immediate failure. That is, if the first SRV record turns
out to be for TCP and the connection to the specified host fails, the
next SRV record should be tried. However, ICMP errors cannot be detected
in stateless mode so the search automatically stops on the first UDP
record (recycling connected UDP socket across requests would help
detecting ICMP errors).

Note that using the standard algorithm described in 1.4.2 and RFC2782 in
stateless mode is problematic since this will likely result in
retransmissions of the request to be sent to different next hops. This
is certainly undesirable even though probably not catastrophic since all
such requests are likely to be eventually forwarded to the downstream
proxy or UA so the retransmissions will be detected as merged requests
there.

Another possible approach is to use only A records in stateless mode.
However, I don't think this has any advantages over the first approach
described; besides, some domains may not even have a SIP server at the
address listen in the A record.

Any comments?

---
Igor Slepchin

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

---

From: James Undery <[email-masked]>
Date: Wed, 13 Sep 2000 09:34:25 +0100

> proxy or UA so the retransmissions will be detected as merged requests

When using SRV records you have to choose the transport protocol as well as
the service. So the TCP/UDP issue isn't a problem, the problem comes when
the returned record contains multiple entries with the same priority, the
proper method of using SRV requires that the weightings are used to randomly
select an address. As soon as you select a random address a stateless proxy
is doing the wrong thing, if you always select a server based on some
deterministic heuristic you have broken the SRV lookups.

On the subject of stateless proxies I am of the opinion that a true
'stateless proxy' is an oxymoron, for it to be useful it needs some state,
the challenge is how much to make it useful and how little to make it fast.

> address listen in the A record.

I think the server location section of the bis draft would be better made a
'MAY' as it severely limits a proxy's discretion in routing matters. As the
main purpose of a proxy is routing it seems unusual to fix this as a
'SHOULD' as the proxy itself may know better, before falling back on SRV. I
am not in favour of specifying this in the bis draft as I believe it is an
implementation issue outside of the scope of the proposed standard.

James Undery

---

From: Gethin Liddell <[email-masked]>
Date: Wed, 13 Sep 2000 09:06:12 +0100

Hi, Igor

On Tue, 12 Sep 2000, Igor Slepchin wrote:
> next SRV record should be tried. 

um, stateless proxies don't do tcp. so when you do the SRV lookup,
you would only sepcify udp so this problem does not occur.

> However, ICMP errors cannot be detected

agreed, and i do believe that the only real thing that statless
servers can do here is ignore ICMP.

> proxy or UA so the retransmissions will be detected as merged requests

this error could provide big problems, if not with the routing then
maybe with a user getting billed twice etc...

> address listen in the A record.

I think it is fair to say that a statless proxy first of all does SRV
for sip and udp (in the case of non IP address and port 5060).  if this
fails then an A record look up is done.  In each case the first record
should be used if possible.  if both fail, then nothing is
done.  Although there was some discussion recently on returning final
responses in the statless mode which we may need to consider.

thoughts and opinions?

gethin

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 13 Sep 2000 14:19:25 -0400

> you would only sepcify udp so this problem does not occur.

That's correct. However, the proxy may decide to process a transaction
statefully if there is a TCP SRV record for it so I wouldn't necessarily
limit SRV request to UDP only. Of course, once the decision to process
the request statefully has been made, the problem with handling
retransmissions is gone.

> implementation issue outside of the scope of the proposed standard.

The proxy is free to apply any logic it wants when making routing
decisions (CPL, CGI, servlets, etc.). However, if it decides to make the
routing decision based on DNS, it should follow the SRV algorithm
described so I see no problems with keeping it as a SHOULD.

> <...> if you always select a server based on some

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.

---
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2000 08:22:17 -0400

> record (recycling connected UDP socket across requests would help

Always, a randomly selected host among the highest-priority SRV record
is used. Thus, even in the case, retransmissions may reach different
destinations. However, that's completely up to the configuration of that
domain. A domain that cares that this doesn't happen is well advised to
not to list hosts with equal priority.

I agree that keeping a cache of connected UDP sockets would be helpful,
in case the upstream client retransmits. Also, some operating systems
may allow detection of ICMP errors (and one could, albeit with
significant pain, intercept ICMP via raw sockets on Unix-like operating
systems and then keep a black list of invalid downstream servers.).

The obvious problem is that having a single highest-priority UDP server
makes failover for servers more difficult, as the stateless proxy will
try the failed server again and again. Thus, randomization seems like a
good thing.

> address listen in the A record.

Using A records would be highly undesirable. In addition, it would be
hard to determine which protocol to use.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2000 20:36:09 -0400

> described so I see no problems with keeping it as a SHOULD.

I agree. Since an implementation's decision of creatively reinterpreting
the SRV logic could severely degrade the load balancing that a
downstream server has in place, for example, this is not a private
decision. If somebody gets lazy and always picks the first server from
the load sharing pool, I want to at least be able to wave the spec at
them.

> 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. For
billing records, it's pretty easy to create a handle that only depends
on invariant aspects of the request and thus lends itself to easy
reconciliation if two records appear with the same value, entered by
different servers. 

If you want that across requests, use Record-Route.

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