On Sep 26, 2007, at 10:25 AM, Brian Rosen wrote:

Yeah, but I think you are starting with an incorrect assumption that if you improve the average response, you will get a better global result. The assumption usually made in these systems is that the network is horribly overloaded; nearly all low priority messages are timing out and the system is choked. You are way past the point where anything like what you are
talking about can help.

Perhaps. But if you have to receive, enqueue, and parse the messages to find out they have high priority or not, and if that's a substantial part of the workload, and NOT forwarding the low-priority responses is going to dramatically increase your workload (due to cascade), then you gain nothing and lose much by using RPH to prioritize responses. This needs to be tied to some lower-layer mechanism (like a diffserv marking) that can allow for discard without so much parsing.

Or it needs to be tied to a pushback "congestion notification" kind of approach, and we have SIP set up with no way to push back against responses, just against requests. So if a proxy is having to discard a response because of congestion, the proxy needs to inform the sender of the request that generated the response to back off.

Perhaps a proxy could MODIFY a response, turning it into a terminal "retry after" or something like that. Of course, then it wouldn't be a proxy -- it would be a B2BUA.

Maybe a header that says "I don't care if this looks like a 200 OK, but some proxy in the path has decided an overload applies, so abandon this request and don't retry" would work, but then we're in the middle-to-end authentication realm, and that's a mess all on its own.

Nope, I think SIP is just set up where trying to prioritize responses doesn't work.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to