Gee, I think you have it wrong. In MLPP systems priority is absolute. The overall effect on work done is not interesting. It does not matter that you generate more messages by delaying responses to low priority tasks. You MUST process the high priority requests before you process any low priority responses.
I also think you are incorrect in your assumption that delaying responses for low priority sessions will in fact cause more congestion. I'm sure there are circumstances where it does occur, but if you are in serious overload (9/11 events) then the traffic for the retries is going to happen no matter what you do, and you have to get the high priority traffic through. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 2:57 PM > To: [email protected] > Subject: [Sip] Progression of draft-polk-sip-rph-in-responses-00 > > (As WG chair) > > Dean attempted to get this one started a while back and it fell on stony > ground. > > We have now set charter milestones for all the documents we agreed to > progress at the last IETF meeting except for the draft above. > > The reason for this absence is that after discussion with the AD, we are > not convinced that doing this provides a significant benefit. Part of > this may be clarified by revising the draft as an author draft but... > > The essence of the problem is that the application is to that of a > transaction stateless proxy. Of the list of activities specified by RFC > 4412: > > 1. The request can be given elevated priority for access to PSTN > gateway resources, such as trunk circuits. > > 2. The request can interrupt lower-priority requests at a user > terminal, such as an IP phone. > > 3. The request can carry information from one multi-level priority > domain in the telephone network (e.g., using the facilities of > Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves > inspecting or modifying the header field. > > 4. In SIP proxies and back-to-back user agents, requests of higher > priorities may displace existing signaling requests or bypass > PSTN gateway capacity limits in effect for lower priorities. > > The only reason for including a Resource-Priority header in a response > for use in a transaction stateless proxy is item 4 above. This means > that a response for (namespace x, priority 5) could be handled ahead of > a response for (namespace x, priority 4). > > The question is what is the impact of such handling on an overloaded > system, where such priority handling could have a benefit (we assume > that in a system that is not overloaded then responses can be pushed > back pretty much as fast as they are received). If a response processing > gets delayed according to some queueing mechanism, then eventually > timers related to the request at the entity before this proxy will time > out, and the request will be repeated. This increases the processing > load on an overloaded system. > > So in terms of resource priority, is the appropriate model that > responses should always be handled immediately and before the request > queues are handled, or is there a justification for some other model. > > Please respond and tell us we have got it wrong. > > Regards > > Keith > > > _______________________________________________ > 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
