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

Fri, 21 Sep 2007 12:35:29 -0700 

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:[EMAIL PROTECTED] 
Sent: Friday, September 21, 2007 11:45 AM

To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)'
Cc: [email protected]
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:[EMAIL PROTECTED]
Sent: Thursday, September 20, 2007 5:36 PM
To: DRAGE, Keith (Keith)
Cc: [email protected]
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://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






















					Reply via email to