Subject: [Sip] Progression of draft-polk-sip-rph-in-responses-00

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Sep 2007 20:56:31 +0200

(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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 20 Sep 2007 23:35:41 +0200

Keith,

I agree with your assessment, there is little benefit and several 
drawbacks in adding a Resource-Priority header to responses.

- for proxies there is no benefit in processing one response before 
another (at least of the same type, i.e. INVITE or non-INVITE) that was 
received earlier. Both free up memory resources, take about the same CPU 
time and prevent retransmissions in the same way, so all other things 
being equal FIFO processing is preferable (because statistically it 
avoids more retransmissions and achieves a lower memory*time product)
- dropping non-provisional responses is a bad idea, especially in overload
- queuing such responses for too long: idem

One could perhaps argue that provisional responses could be treated with 
lower priority than final responses, but if so this is better 
implemented as a local policy; no need to mark individual responses for 
this.

Some additional points:
- responses cannot be challenged, so responders could claim any priority 
they feel appropriate
- a R-P header would add quite some bytes to the response size, filling 
the network buffers sooner which makes overload situations worse
- is there / should there be a relationship between the priority of the 
request and that of its associated responses? if so, the proxy has 
better ways of achieving this (i.e. encoding an integrity protected 
value in the request, no need for standardization here)

Regards,
Jeroen

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 12:32:56 -0400

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-masked]]
> Sent: Thursday, September 20, 2007 2:57 PM
> To: [email-masked]
> Subject: [Sip] Progression of draft-polk-sip-rph-in-responses-00
> 
> (As WG chair)
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 12:44:30 -0400

Hmmm.  You must have different implementation experience than I do, and you
must not have talked to any MLPP folks.

Inline for more

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Thursday, September 20, 2007 5:36 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sip] Progression of draft-polk-sip-rph-in-responses-00
> 
> Keith,
> 
But that is not the goal of the RPH.  At least with classic MLPP type
systems, the goal is to make sure that the priority calls go through.  It
doesn't matter what happens to the low priority calls.  It doesn't matter if
the proxy resource is used efficiently.  It doesn't matter that, let's say,
you got 10,000 low priority calls through at the expense of dropping one
high priority call; you should have gotten the one high priority call
through.
  
> - dropping non-provisional responses is a bad idea, especially in overload
Only from an overall load point of view.  Not from the point of view that
the priority is absolute, which for some uses, it is.

> - queuing such responses for too long: idem
As above, no

> implemented as a local policy; no need to mark individual responses for
Well, you must process the one high priority request/provisional
response/final response before you process any low priority final response.

> - responses cannot be challenged, so responders could claim any priority
Policing of R-P-H is a problem, and it's true that policing the response is
harder than policing the request.

> the network buffers sooner which makes overload situations worse
I think this is a red herring.  Memory size is usually not the problem.

> value in the request, no need for standardization here)
This is for a stateless proxy, right?  I don't think that works.
 
Brian

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 21 Sep 2007 17:27:15 +0000

I agree with Brian.  Though I'm not completely comfortable with equating
ETS and MLPP, I think his main point is right on.  The purpose of RPH is
not to improve the efficiency of the network.  It is to provide
certainty of service to a specific community of users.  As long as the
network is operational, their calls must go through.  If that makes the
network less available to others, so be it.  Whether it provides benefit
to proxies or whatever, isn't relevant since it isn't intended to
provide such benefits. 

Tim

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 11:45 AM
> To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)'
> Cc: [email-masked]
> Subject: RE: [Sip] Progression of draft-polk-sip-rph-in-responses-00
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 21 Sep 2007 21:19:09 +0200

Tim, Brian,

First of all a question to clarify the requirements further: is it 
possible/valid for the request to have no specific priority while its 
response does, or should the RPH headers in a response always be the 
same or a subset of those in the request (i.e. copied)? I assume the latter

RFC4412 mostly discusses RPH in the context of endpoints, it states that 
proxies MAY ignore it. It does mention the possibility for a proxy to 
provide differentiated treatment for "responses containing resource 
priority levels", so apparently it was foreseen but omitted from section 3.1

Even if RPH is intended to provide certainty of service, then still I 
think there are other, IMHO better ways to implement this requirement 
without additional standardization. A stateless proxy could send 
priority requests out on a different port (or ports, e.g. 1 per level) 
than ordinary requests, and treat messages received on the priority 
port(s) with the associated priority. There is of course still a risk 
for abuse (which can be mitigated, ports could be random or proxy could 
encode a magic integrity-protected token). The appropriate Diffserv bits 
could be set on each port, and such a scheme enables determining the 
priority even before parsing the message.

If abuse is considered likely and a potential problem, the proxy could 
always revert to stateful behavior for priority requests (in combination 
with the priority port approach for best effect under high load)

My reasoning is as follows: RPH in responses without additional 
mechanisms is not acceptable, as it provides an obvious security hole 
(DoS opportunity). So some additional mechanism is required, e.g. 
stateful operation to remember the authorised level, or some stateless 
mechanism (e.g. as described above). In both cases, the proxy does not 
need (and MUST NOT trust) the RPH header in responses to determine the 
priority level. So why include it?

So even though I may have misinterpreted the purpose of RPH in my 
previous posting, do you agree with the above conclusion?

Regards,
Jeroen

Dwight, Timothy M (Tim) wrote:
>>> another (at least of the same type, i.e. INVITE or 
>>>       
>> non-INVITE) that was
>>     
>>> received earlier. Both free up memory resources, take about 
>>>       
>> the same CPU
>>     
>>> time and prevent retransmissions in the same way, so all 
>>>       
>> other things
>>     
>>> avoids more retransmissions and achieves a lower 
>>>       
>> memory*time product)
>>> - dropping non-provisional responses is a bad idea, 
>>>       
>> especially in overload
>>> One could perhaps argue that provisional responses could be 
>>>       
>> treated with
>>     
>>> implemented as a local policy; no need to mark individual 
>>>       
>> responses for
>>     
>>> this.
>>>       
>>> - responses cannot be challenged, so responders could claim 
>>>       
>> any priority
>>     
>>> they feel appropriate
>>>       
>>> - a R-P header would add quite some bytes to the response 
>>>       
>> size, filling
>>     
>>> - is there / should there be a relationship between the 
>>>       
>> priority of the
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 16:39:46 -0400

> same or a subset of those in the request (i.e. copied)? I assume the
Yes, it should be the latter

> priority levels", so apparently it was foreseen but omitted from section
Yeah, looks like it.  Maybe James would comment on this

> priority even before parsing the message.
I am sure there are several ways to get the effect of a classic MLPP or ETS
system.  There was however, a lot of effort put into RPH and as I recall
there were quite a few suggestions along the line you propose, but the
people working on the problem did not feel they offered a complete solution.
Again, my memory is a bit fuzzy on this, and perhaps James could help.  One
obvious issue is that RPH is standardized, there are implementations here
and coming, and changing mechanisms in the absence of evidence that a change
is needed may not be wise.  We all know about marking the packets.  It's
highly likely in networks that support DiffServ that the packets will be
marked.  However, it's real hard to infer the priority of the signaling from
the priority of the packets.  Some things are impossible (pre-emption as an
example).

> with the priority port approach for best effect under high load)
Yes, I suppose, but a lot of the networks that will use RPH will have some
reasonable ways to police RPH.  Those mechanisms probably would work with
the response. 

> priority level. So why include it?
While policing RPH in the request is somewhat easier than in the response,
it's not that much different.  I do agree that the security situation is
worse enough that it deserves mention in the text, but I don't think the
problem is significant enough to warrant discarding the whole idea.
Specifically, I don't think you need to outlaw stateless proxies.  As an
example, an SBC could police RPH at the edge.  It may be stateful, it may
use some kind of identity mechanism to check authorization...  Having
policed at the edge, the proxies in the middle may be okay in accepting the
RPH.  Wouldn't want to put too much trust in that, but it may be sufficient.

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 21 Sep 2007 17:45:30 -0400

> same or a subset of those in the request (i.e. copied)? I assume the 
latter
No, not a valid assumption. 

In order to support legacy applications, priority markings (e.g. RPH) may 
be set based on the "dialed number"- e.g., by parsing the Request URI.

In some architectures (e.g. IMS) there may be RPH-capable SIP actors (Type 
A) which do not parse the Request URI looking for the key strings.  Such a 
SIP actor would send a SIP Invite WITHOUT RPH.  However, a subsequent 
RPH-capable SIP actor (which DOES parse the Request URI looking for the 
key strings) (Type B) would set RPH, both in Invites sent forward, and in 
responses sent back.

So the "Type A" SIP actor could send out an Invite without RPH, but get 
back a response WITH RPH.

I have oversimplified, but the point is that it is not a valid assumption.

Janet

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 21 Sep 2007 22:01:35 +0000

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

> Sent: Thursday, September 20, 2007 1:57 PM
> To: [email-masked]
> 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

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.

> 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.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sun, 23 Sep 2007 07:05:25 +0000

Jeroen,

I noted previously that "if it helps the application then we should do
it".  Your comments are quite helpful as they address directly the
question of how/whether appending of RPH to responses would help
applications using this mechanism, and how doing so might harm them.

I understand your conclusion to be that [stateful] devices will
"remember" the priority of the request and apply it to the response, and
that stateless devices may effectively be rendered stateful with respect
to the priority applied to responses; therefore it is unnecessary to
signal the priority of the response explicitly.  Moreover, doing so
creates potential for abuse.  Is that a fair summary?

I think there are a couple of small issues with that, but basically I
think it's sound.

1. As Ms. Gunn has pointed out, there are cases where the request is not
marked for priority treatment until it gets some ways into the network.
In principle the originating UA should append RPH but in reality some
won't.  If the network element that appends RPH, generates a response,
it might be helpful that that response contain an RPH.  I would like to
understand "might be helpful" better though.

2. Although I agree that a stateful device should remember the request's
priority (I think 4412 mandates this to prevent colluding end systems
from raising their priority) I'm not sure you want a congested network
element to have to fetch the session state information in order to
decide whether to drop or queue a response.  This is an implementation
issue that I'm not in a position to state with authority, so comments
would be helpful on this point as well.  Certainly I recognize that by
acting upon the RPH received in the response message without validating
it, the device might be more vulnerable to abuse.

I think your scheme for how a stateless device could effectively be
stateful with respect to response priority (by sending requests, and
therefore receiving responses, associated with different priorities,
through different ports) is clever, and probably less vulnerable to
abuse than explicitly signaling priority in responses.

tim

> Sent: Friday, September 21, 2007 2:19 PM
> To: Dwight, Timothy M (Tim)
> Cc: Brian Rosen; DRAGE, Keith (Keith); [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Sep 2007 12:12:49 -0500

> I have oversimplified, but the point is that it is not a valid assumption.

Ok, so what keeps me as a Joe End User from putting a "higher priority
than the president" marking on every response I send? You can't
challenge a response or send me an error code if you don't like my
priority. Does every response require authentication of priority level?

Do we also have a new requirement for a node to "learn" the priority
level of a dialog from a response, and then include that priority level
in future requests on that dialog?

It seems like this mechanism could be used to "jack up" the priority
level of a dialog:

1) Alice sends a low priority request to Bob.
2) Bob replies with a high-priority marking in the response.
3) Alice marks all future requests and responses in this dialog high
priority.

--
Dean

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 24 Sep 2007 14:20:15 -0400

Those are valid concerns.  I said that I was oversimplifying, and some of 
the oversimplification involves mechanisms to addresses some of those 
concerns.

But we DO need to allow the situation where the first "hop" of a 
"priority" call does not have RPH, but RPH is added for later hops.

Janet

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 24 Sep 2007 14:23:11 -0700

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-masked]] 
Sent: Saturday, September 22, 2007 12:02 AM
To: DRAGE, Keith (Keith); [email-masked]
Subject: RE: [Sip] Progression of draft-polk-sip-rph-in-responses-00

Other comments below.

Best regards,

tim

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Sep 2007 07:29:48 +0100

Janet,
 
If there really is a need for the callee to jack up the priority of a
dialog (I don't have a view on that), then a mechanism similar to
connected-identity should be used, i.e., a mid-dialog request in the
reverse direction, which can therefore be challenged and authenticated
in the normal manner.
 
John

________________________________

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: 24 September 2007 19:20
	To: Dean Willis
	Cc: [email-masked]; DRAGE, Keith (Keith)
	Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00

	
	Those are valid concerns.  I said that I was oversimplifying,
and some of the oversimplification involves mechanisms to addresses some
of those concerns. 

	Janet

	Dean Willis <[email-masked]> wrote on 09/24/2007
01:12:49 PM:
	
	> >> same or a subset of those in the request (i.e. copied)? I
assume the

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Sep 2007 14:53:58 +0200

So the list discussion seem to have diverged into issues that relate to
RFC 4412 rather than the real issue under discussion. I'll work through
the issues raised I currently see them and try and get back on track to
the understanding we need to charter this. In terms of chartering, it is
not just a matter of saying to the Area Director that we need this, we
need to rationally explain a number of things including why it is
needed.

I thought I made clear in my initial mail that in my understanding there
would be no change between the namespace and priority levels of response
and the request. This needs to be more accurately specified in the draft
but certainly that was my understanding from the author, and what was
stated in IETF#69 SIP WG. No one seems to have disagreed with this from
the supporting side.

Therefore change of namespace and/or priority during a dialog would
become a separate issue for discussion in terms of RFC 4412 enhancement,
if it needed extra documentation. I tend to agree with John that using a
response is not the correct way to do this.

In terms of misuse, RFC 4412 section 1 states:

   Since gaining prioritized access to resources offers opportunities to
   deny service to others, it is expected that all such prioritized
   calls are subject to authentication and authorization, using standard
   SIP security (Section 11) or other appropriate mechanisms.

And section 4.2

   2.  It ascertains that the request is authorized according to local
       policy to use the priority levels indicated.  If the request is
       not authorized, it rejects it.  Examples of authorization
       policies are discussed in Security Considerations (Section 11).

My understanding of the model used here is that some sort of trust model
applies. Some edge proxy determines whether the user is allowed to use a
certain level of priority (either from an included RPH or from some
other conditions), and either therefore includes or relays a RPH header.
>From that proxy onwards within the same trust area, that RPH is assumed
to be authenticated for use. If the trust are is exited, the RPH is
removed.

In terms of a valid architecture for use in responses, the one I have
certainly been considering has been the one where we have a stateful
proxy serving both the called and calling user, forming the edge of this
trust area. Other proxies providing routeing functionality between these
two edges could be stateless.

In this architecture, the originating edge proxy authorises the request
as indicated in RFC 4412. This makes its way to the terminating side. At
the terminating side either the terminating user or terminating proxy
puts the RPH in the response with the same value as in the request. If
this is performed by the terminating user, the terminating proxy checks
it (all proper walled garden stuff).

In this case, there does not seem to be any real function performed by
the need to reject a response with a 403, and it seems to be entirely
consistent with RFC 4412 section 4.7.3

   SIP proxies MAY ignore the 'Resource-Priority' header field.  SIP
   proxies MAY reject any unauthenticated request bearing that header
   field.

The stateless proxies that need the RPH header in this architecture
therefore get an authorised one, and only an authorised one. I am
assuming that stateful proxies would in anycase use the RPH from the
request - does this need to be stated?

Now whether there are other valid architectures that work could probably
be discussed in the draft if they are desired, but this seems to be the
main one, and seems to be valid, in terms of getting the information to
a stateless proxy that may need it.

But the real question I asked is that given this scenario, are there
valid things the stateless proxy can do with it. There seems to be no
dispute that for a stateless proxy it only applies to the SIP
processing, and therefore the treatment of the SIP response in
relationship to other requests and responses.

However, the only responses I have been given are of the "if its there
you have to do it" rather than "these are the reasons for doing it".
This does not lead us to a discussion which we need to have of whether
it is of benefit, might give improvements in certain circumstances, or
of no benefit whatsoever. Do we need it as a mandatory extension to RFC
4412, optional and used in some cases, or don't need the extension at
all?

If it does convey benefits, I think we also need to discuss whether the
requests and responses are placed in the same queue for each namespace,
priority level pair, or whether separate queues are needed for each.

To also explain further the linkage I made with overload control, it is
not that they form part and parcel of the same function, but rather that
in an overloaded network, we presumably see the end user seeing benefit
from RPH header usage. Do we expend more network resources on proxies
relaying responses into queues and then processing those queues, such
that the delay to the responses with RPH is greater than if we had just
proxied all responses on a first come first served basis without even
looking at the RPH issues (bearing in mind that transaction stateless
proxy processing of responses is simpler that stateful), i.e. 

   Response processing as described in Section 16.7 does not apply to a
   proxy behaving statelessly.  When a response arrives at a stateless
   proxy, the proxy MUST inspect the sent-by value in the first
   (topmost) Via header field value.  If that address matches the proxy,
   (it equals a value this proxy has inserted into previous requests)
   the proxy MUST remove that header field value from the response and
   forward the result to the location indicated in the next Via header
   field value.  The proxy MUST NOT add to, modify, or remove the
   message body.  Unless specified otherwise, the proxy MUST NOT remove
   any other header field values.  If the address does not match the
   proxy, the message MUST be silently discarded.

Any modelling out there to prove one thing or the other.

Independently of getting these answered, I think there is value in the
author revising the draft to make the usage scenarios clearer.

Regards

Keith

	From: Elwell, John [mailto:[email-masked]] 
	Sent: Tuesday, September 25, 2007 7:30 AM
	To: Janet P Gunn; Dean Willis
	Cc: [email-masked]; DRAGE, Keith (Keith)
	Subject: RE: [Sip] Progression of
draft-polk-sip-rph-in-responses-00

	Janet,
	 
	If there really is a need for the callee to jack up the priority
of a dialog (I don't have a view on that), then a mechanism similar to
connected-identity should be used, i.e., a mid-dialog request in the
reverse direction, which can therefore be challenged and authenticated
in the normal manner.
	 
	John

		
		
		Those are valid concerns.  I said that I was
oversimplifying, and some of the oversimplification involves mechanisms
to addresses some of those concerns. 
		
		But we DO need to allow the situation where the first
"hop" of a "priority" call does not have RPH, but RPH is added for later
hops. 
		
		Janet

		Dean Willis <[email-masked]> wrote on
09/24/2007 01:12:49 PM:
		
		> >> same or a subset of those in the request (i.e.
copied)? I assume the

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Sep 2007 11:33:35 -0400

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

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Monday, September 24, 2007 5:23 PM
> To: Dwight, Timothy M (Tim); DRAGE, Keith (Keith); [email-masked]