Subject: [Sipping] draft-hilt-sipping-overload-03

From: Volker Hilt <[email-masked]>
Date: Tue, 30 Oct 2007 14:25:31 -0400

A new version of the overload control draft is available at:
http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-03.txt

The main changes to the -02 version are:
- Since this came up multiple times, I've added a more detailed 
specification of an event package for overload control. This should help 
to understand the pros and cons of an event package vs. a new header. 
The discussion of a SIP mechanism for overload control is expanded and 
now focuses on a header vs. an event package.
- Changed the header specification from a 'Load' header to an 
'Overload-Control' header since the purpose of the header is to convey 
overload control feedback and not current load.
- Removed the option to report load from the header.
- Added a reference to Resource-Priority for message prioritization.
- Added a section on overload control algorithms (this is an open issue).
- Moved discussion of local overload control.
- Added on open issue on the need of a fading mechanism for the control 
value.
- Removed sections on calculating load levels and operations and management.
- Lots of other clarifications and editorial changes.

Thanks,

Volker

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Oct 2007 15:38:31 -0400

Howdy,
I haven't been keeping up with any mailing list discussion on this recently (and haven't seen any except the RPH one), so my apologies if this was already asked.

The question I have is on the hop-by-hop SIP response feedback mechanism.  You define the overload info to be in a new header in the response.  Because this can then incorrectly be passed back more than one hop, you have to add an address in it, and rules around deletion.  What I don't get is why you don't just put the info in the Via header, as a param.

So for example, if a proxy supports this mechanism, it inserts an "oc" param in the Via it inserts in requests it sends, which tells the next-hop that it supports this mechanism.  And when the next-hop wants to put the control info in the upstream responses, it sets a value for the param in the top-most Via it received (ie, now "oc=20"), assuming the Via had the param.  So in theory the next-hop will never send oc info unless the previous-hop supported it, and even if it did the previous-hop would always remove it since it strips its own Via.

Thus this would provide explicit support indication, no new headers, no guessing of addresses, no verifying of addresses, etc.

-hadriel

> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2007 2:26 PM
> To: Sipping
> Subject: [Sipping] draft-hilt-sipping-overload-03
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Oct 2007 17:07:41 -0400

> now focuses on a header vs. an event package.

To me, the idea of using a subscribe/notify for overload-control is too problem-ridden to consider.

Pros:
1) You can tell a neighbor you're no longer overloaded, without waiting for it to send you a request.  That to me is a real potential advantage, since that neighbor may not send a request for a long time, e.g. if you fully throttled it.
2) You can tell a neighbor you're overloaded before it sends a request.  Of course this requires sending *it* a request, and handling the retransmission timers for such, subscription state changes with failure codes, and processing a response.  So I don't even see this as an advantage.
3) You can tell a neighbor loading info in general without getting requests.  But that's really just (1) and (2) above, since the only time you really care about it is in those cases.  Unless we're saying this notification of load state is about load-balancing vs. throttling, which this draft no longer does.
4) An event package can contain lots of info, should we want to do add such in the future.  Of course processing such info is itself a burden.
5) You can tell non-neighbors your load - in other words it's a mechanism useful for multi-hop or end-end overload-control, if we could figure out how such a concept were to actually work from a SIP routing perspective. (which I don't think we have)
6) You can challenge subscriptions and notifies, reject them, etc.  I'm not sure what benefits that provides for an overload control mechanism, but it's there.

Cons:
1) You have to know who your neighbors are a priori. (ie, they're provisioned or register)
2) Subscriptions add state and processing.  If a proxy is overloaded at boot up time (not unlikely), this is just more work it needs to do.
3) Notifies add processing, because you need to match it to a subscription dialog, usage, and event type. (vs. a response matching at the transaction layer)
4) If your system is architected with a distributed processing model, for example one which follows the SIP layer model, you can handle sending responses at a very early/low stage.  You can't do so cleanly for sending Notifies.  In other words the mechanism is at a higher layer than it could be.
5) Notifying all neighbors is in effect the worst-case of the response proposal, every time.  With the response proposal, if a neighbor sends a request, you tell it; if it doesn't, you don't.  There's a statistical benefit you gain by not having to assume all neighbors will send requests all at the same overload time.  Even if they did, the net effect would be the same as if you had told them all to not send you requests.  Imagine an outbound proxy with hundreds of thousands of endpoints.  Do all of them subscribe, and the proxy tells them all not to send something when it's getting overloaded?  Ouch.
6) Proxies don't generally need to subscribe for anything, and aren't subscribed to.  They can, as a UA, but they didn't have to before this mechanism.  Every SIP device type handles responses, afaik.
7) There is a non-zero probability you won't have an active subscription from a neighbor - for example, if it just booted up and is sending you the subscribe and that request itself cannot be processed due to overload.  So now we need an overload mechanism for the overload mechanism.
8) Unless we're saying this mechanism only applies to proxies and not UA's, doing this subscribe from UA's exacerbates the Registration avalanche problem.  Reg-event (RFC3680) has proven this in the field (not that it needed proving).

-hadriel