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
