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
