The resource priority header is only useful for getting priority in resource constrained gateways to the PSTN (not enough TDM lines available in a crisis). The solution to this is really to put emergency centers on the Internet with adequate broadband and avoid the PSTN altogether.
Priority on the Internet at large gets us into the issue of Internet Neutrality and yours truly believes priorities are evil. We can discuss offline why priorities in the Internet are evil. In short: The Co-Chair is right :-) Henry -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:[EMAIL PROTECTED] Sent: Saturday, September 22, 2007 12:02 AM To: DRAGE, Keith (Keith); [email protected] Subject: RE: [Sip] Progression of draft-polk-sip-rph-in-responses-00 OK, you've got it wrong. ("be careful what you ask for, because you may get it..."). The capability supported by the Resource Priority Header is not meant, or anticipated, to be "good for" the network. Its intent is to support a higher-then-normal level of certainty that service will be expeditiously provided, to a "special" community of users. In this case "service delayed is service denied", i.e., if it takes an hour for the fire department to get through to the police department your house is probably toast. So it's not good enough that these calls eventually go through, The issue to debate is whether the inclusion of RPH in response messages, serves that objective. If it does, and in so doing it makes certain network elements work harder or congest worse or in general results in degradation of service to servers not in the "special" community, so be it. Other comments below. Best regards, tim > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 1: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). With respect, that is not the most relevant question. If inclusion of RPH in response messages serves the end of increasing the certainty that priority requests expeditiously obtain service, it is in principle worth doing. Certainly it is prudent to ask what the side effects would be (e.g., increased congestion), and in principle they might impact the desirability of this enhancement; but the bar for them to do so needs to be set very high. If an airplane hits an office building, it is much, much more important that the agencies tasked with providing emergency services be able to communicate with one another, than it is for everyone who knows anyone that lives in that area to be able to call their friend. > 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. Of course. But the relevant issue is again not the impact on the overloaded system, it is the impact on the certainty that service will be expeditiously provided to priority requests. > > 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. Some variant of that model (prioritizing responses over requests) seems likely to already in use. The question on the table is whether it should be augmented such that responses associated with priority calls are prioritized higher than other sorts of responses. If doing so increases either the certainty or the speed with which service is provided to priority calls, then it seems the enhancement is justified. > > 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 _______________________________________________ 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
