RPH is useful in many contexts. One is a network where it is essential to have priority, both for signaling and for packets. These may not be walled gardens, but they are not the open Internet. The example in the Emergency Services IP Network that comes to mind is the "evacuate" message sent from the command center to every responder in the building which is about to collapse. The likelihood that the network serving the responders is overloaded is very high. Voice chatter between, say two fireman is important, but the "evacuate" is more important, and in fact will absolutely preempt everything else. On that network, it makes a whole lot of sense.
The "GETS" example is probably more what you were thinking of. Imagine that we're talking about the data network in a public wireless network near ground zero. It is completely overloaded. There is not enough capacity to serve the demands being put on it. A responder with a GETS SIM should be able to get a call through, assuming that there are not enough such people that they overload the network. This is a SIP problem: there are more calls being attempted then the network can handle. It cannot treat them in a fair way; there is no fair here. The responder gets through, the random caller may not. That has nothing to do with gateways. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 5:23 PM > To: Dwight, Timothy M (Tim); DRAGE, Keith (Keith); [email protected] > Subject: RE: [Sip] Progression of draft-polk-sip-rph-in-responses-00 > > 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 _______________________________________________ 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
