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:dean.willis softarmor.com]
> 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
