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.
In that scenario, you pick out the high priority messages, get them through, and the rest of the users are hosed. They were hosed to begin with. I suspect that you could model well enough and discover that the difference between the work of parsing messages to find high priority responses and fully handling all responses in a stateless proxy is pretty much don't care. I think though that the priority people would be very suspicious of the model. I don't think you could show that handling priority responses behind non priority requests would have that characteristic. Then you get to talking about designing proxies so that they handle all responses before any requests. But I think it would take some seriously difficult modeling to show that it worked well, and you could always find corner cases where it didn't. That may mean GETS-like services could reasonably work that way. MLPP systems would not; priority is absolute. Brian > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 25, 2007 6:08 PM > To: Janet P Gunn > Cc: IETF SIP List > Subject: Re: [Sip] What does draft-polk-sip-rph-in-responses-00 get us? > Isthat what we want? > > > On Sep 25, 2007, at 2:35 PM, Janet P Gunn wrote: > > > Dean Willis <[EMAIL PROTECTED]> wrote on 09/25/2007 > > 03:05:47 PM: > > > > > > > > It seems like there's more motivating draft-polk-sip-rph-in- > > > responses-00 than just the need to prioritize access to scarce > > > gateway resources. A lot of the people I've talked to are thinking > > > that it is also useful for prioritizing message processing in > > > congested proxies or other SIP nodes (like B2BUAs, call center > > > queues, whatever). > > > > > > It has even been suggested that the RPH value might be used by a > > > congested node for selective discard of responses, which has some > > > interesting impacts on the overload queueing model. > > > > > > > > Req 13 in draft-ietf-sipping-overload-reqs already provides for this > > > > REQ 13: The mechanism must not dictate a specific algorithm for > > prioritizing the processing of work within a proxy during > > times of > > overload. It must permit a proxy to prioritize requests > > based on > > any local policy, so that certain ones (such as a call for > > emergency services or a call with a specific value of of the > > Resource-Priority header field [3]) are processed ahead of > > others. > > > > I'm far more concerned with what it does to the mathematics of the > overload model than what it does to the protocol specification. > > SIP, in my experience, is sensitive to what I call "cascade > failures". One element suffers a delay (overload, garbage collection, > whatever) thereby causing a message (request or response) to get > delayed. This delayed message adds enough latency to pop a retransmit > timer, causing a request to get retransmitted (even though the first > message may still be "in-flight"). This additional message adds to > the workload on the already delayed node (possibly incurring also > additional responses), causing further delays and further > retransmissions. At certain thresholds, this can suddenly load the > network with messages, such that a "melt-down" occurs wherein all > requests time out and are retransmitted the maximum number of times > before failing. If the request arrival rate (new users who haven't > yet noted the congestion, or old ones who are just "trying again") > exceeds the clearing rate of the network, the whole thing can > basically stay locked up indefinitely. Remember, you have to parse a > message to see its RPH, and if you're overloaded trying to parse a > message flood you're not going to meet your delivery requirements on > high-priority messages. > > Most modeling work I know of has proceeded under the pattern that > requests can be delayed (or "pushed back" on like a retry-after), but > that responses move with all available speed and are never > deliberately discarded. This is consistent with SIP's authentication > model that allows challenging a request but not a response. > > When we start discarding the responses, the queueing model gets a lot > more complicated. Not only do we have the same retransmission > cascade, but we add a possible confounding of the states at the end > points. While SIP UAs should of course handle repeated requests, it's > certainly more complex for them to see a request again to which they > have already responded than it is for them to see a request they've > never seen before. More state stacks up, more strange things can > happen, and I don't know what it will do to the resultant system. > > Notice that this thinking is evident even in the section from > overload-reqs you quote, which talks only about prioritization of > requests, not prioritization of responses. > > Consequently, adding text that seems to facilitate and encourage > discarding or deferral (or, I suppose, prioritization in general) of > responses makes me queasy. It might turn out ok, but it certainly > sets my spider-senses to tingling, and makes me want to understand > the risks better before I suggest it to anybody. > > For you students out there looking for a modeling project, > quantifying the impact of this would make a great thesis effort. > > -- > 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 _______________________________________________ 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
