Re: [Sipping] comments on draft-shen-sipping-load-control-event-package

[Henning Schulzrinne <[e-mail]>]

Thanks for your comments.

On Jul 27, 2008, at 8:55 PM, Jonathan Rosenberg wrote:

> A few comments on this draft:
>
> * a think a bit more discussion is needed on how this is different  
> from the work being done by Volker and the overload team. Clearly  
> there is amount of overlap, in that both mechanisms attempt to work  
> to reduce overall network congestion during periods of load. The  
> mechanism here is much more policy-centric, and targeting the  
> specific case where load is directed to a particular number.  
> However, with a sufficiently general policy, could this not be used  
> as an alternative feedback mechanism between a proxy and its  
> upstream neighbor, to reduce the load on all traffic?

Yes, this had occurred to me. I didn't want to muddle the discussion,  
also because the load-event-package work has notions of pre- 
announcement ("throttle tomorrow at 8 pm"), which don't really apply  
to the in-band feedback in Volker's draft. That said, I have no  
objection to a common format if there's an advantage to that.


>
>
> On the other hand, a more complementary way of thinking about them,  
> is that when the overload mechanism ala draft-hilt-* indicates to an  
> upstream proxy, 'hey, I'm overloaded, please reduce by 20%', now  
> that proxy needs to make a POLICY decision about which traffic to  
> discard to achieve said goal. Though it could randomly throw away  
> traffic to achieve it, another approach would be to selectively  
> discard traffic based on priorities. draft-shen could be thought of  
> as a way to distribute those policies, directing a proxy how to  
> discard traffic when the overload mechanism suggests its needed. I  
> don't think thats quite your formulation, but if it was done that  
> way it would make them clearly complementary.

Agreed. One could well imagine that feedback overload control would  
trigger the mechanism, as in "If there's overload, here's the low  
priority class of calls you should kill first" rather than "always  
drop 20% of the American Idol" calls. Kind of like an inverse resource  
priority mechanism.


>
>
> * The draft talks about each proxy needing to subscribe to the  
> package from its neighbors. I don't see how this works when the  
> topology is such that requests could loop around, so that a  
> particular proxy can be both an upstream and downstream neighbor

This is not for each request, but adjacency is defined as "sending  
traffic". Thus, if proxy A sends traffic to proxy B, it would  
subscribe to the filters provided by B. If B also sends to A, B would  
subscribe to A. Clearly, to avoid infinite loops, you'll have to have  
a mechanism that prevents delivering the same filter back to A that  
you just received *from* A. As long as you deliver each filter once to  
each such neighbor, things should be ok. A proxy may get the same  
filter from multiple places, but there shouldn't be loops.

I'm trying to find a reasonably simple distribution mechanism that  
doesn't require running a spanning tree protocol on the world's SIP  
proxies.

This clearly requires more discussion in the draft.


>
>
> * some more discussion of use cases would be good; defining the  
> parameters of the xml doc would really depend on understanding what  
> kind of things are useful to use to as criteria for determining  
> which traffic to discard
>

Definitely. I suspect we want source and destination (both precise and  
prefix/domain matches), in addition to RPH information.

>
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [e-mail]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP