On Sep 25, 2007, at 2:35 PM, Janet P Gunn wrote:
Dean Willis <[EMAIL PROTECTED]> wrote on 09/25/2007
03:05:47 PM:
>
> It seems like there's more motivating draft-polk-sip-rph-in-
> responses-00 than just the need to prioritize access to scarce
> gateway resources. A lot of the people I've talked to are thinking
> that it is also useful for prioritizing message processing in
> congested proxies or other SIP nodes (like B2BUAs, call center
> queues, whatever).
>
> It has even been suggested that the RPH value might be used by a
> congested node for selective discard of responses, which has some
> interesting impacts on the overload queueing model.
>
>
Req 13 in draft-ietf-sipping-overload-reqs already provides for this
REQ 13: The mechanism must not dictate a specific algorithm for
prioritizing the processing of work within a proxy during
times of
overload. It must permit a proxy to prioritize requests
based on
any local policy, so that certain ones (such as a call for
emergency services or a call with a specific value of of the
Resource-Priority header field [3]) are processed ahead of
others.
I'm far more concerned with what it does to the mathematics of the
overload model than what it does to the protocol specification.
SIP, in my experience, is sensitive to what I call "cascade
failures". One element suffers a delay (overload, garbage collection,
whatever) thereby causing a message (request or response) to get
delayed. This delayed message adds enough latency to pop a retransmit
timer, causing a request to get retransmitted (even though the first
message may still be "in-flight"). This additional message adds to
the workload on the already delayed node (possibly incurring also
additional responses), causing further delays and further
retransmissions. At certain thresholds, this can suddenly load the
network with messages, such that a "melt-down" occurs wherein all
requests time out and are retransmitted the maximum number of times
before failing. If the request arrival rate (new users who haven't
yet noted the congestion, or old ones who are just "trying again")
exceeds the clearing rate of the network, the whole thing can
basically stay locked up indefinitely. Remember, you have to parse a
message to see its RPH, and if you're overloaded trying to parse a
message flood you're not going to meet your delivery requirements on
high-priority messages.
Most modeling work I know of has proceeded under the pattern that
requests can be delayed (or "pushed back" on like a retry-after), but
that responses move with all available speed and are never
deliberately discarded. This is consistent with SIP's authentication
model that allows challenging a request but not a response.
When we start discarding the responses, the queueing model gets a lot
more complicated. Not only do we have the same retransmission
cascade, but we add a possible confounding of the states at the end
points. While SIP UAs should of course handle repeated requests, it's
certainly more complex for them to see a request again to which they
have already responded than it is for them to see a request they've
never seen before. More state stacks up, more strange things can
happen, and I don't know what it will do to the resultant system.
Notice that this thinking is evident even in the section from
overload-reqs you quote, which talks only about prioritization of
requests, not prioritization of responses.
Consequently, adding text that seems to facilitate and encourage
discarding or deferral (or, I suppose, prioritization in general) of
responses makes me queasy. It might turn out ok, but it certainly
sets my spider-senses to tingling, and makes me want to understand
the risks better before I suggest it to anybody.
For you students out there looking for a modeling project,
quantifying the impact of this would make a great thesis effort.
--
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
