Subject: [Sip] more outbound-03

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 30 May 2006 07:58:10 +0200

Cullen,

For deployments with edge proxies (3.4), do we need some way to ensure that "primary" and "backup" flows don't end up at the same registrar host? 

Regards,

Jeroen

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Tue, 30 May 2006 00:24:21 -0700

For solving the high reliability  problem - yes.

Note that there have been a few proposed solutions to this and  
outbound as it is currently defined works with any of them

On May 29, 2006, at 10:58 PM, Jeroen van Bemmel wrote:

> Cullen,
>
> For deployments with edge proxies (3.4), do we need some way to  
> ensure that "primary" and "backup" flows don't end up at the same  
> registrar host?
>
> Regards,
>
> Jeroen
>

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 30 May 2006 12:07:58 -0400

I'd like to get my brain refreshed in regard to the "backup flow" issue.

My belief is that keeping a backup flow is intended to increase
reliability.

This can be true in only one sense -- When the primary flow fails, the
agent can start using the backup flow without having to wait the time
that it would require to set up another primary flow.  And that this
time delay would be a significant impediment to the type of reliability
that we are attempting to provide.  Naively, this seems plausible to me,
but I'd like some confirmation that people have examined this assumption
and know that it is significant.

The second problem is "How to choose the backup flow target from the set
of potential targets?"  This is not as simple as it seems.  For picking
the primary flow, we just go through the list of servers in some
preference order.  But picking the backup flow is based not on the
desirability of the backup target itself, but on minimizing the
probability that both the primary and backup will fail simultaneously.
And the optimal choice may depend on what was chosen as the primary.

For example, sitting in Boston, my UA may prefer to connect with one of
my provider's New York proxies.  But the most likely failure mode might
be "all New York proxies become inaccessible due to transmission line
failure", in which case the backup should be *constrained* to be a Los
Angeles proxy.  OTOH, the most likely failure mode might be one proxy
failing independently of all others, in which case, the backup should be
the same as the second-most-preferred primary proxy, another New York
proxy.  There are other, messier, possibilities, which might be very
difficult to model in a general DNS mechanism.

Dale

---

From: <[email-masked]>
Date: Wed, 31 May 2006 16:36:51 +0300

Hi Dale,

I think you have raised good questions, indeed: 

>but I'd like some confirmation that people have examined this 
>assumption and know that it is significant.

After working some time with the I-D specifying how the UA might
find target hosts for primary and backup flows I started to think
about what the UA would do with those multiple flows. I was able
to make the following conclusions:

In the introduction section draft-ietf-sip-outbound-03 says:

   There are many environments for SIP [5] deployments in which the User
   Agent (UA) can form a connection to a Registrar or Proxy but in which
   the connections in the reverse direction to the UA are not possible.
   This can happen for several reasons.  Connection to the UA can be
   blocked by a firewall device between the UA and the proxy or
   registrar, which will only allow new connections in the direction of
   the UA to the Proxy.  Similarly there may be a NAT, which are only
   capable of allowing new connections from the private address side to
   the public side.  This specification allows SIP registration when the
   UA is behind such a firewall or NAT.

   ...

   The key idea of this specification is that when a UA sends a REGISTER
   request, the proxy can later use this same network "flow"--whether
   this is a bidirectional stream of UDP datagrams, a TCP connection, or
   an analogous concept of another transport protocol--to forward any
   requests that need to go to this UA.  For a UA to receive incoming
   requests, the UA has to connect to a server.  Since the server can't
   connect to the UA, the UA has to make sure that a flow is always
   active.  This requires the UA to detect when a flow fails.  Since,
   such detection takes time and leaves a window of opportunity for
   missed incoming requests, this mechanism allows the UA to use
   multiple flows to the proxy or registrar.

Having multiple flows only helps if those flows are not likely 
to fail at the same time. In draft-ietf-sip-outbound-03 and my 
I-D considerable amount of effort has been spent to ensure that 
those multiple flows would be set up to different proxy servers, 
thus providing protection against a failing proxy. 

However as the introduction says, the key reason behind writing 
the draft-ietf-sip-outbound-03 are the NAT and firewall boxes 
between the UA and those proxies. Do the those middleboxes 
typically introduce a single point of failure that would make 
all flows to fail simultaneously ? In my understanding this 
would be the typical case, as usually the UA has only a single 
network interface towards a local network that interconnects
to the external networks over a single NAT or firewall. Even
if the network would have different NATs or firewalls towards 
different external networks, it would require very detailed 
knowledge of the network configuration to select the proxies 
such a way that each flow would be routed via a different 
middlebox.

So putting the issue together: if the NAT / firewall traversal
is the key issue for draft-ietf-sip-outbound-03, does introduction
of multiple redundant flows actually increase the likelihood of
having a flow alive so much that it is worth the effort and
additional traffic for keepalives ?

>difficult to model in a general DNS mechanism.

In the example you gave the optimal choice does not only depend on 
which server was chosen as the primary but also whether you would 
like to optimize towards "maximum likelihood that at least one flow 
stays alive" or "minimum impact to the service quality of only one 
proxy fails".

With only two flows (one primary and one backup) it is impossible 
to reach both those aims simultaneously, regardless of whether those
two target hosts are determined by UA configuration or DNS queries.
You can however achieve that, if the UA can be configured with e.g.
three proxy URIs (two for New York and one for LA, the New York
proxies having precedence over that in LA).

The aim in the coming version of draft-koivusalo-sip-outbound-discovery
is this:

      REQ-OUTB-DISC-04: The size of the outbound-proxy-set discovered
      automatically must reach at least the minimum size specified in
      draft-ietf-sip-outbound (i.e. 2)

The solution outlined in the I-D targets to meet this minimum
requirement
so that the UA would set up (one or) two flows, unless explicit
configuration 
of multiple URIs are given. How the UA selects the target host for its
second backup flow is based on algorithm, relying on the priority and
weight
values of SRV records. By configuring those SRV records in an
appropriate
way the service provider should be able to achieve different kind of
redundancy schemes, also based on geographical location if needed.

P.S. I try to send draft-koivusalo-sip-outbound-discovery-01 over today
so that you would be able to have a look into its details.

Regards,

Erkki

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 31 May 2006 09:53:34 -0400

> additional traffic for keepalives ?

Well, that's a different problem than the one I was asking about --
namely, is it worth the effort to *maintain* two flows?  One could
establish a backup flow at the time that one discovers that the primary
flow has failed.  (Which has the advantage that one can with certainly
choose a proxy that is working at the moment of need.)  The only
disadvantage is that it takes time to establish the second flow.  The
only reason that one would want to have the backup flow pre-established
is that the setup time is longer than can be tolerated.

But I've never seen anyone say that they've determined that the setup
time is too long to be tolerated.  I've never even seen anyone *assert*
(with or without evidence) that the setup time is too long.  We just
seem to be progressing with the design, taking that for granted.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 31 May 2006 18:10:01 +0300

> additional traffic for keepalives ?

erkki,

if UA has flow open to multiple proxies, then any of these proxies may
send request to the UA, which makes load balancing of proxies possible.
seems like you forgot that important aspect.

 > two target hosts are determined by UA configuration or DNS queries.

could you please stop mentioning primary and backup, since that kind of
distinction should go away from outbound i-d.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 May 2006 15:30:44 -0400

I don't know what "too long" is. But this is one of those places where 
avalanche restart is a problem. E.g. the proxy serving Manhattan goes 
down and everybody reregisters to the alternate proxy in Hoboken.

To avoid killing the backup, you want to randomize the time when the 
reregistration is attempted. But if in the meantime you have no 
connection at all, then you miss calls.

But if you normally have two connections, then when one of them goes 
down you can take your time getting a replacement for it established. 
E.g. you have connections to Manhattan and Hoboken. Then you notice your 
Manhattan connection has gone away. So at your leisure you try to 
reconnect to another server, say in Queens. Its ok if it takes 
5/10/15/30 minutes, because meanwhile you can still get calls via Hoboken.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 31 May 2006 17:04:51 -0400

> down and everybody reregisters to the alternate proxy in Hoboken.

OK, now I understand.

Thanks,

Dale