[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] comments on draft-shen-sipping-load-control-event-package
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
jdrosen at cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP