Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

From: <[email-masked]>
Date: Wed, 3 May 2006 09:33:29 +0300

Hi,

>> operator wants to have load balancing, there must be at least two
>> primaries and perhaps also two backups organized in such a 
>> way that if one primary goes down. also the other needs to be brought

>> down, because otherwise there would be no load balancing.

I do not think the sizes of the primary and proxy farms should
necessarily be the same. Instead of applying 1+1 protection you
can also arrange 1:N protection e.g. by having the SRV record
of primary proxies to resolve as 2 servers and the SRV record
of backup proxies to resolve as 1 single server.

Each of the two primary proxies would serve half of the UA
population while the single backup one could take over the
load of any of the primaries failing. Load balancing would
be kept as only those UAs using the failed proxy as their
primary would now start to use the backup server.

>> if all proxies are the same, then operaor can add a new one 
>> to the set and it automatically receives also some of the load.

Now the issue is whether the autodiscovery mechanism should
support having redundant (idle) backup proxies or not. It 
could also be possible to revise the I-D so that both ways
would be possible. The mechanism would work e.g. like this:

- If operator wants to use idle backup servers, a separate
  SRV record with higher Priority value could be introduced
  for those (like the I-D currently proposes).

- If the operator wants to use a single set of servers both
  for load balancing and backup, then only single SRV record
  would be introduced. In this case the UA should set up its
  primary and backup connection towards two different proxies
  within this single record. UA would only do so if it does not
  find SRV records for SIP Outbound with higher Priority value.

Comments ?

Regards,

Erkki

>-----Original Message-----
>From: ext Hadriel Kaplan [mailto:[email-masked]] 
>Sent: 28.April.2006 20:12
>To: 'Juha Heinanen'
>Cc: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); [email-masked]
>Subject: RE: [Sip] I-D 
>ACTION:draft-koivusalo-sip-outbound-discovery-00.txt 
>
>But I think no matter what it will be the UA which decides 
>which one to use
>for active signaling.  Even if you call them both primaries, 
>the UAs would
>probably just use the first one configured/discovered/bound 
>for signaling.
>If you specify they must choose it randomly then you could 
>just say that
>about the primary and backup terms. (although I agree the 
>terms would be
>highly confusing, as they already are for me)
>
>In some ways that's already going to happen - the draft does 
>not say the UA
>must use the "primary" for new outbound requests, and the 
>registrar has no
>idea which one the primary is, so new requests going to the UA will be
>pseudo-randomly chosen. (if anything, it would probably use the most
>recently bound one, which ironically means the backup will be the first
>used)
>
>-hadriel
>
>> -----Original Message-----
>> From: Juha Heinanen [mailto:[email-masked]]
>> Sent: Friday, April 28, 2006 12:37 PM
>> To: Hadriel Kaplan
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-
>> 00.txt
>> 
>> Hadriel Kaplan writes:
>> 
>>  > BTW, why does the terminology mistake make you need four proxies?
>> 
>> if one is primary and one is backup, then ua would always 
>use primary as
>> long as it is alive, i.e., backup would be on hot standby.  so if
>> operator wants to have load balancing, there must be at least two
>> primaries and perhaps also two backups organized in such a 
>way that if
>> one primary goes down. also the other needs to be brought 
>down, because
>> otherwise there would be no load balancing.
>> 
>> if all proxies are the same, then operaor can add a new one 
>to the set
>> and it automatically receives also some of the load.
>> 
>> -- juha
>
>

_______________________________________________
Sip mailing list  https://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: Juha Heinanen <[email-masked]>
Date: Sat, 6 May 2006 21:56:24 +0300

>   find SRV records for SIP Outbound with higher Priority value.

if i understood correctly, this option is what i prefer, i.e., a single
pool of outbound proxies with equal priority value.  the notion of
primary and backup should be abolished from outbound i-d if it still is
there.

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 18:24:35 -0400

Reading draft-ietf-sip-outbound-03, I see that it mentions configuring
a UA with a "primary" and a "backup" proxy, and assumes that the UA
will maintain connections with both of them, preferentially using the
"primary" for outgoing messages.

But as I read it, that is entirely a suggestion -- implicitly, the
authors expect that the reader understands that since the I-D does not
specify how the configuration is done, and since the two connections
are equivalent in outcome (if not performance), the number of proxies
configured and the algorithm which the UA uses choose which proxies to
contact and use is a matter of UA policy, outside the scope of the
I-D.

Reading draft-koivusalo-sip-outbound-discovery-00, it appears that it
is formalizing the classes of "primary" and "backup" proxies, and
requiring that the UA maintain a connection to exactly one of each.
Or rather, each SRV priority level defines a class of servers, and the
UA must maintain a connection to exactly one of each.  It seems to me
to be excessively restrictive to constrain UAs to this scheme, given
that we have little experience with this problem, and that this scheme
is quite different than the behavior previously specified by a set of
SRV records.

Unfortunately, we really do need to solve the problem of locating
Outbound-capable servers using DNS records.  But do we need to specify
exactly which servers a UA must use, beyond the rather general
preference and balancing rules of RFC 3263?

At this point, an idea occurs to me that must have already been
considered and rejected -- Why not have the UA attempt to register
using the 3263 rules, but specifying "Requires: outbound"?  That will
automatically exclude servers that do not support Outbound.  The only
limitation would be that a UA using Outbound would see the same
priority relationships between the servers that a non-Outbound UA
would see.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 29 May 2006 08:14:47 +0300

> preference and balancing rules of RFC 3263?

dale, this is exactly what i have proposed in two or three emails to
this list already.  since i don't remember anyone opposing, it would be
nice if the authors outbound would issue a new version where the
primary/backup distinction has been eliminated.

 > automatically exclude servers that do not support Outbound.
 > The only limitation would be that a UA using Outbound would see the same

yes, it would mean lots of redirects by the proxies.

-- juha

---

From: <[email-masked]>
Date: Mon, 29 May 2006 11:31:06 +0300

Hi,

Thanks Dale for the attention you have given to the
sip-outbound-discovery draft. I try to provide some
insight of the aims of the draft, rationale for the 
choices made in that draft and a briefing of changes 

>contact and use is a matter of UA policy, outside the scope of the

Yes and no. Outbound-03 introduces a number of example configurations,
some with and others without the support for backup connection. However
the normative text in section 4.2 currently tells:

   A UA MUST support sets with at least two outbound proxy URIs (primary

   and backup) and SHOULD support sets with up to four URIs.  For each
   outbound proxy URI in the set, the UA MUST send a REGISTER in the
   normal way using this URI as the default outbound proxy.

However section 4.2 also leaves the door open to use other means than
configuration, e.g. DNS:

   UAs are configured with one or more SIP URIs representing the default
   outbound-proxy-set.  The specification assumes the set is determined
   via configuration but future specifications may define other
   mechanisms such as using DNS to discover this set. 

What I have been trying to do is to formalise those mechanisms based 
on DNS in order to:

1. Make it possible to implement UAs that would support two flows
   towards two proxies even if the UA is configured with 0-1 URIs
   based on which the UA tries to locate the proxy:

	a) UA tries to locate its home proxies based on the domain 
	   of the AOR of the user

	b) UA tries to locate a visited proxy based on DHCP query
	   which results a single domain name to be used

2. Make it more specific how the service provider should configure DNS
   so that compliant UAs would be able to find two different proxies
   to contact with. The aim is to define the algorithm that the UA
   uses for discovery so that the service provider could achieve
   various aims like:

	- Only a single proxy, no support for backup flows
	- One pool of proxies amongst which the UA can select two
	  for setting up the flows towards them. Server load balancing
 	  would be done within this pool.
	- Separate pools of proxies for primary flows (load balancing
	  amongst them) and redundant idle proxies for backup flows.
	  The sizes of those pools can be same or different, e.g. to
	  allow N primary proxies to be protected by one backup proxy.

I am planning to publish a revised scheme of using SRV records to
support
these items, based on the comments I have got for
sip-outbound-discovery-00.
Also I have agreed to add a requirements section to the draft to make
those aims clearer.

>requiring that the UA maintain a connection to exactly one of each.

In the next version I will change the point of view to be the view
of the UA. So instead of discussing primary and backup proxies, the
I-D will rather describe how a UA will set up its primary and backup
flow towards two different proxies. The proxies themselves will not
have a fixed "primary" and "backup" status, at least in all the cases.

>is quite different than the behavior previously specified by a set of

Please note that this spec would not prevent developing UAs which 
support a larger numer of proxies by configuration. The target of
this I-D is just to make it possible to develope UAs that need 
only a single URI to be configured (e.g. AOR) and automatically 
discover the used proxies based on a standardized scheme of DNS 
configuration.

Next version will actually use exactly the same algorithm for 
handling the SRV records as already specified in RFC 2782. The
new idea is just to use a reduced set of SRV records to be sorted
for setting up the backup flow.

But what will remain is the formal idea of how a UA can automatically
discover two different proxies (supporting SIP Outbound) so that it
can set up exactly two flows (primary and backup) towards them.
Also it should be possible to have a mobile type of UA that only
sets up one single flow, so that it would not exhaust its battery
too quickly for keepalives.

>preference and balancing rules of RFC 3263?

The problem is that those rules you are referring to do not give
any guideline for selecting a proxy for the backup flow. This is 
one of the two major problems my I-D is trying to solve. (The other
problem is how to find which proxies support SIP Outbound as the
domain might have proxies without that support, too.)

>priority relationships between the servers that a non-Outbound UA

Relying on SIP based mechanisms has a few problems:

1. It would introduce extra round-trips as the UA would need to
   blindly try if the proxy found by RFC 3263 rules would support
   SIP Outbound or not. If not, then the number of further round-
   trips would depend on whether the contacted proxy is able or
   is not able to redirect the UA towards another proxy.

2. If the UA aims to set up two flows towards two different proxies,
   it would make the round-trips easily to double. Furthermore I can
   not imagine how the proxies could make sure that they would not 
   redirect the second flow towards the very same proxy with which
   the UA already has set up the first flow.

I hope to be able to publish the next version of sip-outbound-discovery
still this week.

Regards,

Erkki

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 20:59:16 -0700

I agree with Juha that this primary/backup terminology is bogus. The  
problem is coming up with better terminology. On earlier version, I  
had tried to just refer to is as a set and picking one from the set.   
If someone has good suggestions on better terminology (or even  
better, a patch we can apply to the XML) it would be nice.