I think it may be true that a classical SIP stack used to build a plain old stateless proxy server that doesn't do any work on a response other than pass it along could have most, or at least a large part of the work in the parsing of the messages and managing queues.
If however, you were building a proxy that was supposed to implement RPH in the face of the kinds of problems we are talking about, I think your assumption would not hold. For example, you can trivially parse requests from responses, and you can with a little more work find those with an RPH or a facsimile thereof. The amount of work needed for that is small compared to the entire processing time of a response. Once separating requests from responses and non priority from priority is a small part of the processing, then your subsequent arguments don't hold. In any system, the packet arrival rate ultimately limits what you can handle. I think DiffServ marking helps any form of priority system. At some rate of message arrival, the trivial parsing I'm thinking about will fail, although I suspect it will be packet handling that chews up the CPU and not the parsing and sorting. Brian > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 26, 2007 3:58 PM > To: Janet P Gunn > Cc: Brian Rosen; 'IETF SIP List' > Subject: Re: [Sip] What does draft-polk-sip-rph-in-responses-00 get us? > Isthat what we want? > > > On Sep 26, 2007, at 2:19 PM, Janet P Gunn wrote: > > > > > Perhaps. But if you have to receive, enqueue, and parse the messages > > > to find out they have high priority or not, and if that's a > > > substantial part of the workload, and NOT forwarding the low- > > priority > > > responses is going to dramatically increase your workload (due to > > > cascade), then you gain nothing and lose much by using RPH to > > > prioritize responses. This needs to be tied to some lower-layer > > > mechanism (like a diffserv marking) that can allow for discard > > > without so much parsing. > > > > > I would like to hear more on this approach. > > > > Well, I'm no expert on diffserv . . . > > But it seems to me that if we diffserv-marked SIP messages in a > manner that correlates to the RPH value, then a SIP forwarding > element (aka proxy) could discard or defer those messages based on an > examination of the diffserv marking (which is in a relatively fixed > location in the packet) without having to text-parse the whole SIP > message. Since the main threat of the cascade is the increased CPU > load for parsing the retransmitted lower-priority messages, we could > ostensibly gain a large (several orders of magnitude, IMHO) increase > in performance. > > This would seem to only work for SIP over connectionless datagram > transports. If multiple priority levels were to be muxed on a single > TCP connection, then it wouldn't work. > > I believe others have suggested using different ports or different > shared connections for each priority level as a means to work around > this limitation. > > Let's go back to the basic mechanics of cascade failure: > > 1) It takes a reasonably large amount of time to parse a SIP message > and decide what to do with it. > > 2) Discarding messages (as opposed to pushing back on the sender) > cause the requests to be retransmitted. And we can only push back on > requests, not responses. > > 3) If the message arrival rate is such that the processor cannot > parse its way through the queue to reach a high-priority message > before the timers on that high-priority message expire, then the > transaction that created that high-priority message will time out and > re-send the message, moving it to the back of the queue. > Consequently, the high-priority transaction will never complete. > > 4) Once we hit this sort of stage, we're gridlocked and NO > transactions will complete until the message arrival rate drops. If > the pool of participants is constant, then SIP's backoff timers will > eventually reduce the arrival rate. However, large-scale crises tend > to induce a ramping-up of the participant pool, thereby continually > increasing message arrival rates. Failure of communication tends to > induce even more attempts at communication, until the back-off timers > in the human psyche kick in, and they're pretty darned slow. We could > stay gridlocked for hours or days. > > Consequently, I'd argue that it is not effective to discard responses > UNLESS there is also a mechanism to push back against further > requests AND a mechanism for discarding new requests (first and > second level overload controls), and that discarding responses can > only be effective if this discard can be done without the penalty of > parsing the request. Once the response has been parsed, discarding it > is likely do more harm to the system load level than processing it > will, because each discard of a response (absent a pushback on new > requests) simply assures that a new request will be sent. > > -- > Dean _______________________________________________ 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
