Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 5 Jul 2006 14:22:43 -0400

Jeroen,

If there are two flows available and one fails, then there is less
urgency to doing the registration refresh.  In other words less of a
need to do an avalanche restart.  I would hope that the UA would
appreciate that there is more to reliability than just the one
connection it cares about.  Because the UA does not have the visibility
that the proxy does, it might allow this type of decision to be deferred
to the network.  Network operators may need to provide such guidance to
maintain the network's stability or deny the UA access altogether.  It
would be good if the implementations of UA and Proxy would support the
possibility of such a negotiation.

Mike

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, July 05, 2006 11:24 AM
> To: Cullen Jennings (fluffy); Miguel Garcia
> Cc: [email-masked]; Rohan Mahy
> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04
> 
> Cullen,
> 
> see inline,
> 
> Regards,
> 
> jeroen
> 
> 
> >
> > My impression of what the WG wanted was that the service provider  
> > could provide between 1 and the max number the UA supported 
> of URIs.  
> > The UA must implement support for at least 2 and should support 4.
> >
> 
> yes, agree. And "the service provider SHOULD provide at least 
> 2" I suppose
> 
> > So let's say that the domain use two and this domains has 
> to have two  
> > do to reliability. If the UA has "local policy" and only 
> decided to  
> > use one - things don't work.
> 
> This depends on the definition of "work". The resillience 
> against certain types of failures is less, but things will 
> work provided no such failures occur.
> 
> > I think this is more or less the same as  if you are doing a single 
> > registration and the registry tells you  your registration expires 
> > after 1 hour but the UA decided to refresh  after two hours 
> to reduce 
> > network load, well things are broken.
> >
> 
> This is a clear case because *it is the UAs responsibility to 
> stay registered*. In this scenario, we would say that 
> specifically the UA is broken (RFC3261 section 10.2.4 : "Each 
> UA is responsible for refreshing the bindings that it has 
> previously established.")
> 
> Things are not so clear cut for outbound. The question is: 
> who is responsible for achieving a certain level of 
> reliability? who decides what is sufficient?
> 
> > Now you say that the UA might decide by local policy if it 
> wanted to  
> > do say 1 or 2 flows - but where will this local policy come 
> from? The  
> > end user is not going too provide it. I suspect the domain 
> will  provide it.
> > I'm fine with some times the domain tells the UA to use 1  uri and 
> > other times two. I can imagine the domain changing this  
> configuration 
> > as the UA moves from different types of access networks.
> >
> 
> This type of policy could very well be implemented in the UA, 
> in fact it may 
> be in a better position to estimate the reliability of the 
> access network(s) 
> it is connected to (eg by monitoring channel conditions). 
> Therefore, a model 
> in which the UA decides how many flows it uses is defendable too.
> 
> The decision on the number of flows depends on the desired level of 
> reliability, which in turn depends on the failure 
> characteristics of a 
> number of things including the access network, any NAT 
> devices, any edge 
> proxies, and the home proxy.
> 
> What if we adopt a modus operandi in which the UA decides 
> what level of 
> reliability it desires and (thus) how many flows it needs, 
> and the domain 
> provides information to support this decision (eg MTBF 
> figures for the 
> registrar, or derived information such as a *suggestion* for 
> the number of 
> flows)
> 
> > I expect you are right in that this MUST is too strong here 
> but I  think 
> > there is an argument for SHOULD. The problem is that if the 
>  domain assume 
> > the UA is doing two flows and the UA does one, things  are broken.
> >
> 
> Not from the point of view of the UA, it is getting exactly 
> the level of 
> reliability that it would expect from one flow. What reason 
> would the domain 
> have to assume anything about the number of flows the UA is using?
> 
> >
> >
> > On Jul 5, 2006, at 3:44 AM, Miguel Garcia wrote:
> >
> >> Reading Section 4.2 of Outbound-04, there is a sentence 
> that came  to my 
> >> attention.
> >>
> >>    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.
> >>
> >> I think it is not appropriate to use a MUST strength in 
> this case.  I 
> >> suspect that the spirit of the draft is to offer high  
> availability by 
> >> making the UA to establish one flow per URI, which  is a 
> good spirit. 
> >> However, one has to evaluate the cost of  establishing one 
> flow per URI, 
> >> which might be quite high in terms  of battery 
> consumption, for example 
> >> (due to STUN refreshes).
> >>
> >> I also believe the MUST is misused here because it is not 
> an  absolute 
> >> requirement for the specification. In other words, the SIP 
>  outbound 
> >> procedures work OK even if the UA establishes just one  
> flow (even when 
> >> it is provisioned with several outbound URIs).  Nothing is broken.
> >>
> >> So, we should be looking at adding a paragraph that describes the 
> >> benefit of establishing one flow per outbound URI, but 
> letting up  to the 
> >> UA's policy to decide on the absolute number of established  flows.
> >>
> >> I would suggest to replace the above mentioned sentence 
> with  something 
> >> around these lines:
> >>
> >>    For each outbound proxy URI in the set, the UA MAY send a
> >>    REGISTER in the normal way using this URI as the 
> default outbound
> >>    proxy. Sending one REGISTER per outbound proxy URI decreases the
> >>    likelihood of interrupted service due to dropped 
> connections at the
> >>    cost of maintaining a living flow which each outbound 
> proxy server.
> >>
> >> Comments?
> >>
> >> /Miguel
> >>
> >> -- 
> >> Miguel A. Garcia           tel:+358-50-4804586
> >> sip:[email-masked]
> >> Nokia Research Center      Helsinki, Finland
> >
> > _______________________________________________
> > 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 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Jeroen Van Bemmel <[email-masked]>
Date: Fri, 07 Jul 2006 09:13:08 +0200

Inline

> Thats not my read.
> 
> The draft says that a client has to support at least 2 outbound URI, and 
> that it MUST send a REGISTER for each. However, that doesn't mean a 
> domain *has* to provide two; it can also provide one. A domain would 
> only provide one if it knows that it doesn't need two for purposes of 
> reliability, or if it doesn't require reliability of service.

True, but then the UA does not have an alternative outbound server, in 
case the supplied one fails. 

[jvb] you could still have multiple alternatives from DNS (ie traditional DNS that is)

What I don't like is the one to one 
relation between the number of supplied outbound URIs and the number of 
flows (and REGISTER).

[jvb] indeed, especially since the domain may have no control over how many URIs the client discovers. Manual entry is one example. And what happens  if one URI comes via manual provisioning and 2 more via DNS as per outbound-discovery?

Additionally I suspect that users may still impose local policies in the 
UAs as for the number of established flows, independently of the number 
of learned URIs. So, the MUST in the spec is always subject to local policy

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 10 Jul 2006 10:59:11 -0400

And what is your approach to re-registration avalanches?

Oh, wait that is not a handset problem.

Mike

> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Monday, July 10, 2006 9:58 AM
> To: Rohan Mahy
> Cc: [email-masked]; Cullen Jennings (fluffy)
> Rohan Mahy wrote:
> > So we are back to a pure semantic question.  Does the 
> service get to 
> > decide how many flows the UA opens (up to an implementation 
> supported 
> > maximum), does the UA decide how many flows to open, or is 
> there some
> > negotiation?   I still think the current semantics are 
> fine, because 
> > they allow a single flow to a URI that can still load-share and 
> > failover to a large number of actual servers.  Of course there are 
> > others who don't like that because it relies on DNS for failover.
> > 
> > thanks,
> > -rohan
> > 
> 
> I thought a bit more about this. I believe the service 
> provider has no more say than providing the list of outbound 
> URIs. The UA has to decide on how many flows to open, and 
> what is the cost of this decision. I can imagine a policy in 
> my laptop that makes the number of flows dependent on whether 
> I am plug to the main or running on battery, so that if I am 
> running on batteries I keep only one flow. My provider will 
> never know what is my battery status: He can only set the 
> maximum number of flows, but not the minimum.
> 
> /Miguel
> 
> -- 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 10 Jul 2006 15:30:02 -0400

Agree, it is not a panacea, but a means of mitigation.

I tend to feel things have scaled well when we start talking millions.
But, I know of some systems that think in terms of tens to hundreds of
thousands.

Of course, you would need to detect and re-establish IP connectivity.

As for the avalanche on a replacement proxy in the power-out region
(versus the one outside that region), you could spread the load across a
much longer time period (tens of minutes, if you like), while the backup
proxy could deliver calls following the connectivity re-establishment.

Mike

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, July 10, 2006 2:23 PM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04
> 
> My point was just that it's not a panacea for the avalanche 
> issue.  It helps in various failure modes, doesn't in others. 
>  The power outage was just an extreme failure mode example; 
> there are others.  
> 
> I know everyone's mileage varies, but 2 Minutes lets a heck 
> of a lot of UAs register, from what I've seen of registrar 
> reg/sec load handling.  Like at least in the thousands.  If 
> more than thousands of UAs are registering anew, the odds are 
> it was either because they've all rebooted due to regional 
> power loss, or their primary proxy died/lost-comms.  In the 
> former case multiple flows would not help.  In the latter 
> case outbound would have all the UAs connecting to a backup 
> for that failed primary in 90 seconds (ie, they use the 
> secondary proxy, but then create a replacement for the failed 
> flow).  So the avalanche is still there, just for another proxy, no?
> 
> -hadriel
> 
> 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Monday, July 10, 2006 11:43 AM
> > To: Hadriel Kaplan; Miguel Garcia; Rohan Mahy
> > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04
> > 
> > That 2-minute period could be smoothed out over a much 
> longer period 
> > of time if there were multiple flows.
> > 
> > Your power outage example assumes a specific topology relative to 
> > where power was lost.  I disagree with assuming a poor 
> network design 
> > as argument for multiple flows not handling the outage.
> > 
> > I do agree that proxies need to handle such overloads, but 
> that leads 
> > right back to the service being out for longer than the 
> acceptable (?) 
> > 2 minute period.
> > 
> > I am not adverse to wireless networks choosing to make the 
> tradeoff of 
> > battery time to increased possibility of missing incoming calls, I 
> > just think that there needs to be agreement between the network and 
> > client as to what is acceptable and what those tradeoffs are, such 
> > that neither has negative impacts.
> > 
> > Mike
>