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:[EMAIL PROTECTED] > Sent: Friday, September 21, 2007 2:19 PM > To: Dwight, Timothy M (Tim) > Cc: Brian Rosen; DRAGE, Keith (Keith); [email protected] > 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:[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
