Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-design-00 [was RE: draft-gurbani-soc-overload-control-01 in the IETF archives]

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:21:17 -0400

Paul

From an operator perspective, negotiating would make the solution useless

Martin C. Dolly
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
+1.609.903.3360

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Volker Hilt <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri Jul 23 09:18:29 2010
Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-design-00 [was RE: draft-gurbani-soc-overload-control-01 in the IETF archives]

ISTM we are just talking past one another on this point and not 
converging in any way. Perhaps some informal face-to-face time will help 
here.

	Thanks,
	Paul

Volker Hilt wrote:
> Partha,
> 
> I'm worried about the complexity and possible instabilities we are 
> introducing if the unit of feedback is subject to negotiations. What if 
> there is no agreement? What if units are changed from requests to 
> sessions at some point? The upstream neighbor would then have to reset 
> all measurements. It would also need to support many measurements and 
> method selection methods.
> 
> I think that specifying a common unit for feedback is beneficial. One 
> that comes to mind is feedback based on requests.
> 
> Thanks,
> 
> Volker
> 
> 
> On 7/23/2010 12:35 PM, Parthasarathi R (partr) wrote:
>> Hi Volker,
>>
>> I agree that dropping of the message or dialog or session in the
>> neighboring entity is only the possible way to avoid overload control.
>> The local policy in the neighbor alone will not solve the entire problem
>> by receiving the number of messages as the number of SIP message is not
>> related to dialog and session and it will not serve the purpose. The
>> current SoC design (Sec 9 of draft-ietf-soc-overload-design-00) assumes
>> that SIP message is the only unit between two SIP hops. The current
>> approach complicates the overload design in case of B2BUA/UA.
>>
>> The design should not restrict unit and should be flexible. The unit
>> shall be messages, transaction, dialog, or session.
>> draft-jones-sip-overload-sce-00.txt is one of the example where session
>> (SCE) is provided as a unit. It will be better in case the algorithm is
>> designed without specific unit in mind. The unit shall be agreed upon
>> between two entities in prior. As you mentioned in the earlier mail, the
>> unit shall be agreed between two SIP Hops through Non-SIP or
>> configuration mechanism.
>>
>> Thanks
>>
>> Partha
>>
>> ------------------------------------------------------------------------
>> *From:* [email-masked] on behalf of Volker Hilt
>> *Sent:* Thu 7/22/2010 2:09 AM
>> *To:* Paul Kyzivat (pkyzivat)
>> *Cc:* [email-masked]
>> *Subject:* Re: [sip-overload] draft-gurbani-soc-overload-control-01 in
>> the IETF archives
>>
>> On 7/21/2010 6:10 PM, Paul Kyzivat wrote:
>>  > Volker Hilt wrote:
>>  >> Paul,
>>  >>
>>  >> it is the upstream neighbor that needs to make a decision about which
>>  >> messages to drop in an overload situation. This server is a 
>> legitimate
>>  >> server on the path of the messages it needs to drop and, 
>> therefore, can
>>  >> make valid decisions about which messages to drop.
>>  >
>>  > It MAY make any dropping decision it wants.
>>  > If its dropping them because it is overloaded, then it can judge 
>> whether
>>  > they are valid decisions based on its own criteria.
>>  > But when its dropping them for the benefit of its downstream neighbor,
>>  > then whether the choices are valid ought to be judged based on the
>>  > overloaded node's criteria.
>>  >
>> A server needs to drop messages because of overload. This can be
>> overload in itself or overload in a downstream neighbor (if the server
>> would not react, it is even possible that the overload of the neighbor
>> eventually leads to overload of itself).
>>
>> Main point is that the server needs to drop messages to deal keep the
>> network afloat. I don't see the benefit of engaging in policy
>> negotiations at that point. The local server can make decisions that are
>> perfectly valid.
>>
>>  > In some cases they may natively have the same criteria. But I don't 
>> see
>>  > how we can assume they always do.
>>  >
>>  >> If proxies are required to exchange dropping policies, things get
>>  >> complex very quickly. First, proxies would have to agree on a set of
>>  >> policies that are supported by the upstream and the downstream 
>> neighbor.
>>  >> E.g., which features of messages can be used to formulate policies
>>  >> (differentiate between message types, in/out-of-dialog messages, RPH,
>>  >> SDP bodies, ...?).
>>  >
>>  > Regardless of whether the policies are negotiated or are configured, I
>>  > think there needs to be some agreement about the policies that are
>>  > candidates for selection.
>>  >
>> A draft should make recommendations on selections policies that have
>> proven to be useful.
>>
>>  > For instance, if the goal was to have a consistent policy across the
>>  > enterprise, that might be hard to achieve with products from multiple
>>  > vendors if they don't offer the same selection of policies.
>>  >
>>  > In theory I suppose you might consider an enterprise wide policy that
>>  > favors INVITE dialogs and their in-dialog messages over SUBSCRIBE
>>  > dialogs and their related messages. But if you deployed that 
>> wholesale,
>>  > it wouldn't work when you got to a cluster of servers that were solely
>>  > engaged in handling presence, and so never see INVITEs.
>>  >
>>  > Of course you could then configure a different policy for that cluster
>>  > of servers.
>>  >
>> Yes.
>>
>>  > But at boundaries where you have a full range of traffic types coming
>>  > in, then routed to more specialized servers, you may need different
>>  > algorithms depending on the destination - selected with the needs 
>> of the
>>  > destination in mind.
>>  >
>> Yes, that would be useful.
>>
>>  >> Then policies would have to be negotiated. There are lots of 
>> questions
>>  >> right there: when will this negotiation happen? When the first 
>> message
>>  >> is exchanged between two servers? At bootup time? Some time else? 
>> What
>>  >> if a server rejects submitted drop policies? Will that be the end 
>> of the
>>  >> communication between the two servers? Or trigger another round of
>>  >> policy negotiations? How will these policies be encoded?
>>  >>
>>  >> And finally servers would have to support mechanisms for selecting
>>  >> packets that can implement these policies. These mechanisms need 
>> to be
>>  >> generic enough to support all the possible policies that can be 
>> encoded.
>>  >>
>>  >> What would be the benefit of going through all this trouble?
>>  >
>>  > While negotiating the policy *might* have value, that may not be
>>  > necessary. All I said was that the dropping be done with the needs of
>>  > the overloaded node in mind. That still might be configured.
>>  >
>> I think we are in agreement.
>>
>> Thanks,
>>
>> Volker (as individual)
>>
>>
>>
>>
>>  >>
>>  >> On 7/21/2010 3:25 AM, Paul Kyzivat wrote:
>>  >>> Without replying to individual points, I want to discuss "local 
>> policy"
>>  >>> for the drop algorithm.
>>  >>>
>>  >>> If there are to be varying policies, then ISTM the gold standard 
>> is for
>>  >>> the upstream node to use the policy that the overloaded node 
>> considers
>>  >>> would be best for it.
>>  >>>
>>  >>> Then the question is: how would the upstream node know and be 
>> prepared
>>  >>> to use that policy?
>>  >>>
>>  >>> The simple answer would be: because it has been configured by 
>> someone
>>  >>> who knew that. The more complex answer is that the downstream node
>>  >>> communicates the desired algorithm to the upstream node.
>>  >>>
>>  >>> What seems entirely wrong to me is the upstream node employing some
>>  >>> local policy that is not informed in any way of the
>> needs/preferences of
>>  >>> the overloaded node. A standardized algorithm would be better than
>> that.
>>  >>>
>>  >>> Configuring the local policy may work well in some environments. But
>>  >>> mostly in homogeneous ones. In a multivendor environment, without 
>> any
>>  >>> standard selection of policies to choose from there may be no 
>> suitable
>>  >>> policy available and no way to match the available policies 
>> against the
>>  >>> needs.
>>  >>>
>>  >>> Thanks,
>>  >>> Paul
>>  >>>
>>  >>> Volker Hilt wrote:
>>  >>>> On 7/20/2010 1:49 AM, Paul Kyzivat wrote:
>>  >>>>> Volker Hilt wrote:
>>  >>>>>> For any feedback, it will be important that a SIP server can
>> determine
>>  >>>>>> the outcome of setting the oc parameter to a certain value. For
>>  >>>>>> example,
>>  >>>>>> it should be able to expect that setting oc=30 will lead to a
>>  >>>>>> reduction
>>  >>>>>> in the number of requests by 30%. The semantics of the oc 
>> parameter
>>  >>>>>> should be well-defined and something that is clear and easy to
>> measure
>>  >>>>>> (e.g., number of requests). The question is then how a server can
>>  >>>>>> select
>>  >>>>>> the messages to be dropped to implement the oc value.
>>  >>>>>
>>  >>>>> While it would be a big problem if there was no correlation
>> between the
>>  >>>>> requested reduction and the actual reduction, its not at all clear
>>  >>>>> to me
>>  >>>>> that perfect correlation is necessary.
>>  >>>>>
>>  >>>> Yes, I don't think it will be possible to achieve perfect 
>> correlation.
>>  >>>> However, having both diverge too much will have an impact on the
>>  >>>> stability of the mechanism.
>>  >>>>
>>  >>>>> In the real world, the requested percentage reduction is just a
>>  >>>>> guess at
>>  >>>>> how much will have the desired effect.
>>  >>>>
>>  >>>> The requested percentage is the output of a control algorithm.
>>  >>>>
>>  >>>>> Even if the reduction complies
>>  >>>>> perfectly, and the future load is perfectly consistent with the 
>> past
>>  >>>>> load, it might not have the desired effect, since not all
>> messages will
>>  >>>>> affect the recipient equally.
>>  >>>>>
>>  >>>>> And also, the arriving load will not perfectly maintain the prior
>> rate
>>  >>>>> or other characteristics.
>>  >>>>>
>>  >>>> Yes. There is also the round trip time that adds delay before 
>> feedback
>>  >>>> takes effect.
>>  >>>>
>>  >>>>> So I think there need only be a reasonable positive 
>> correlation. It
>>  >>>>> will
>>  >>>>> be a feedback system that adjusts things to a satisfactory value.
>>  >>>>>
>>  >>>> I agree there will be noise and correlation won't be perfect.
>> However, a
>>  >>>> low correlation will lead to poor performance.
>>  >>>>
>>  >>>>>> For a SIP server, there are two categories of requests: 1) 
>> requests
>>  >>>>>> that
>>  >>>>>> are candidates for reduction and 2) requests that should not be
>>  >>>>>> dropped
>>  >>>>>> (except for catastrophic situations).
>>  >>>>>
>>  >>>>> agreed
>>  >>>>>
>>  >>>>>> The first category would contain
>>  >>>>>> out-of-dialog messages (e.g., new INVITEs, SUBSCRIBES, ...) 
>> whereas
>>  >>>>>> the
>>  >>>>>> second category would contain in-dialog requests, requests
>>  >>>>>> protected by
>>  >>>>>> RPH policies,... (along the lines of Vijay's notes).
>>  >>>>>
>>  >>>>> As I noted earlier, its far from clear what the criteria should
>> be for
>>  >>>>> sorting messages into categories 1 and 2. What you describe is one
>>  >>>>> possibility. But what is the reason for that choice, vs. some 
>> other
>>  >>>>> like
>>  >>>>> the one I suggested a few days ago?
>>  >>>>>
>>  >>>> My main point is that we only need 2 categories: request that are
>>  >>>> candidates for reduction and request that are not. No need for a 
>> more
>>  >>>> complicated priority order.
>>  >>>>
>>  >>>>> (I'm not suggesting mine is objectively better. Only that in the
>>  >>>>> absence
>>  >>>>> of any criteria its equally good.)
>>  >>>>>
>>  >>>> I agree. Each server can set up local policies to determine which
>> set is
>>  >>>> best for its specific deployment/implementation.
>>  >>>>
>>  >>>>>> A draft will need to provide clear guidelines about which 
>> requests
>>  >>>>>> fall
>>  >>>>>> into the first and which fall into second category. I'd expect
>> some of
>>  >>>>>> these guidelines to be MUST strength. E.g., I can't think of a 
>> case
>>  >>>>>> where someone would discard mid-dialog messages before invites.
>> There
>>  >>>>>> need to be local policies as well (e.g., for RPH).
>>  >>>>>
>>  >>>>> Suppose you have INVITE dialogs, and SUBSCRIBE dialogs. The 
>> subscribe
>>  >>>>> dialogs each have a bunch of NOTIFY messages in them.
>>  >>>>>
>>  >>>>> And assume that the dialogs are long lived, so that the NOTIFY
>> messages
>>  >>>>> dominate the traffic.
>>  >>>>>
>>  >>>>> You could certainly make the case that it would be better to 
>> reject
>>  >>>>> NOTIFY messages. Rejecting INVITES wouldn't help much at all, and
>>  >>>>> rejecting out of dialog SUBSCRIBE messages wouldn't help much 
>> for a
>>  >>>>> long
>>  >>>>> time.
>>  >>>>>
>>  >>>> Yes, it might be reasonable to make INVITE, SUBSCRIBE and NOTIFY
>>  >>>> messages part of category 1. INVITE mid-dialog messages will 
>> probably
>>  >>>> still fall into the second category. In the end, it will be local
>> policy
>>  >>>> to determine what is in each category.
>>  >>>>
>>  >>>>>> Once the categories are set, a SIP server can determine fairly
>> easily
>>  >>>>>> which fraction of requests it is processing falls into the first
>>  >>>>>> category and which falls into the second category. E.g., 40% 
>> may be
>>  >>>>>> eligible for reduction, 60% not.
>>  >>>>>
>>  >>>>> Well, depends on what you mean by "fairly easily". I guess it 
>> would
>>  >>>>> have
>>  >>>>> to maintain historic arrival rate for each category, computed
>> over some
>>  >>>>> time interval, and apply the percentage reduction to that.
>>  >>>>
>>  >>>> I think computing an arrival rate is fairly straight forward for a
>>  >>>> proxy. It would have to be weighted to give new values higher
>>  >>>> significance.
>>  >>>>
>>  >>>>> But its
>>  >>>>> possible that even 100% of category 1 won't be enough, in which
>> case it
>>  >>>>> will need to dip into category 2 anyway.
>>  >>>>>
>>  >>>> Yes. See below.
>>  >>>>
>>  >>>>> Finding a good interval over which to calculate the arrival rate
>> could
>>  >>>>> be tricky too. If its longer than the interval over which the oc
>> value
>>  >>>>> changes it can be unstable. But if its too short you won't get an
>>  >>>>> accurate sample.
>>  >>>>>
>>  >>>>>> The server can then convert the overall oc feedback value it has
>>  >>>>>> received to a value that only applies to category 1). E.g., if
>> it has
>>  >>>>>> received oc=10 in the above example, it would use 10 / 40 * 100 =
>>  >>>>>> 25 on
>>  >>>>>> requests in category 1). I.e., it would discard 25% of the
>> message in
>>  >>>>>> category 1 which leads to the desired overall reduction of 10%.
>>  >>>>>> Messages
>>  >>>>>> in category 2 remain untouched.
>>  >>>>>>
>>  >>>>>> The server can use random discard as discussed earlier to
>> achieve the
>>  >>>>>> 25% reduction of messages in category 1).
>>  >>>>>>
>>  >>>>>> In a catastrophic case when there are not enough messages in
>>  >>>>>> category 1
>>  >>>>>> a server can broaden the scope of category 1). This is possible
>> since
>>  >>>>>> assigning messages to categories and measuring their fraction is
>>  >>>>>> completely local. As an alternative it might start targeting
>>  >>>>>> messages in
>>  >>>>>> category 2 as well. This is simpler but provides less control 
>> over
>>  >>>>>> message selection.
>>  >>>>>
>>  >>>>> Broadening the definition of category 1 requires that you already
>> rate
>>  >>>>> data for the new definition. But yes, its still doable. It just 
>> gets
>>  >>>>> more complex quickly.
>>  >>>>>
>>  >>>> Yes, you'd have to collect data for the new category. You can start
>>  >>>> collecting the arrival rate for the broader category 1 at a lower
>>  >>>> threshold (or even all the time). I don't see the significant
>> complexity
>>  >>>> this will add. If you want to keep things really simple, a proxy 
>> can
>>  >>>> simply start going after messages in category 2 if category 1 is
>>  >>>> exhausted.
>>  >>>>
>>  >>>> Volker (as individual contributor)
>>  >>>>
>>  >>>>
>>  >>>>>>
>>  >>>>>>
>>  >>>>>>
>>  >>>>>>
>>  >>>>>> On 7/15/2010 9:13 PM, Hadriel Kaplan wrote:
>>  >>>>>>>
>>  >>>>>>>
>>  >>>>>>>> -----Original Message-----
>>  >>>>>>>> From: [email-masked]
>>  >>>>>>>> [mailto:[email-masked]]
>>  >>>>>>>> On Behalf Of Paul Kyzivat
>>  >>>>>>>> Sent: Thursday, July 15, 2010 2:45 PM
>>  >>>>>>>> To: Vijay K. Gurbani
>>  >>>>>>>>
>>  >>>>>>>> At a basic level, all messages are the same, so that it 
>> makes no
>>  >>>>>>>> difference which ones you drop, as long as the total number of
>>  >>>>>>>> messages
>>  >>>>>>>> delivered is reduced.
>>  >>>>>>>
>>  >>>>>>> While that may be true in some ultra-simple systems, like a
>> proxy, in
>>  >>>>>>> practice I doubt that's generally true. Lots of systems take 
>> more
>>  >>>>>>> CPU
>>  >>>>>>> resources for new INVITEs than they do for many other 
>> messages, for
>>  >>>>>>> example, for a whole host of reasons. Even in a legitimate
>>  >>>>>>> "proxy", I
>>  >>>>>>> bet out-of-dialog messages take more simply because of the
>>  >>>>>>> routing/DNS
>>  >>>>>>> piece.
>>  >>>>>>>
>>  >>>>>>> But more importantly, I doubt whatever we do will succeed in the
>>  >>>>>>> market place if in-dialog messages aren't given preference over
>>  >>>>>>> out-of-dialog ones, at least for INVITE-based dialogs. It's one
>>  >>>>>>> thing
>>  >>>>>>> to get a busy-tone or a call attempt delayed due to re-route;
>> it's a
>>  >>>>>>> completely different thing to have the call fail after 
>> ringing and
>>  >>>>>>> pickup, or not cleared cleanly with a BYE.
>>  >>>>>>>
>>  >>>>>>>
>>  >>>>>>>> I guess the next level of consideration is one of policy -
>>  >>>>>>>> specifically
>>  >>>>>>>> regarding messages with R-P headers. That is one form of
>>  >>>>>>>> prioritization
>>  >>>>>>>> that is hard to argue with. (But it requires consistent policy
>> among
>>  >>>>>>>> upstream and downstream nodes. If upstream favors messages
>> with some
>>  >>>>>>>> R-P, but the overloaded node doesn't consider those special, 
>> then
>>  >>>>>>>> the
>>  >>>>>>>> effort has been counterproductive.)
>>  >>>>>>>
>>  >>>>>>> Yeah that's a toughy. It would be lovely not to have to 
>> coordinate
>>  >>>>>>> such, but I can see the case where it would lead to a very low
>>  >>>>>>> goodput. :(
>>  >>>>>>>
>>  >>>>>>> -hadriel
>>  >>>>>>> _______________________________________________
>>  >>>>>>> sip-overload mailing list
>>  >>>>>>> [email-masked]
>>  >>>>>>> https://www.ietf.org/mailman/listinfo/sip-overload
>>  >>>>>> _______________________________________________
>>  >>>>>> sip-overload mailing list
>>  >>>>>> [email-masked]
>>  >>>>>> https://www.ietf.org/mailman/listinfo/sip-overload
>>  >>>>>>
>>  >>>>
>>  >>
>> _______________________________________________
>> sip-overload mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
> 
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload