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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

DRAGE, Keith (Keith) wrote:
> (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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
>   


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:dragealcatel-lucent.com]
> Sent: Thursday, September 20, 2007 2:57 PM
> To: sipietf.org
> 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

Inline for more

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> Sent: Thursday, September 20, 2007 5:36 PM
> To: DRAGE, Keith (Keith)
> Cc: sipietf.org
> Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
> 
> 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)
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

> 
> 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.
Well, you must process the one high priority
request/provisional
response/final response before you process any low priority
final response.

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

> - a R-P header would add quite some bytes to the
response size, filling
> the network buffers sooner which makes overload
situations worse
I think this is a red herring.  Memory size is usually not
the problem.

> - 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)
This is for a stateless proxy, right?  I don't think that
works.
 
> 
Brian



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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


> -----Original Message-----
> From: Brian Rosen [mailto:brbrianrosen.net] 
> Sent: Friday, September 21, 2007 11:45 AM
> To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)'
> Cc: sipietf.org
> Subject: RE: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
> 
> Hmmm.  You must have different implementation
experience than 
> I do, and you
> must not have talked to any MLPP folks.
> 
> Inline for more
> 
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> > Sent: Thursday, September 20, 2007 5:36 PM
> > To: DRAGE, Keith (Keith)
> > Cc: sipietf.org
> > Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
> > 
> > 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)
> 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
> 
> > 
> > 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.
> Well, you must process the one high priority
request/provisional
> response/final response before you process any low
priority 
> final response.
> 
> > 
> > Some additional points:
> > - responses cannot be challenged, so responders
could claim 
> any priority
> > they feel appropriate
> Policing of R-P-H is a problem, and it's true that
policing 
> the response is
> harder than policing the request.
> 
> > - a R-P header would add quite some bytes to the
response 
> size, filling
> > the network buffers sooner which makes overload
situations worse
> I think this is a red herring.  Memory size is usually
not 
> the problem.
> 
> > - 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)
> This is for a stateless proxy, right?  I don't think
that works.
>  
> > 
> Brian
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:
> 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
>
>
>   
>> -----Original Message-----
>> From: Brian Rosen [mailto:brbrianrosen.net] 
>> Sent: Friday, September 21, 2007 11:45 AM
>> To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)'
>> Cc: sipietf.org
>> Subject: RE: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
>>
>> Hmmm.  You must have different implementation
experience than 
>> I do, and you
>> must not have talked to any MLPP folks.
>>
>> Inline for more
>>
>>     
>>> -----Original Message-----
>>> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
>>> Sent: Thursday, September 20, 2007 5:36 PM
>>> To: DRAGE, Keith (Keith)
>>> Cc: sipietf.org
>>> Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
>>>
>>> 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)
>> 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
>>
>>     
>>> 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.
>>>       
>> Well, you must process the one high priority
request/provisional
>> response/final response before you process any low
priority 
>> final response.
>>
>>     
>>> Some additional points:
>>> - responses cannot be challenged, so responders
could claim 
>>>       
>> any priority
>>     
>>> they feel appropriate
>>>       
>> Policing of R-P-H is a problem, and it's true that
policing 
>> the response is
>> harder than policing the request.
>>
>>     
>>> - a R-P header would add quite some bytes to
the response 
>>>       
>> size, filling
>>     
>>> the network buffers sooner which makes overload
situations worse
>>>       
>> I think this is a red herring.  Memory size is
usually not 
>> the problem.
>>
>>     
>>> - 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)
>>>       
>> This is for a stateless proxy, right?  I don't
think that works.
>>  
>>     
>> Brian
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>
>>     
>
>   


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> 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
Yes, it should be 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
Yeah, looks like it.  Maybe James would comment on this

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

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

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




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:dragealcatel-lucent.com] 
> Sent: Thursday, September 20, 2007 1:57 PM
> To: sipietf.org
> 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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


> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl] 
> Sent: Friday, September 21, 2007 2:19 PM
> To: Dwight, Timothy M (Tim)
> Cc: Brian Rosen; DRAGE, Keith (Keith); sipietf.org
> Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
> 
> 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:
> > 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
> >
> >
> >   
> >> -----Original Message-----
> >> From: Brian Rosen [mailto:brbrianrosen.net] 
> >> Sent: Friday, September 21, 2007 11:45 AM
> >> To: 'Jeroen van Bemmel'; 'DRAGE, Keith
(Keith)'
> >> Cc: sipietf.org
> >> Subject: RE: [Sip] Progression of 
> draft-polk-sip-rph-in-responses-00
> >>
> >> Hmmm.  You must have different implementation
experience than 
> >> I do, and you
> >> must not have talked to any MLPP folks.
> >>
> >> Inline for more
> >>
> >>     
> >>> -----Original Message-----
> >>> From: Jeroen van Bemmel
[mailto:jbemmelzonnet.nl]
> >>> Sent: Thursday, September 20, 2007 5:36
PM
> >>> To: DRAGE, Keith (Keith)
> >>> Cc: sipietf.org
> >>> Subject: Re: [Sip] Progression of 
> draft-polk-sip-rph-in-responses-00
> >>>
> >>> 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)
> >> 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
> >>
> >>     
> >>> 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.
> >>>       
> >> Well, you must process the one high priority
request/provisional
> >> response/final response before you process any
low priority 
> >> final response.
> >>
> >>     
> >>> Some additional points:
> >>> - responses cannot be challenged, so
responders could claim 
> >>>       
> >> any priority
> >>     
> >>> they feel appropriate
> >>>       
> >> Policing of R-P-H is a problem, and it's true
that policing 
> >> the response is
> >> harder than policing the request.
> >>
> >>     
> >>> - a R-P header would add quite some bytes
to the response 
> >>>       
> >> size, filling
> >>     
> >>> the network buffers sooner which makes
overload situations worse
> >>>       
> >> I think this is a red herring.  Memory size is
usually not 
> >> the problem.
> >>
> >>     
> >>> - 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)
> >>>       
> >> This is for a stateless proxy, right?  I don't
think that works.
> >>  
> >>     
> >> Brian
> >>
> >>
> >>
> >>
_______________________________________________
> >> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core
SIP Protocol
> >> Use sip-implementorscs.columbia.edu for
questions on current sip
> >> Use sippingietf.org for new
developments on the application of sip
> >>
> >>     
> >
> >   
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:timothy.dwightverizon.com] 
Sent: Saturday, September 22, 2007 12:02 AM
To: DRAGE, Keith (Keith); sipietf.org
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:dragealcatel-lucent.com] 
> Sent: Thursday, September 20, 2007 1:57 PM
> To: sipietf.org
> 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip