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
