Subject: [Sip] What does draft-polk-sip-rph-in-responses-00 get us? Is that what we want?

From: Dean Willis <[email-masked]>
Date: Tue, 25 Sep 2007 14:05:47 -0500

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.

An unstated goal here is that even if proxy-like resources are  
operating at a totally saturated level they MUST still be able to  
process messages with a high RPH value, even if it means totally  
disrupting lower-priority traffic and creating cascade collapse and  
link saturation with message retransmissions. It seems to me that  
this would require very careful collaboration with a diffserv layer  
to make work, but that's just one of the open questions.

The other open questions I think I see are  a) how to allow a  
priority determination to be made by a node on the "response" side of  
the loop, and b) how to deal with authentication and authorization  
for priority levels requested in a response. This raises a couple of  
state-management questions, and two big thorny architectural questions.

The state bits are easy, I think -- Having learned of a priority  
established "somewhere along the line", each statefully participating  
SIP node must continue to add an equivalent priority header in future  
messages. Unless of course the node has reason to be changing the  
priority level, which of course raises all sorts of questions about  
who is allowed to change a value, how we can tell it has been  
changed, whether or not we decide to honor the change, and so on.

The more fundamental architectural questions are 1) How do we change  
anything in a response that can't be challenged, and 2) how do we  
authenticate changes introduced by non-terminal nodes?

The first problem we've traditionally addressed by a reverse- 
direction request, as noted by John Elwell. That might work here.

The second problem is a much bigger mess, one that we've categorized  
as "middle-to-middle" and/or "middle-to-end". This is a big open  
problem in the SIP space, one that we don't even have a charter item  
to address. We bogged down on the simpler end-to-middle problem,  
which we managed to document as a more-or-less experimental document  
pending better understanding of the problem.

Consequently, I think we're asking RPH to do a lot of things for us  
that it really can't do in the general case.

The only solution that comes to mind is to simplify the problem  
scope. Perhaps if we started from a really concise statement of what  
we can reasonably do with a mechanism like RPH, we'd make more  
headway in understanding the problem.

A short list to work from:

1) RPH can only be set by a request-originating UA. Consequently, any  
intermediary node that is changing RPH MUST be a B2BUA.

2) Like other dialog attributes, changes of RPH require modification  
of the dialog via UPDATE or reINVITE.

These two constraints are driven by the request-authentication model  
and the like of m2m authentication in SIP.

Given these constraints, can we meed the needs of the community? Now  
the "how they want things to work" needs, but the real required  
functionality for prioritization?

Do we need to add RPH negotiation to the session-policy mechanism?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 25 Sep 2007 15:35:49 -0400

> 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.

Janet

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Sep 2007 17:08:05 -0500

>       Resource-Priority header field [3]) are processed ahead of  

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Sep 2007 11:25:25 -0400

Yeah, but I think you are starting with an incorrect assumption that if you
improve the average response, you will get a better global result.  The
assumption usually made in these systems is that the network is horribly
overloaded; nearly all low priority messages are timing out and the system
is choked.  You are way past the point where anything like what you are
talking about can help.

In that scenario, you pick out the high priority messages, get them through,
and the rest of the users are hosed.  They were hosed to begin with.

I suspect that you could model well enough and discover that the difference
between the work of parsing messages to find high priority responses and
fully handling all responses in a stateless proxy is pretty much don't care.
I think though that the priority people would be very suspicious of the
model.  I don't think you could show that handling priority responses behind
non priority requests would have that characteristic.  Then you get to
talking about designing proxies so that they handle all responses before any
requests.

But I think it would take some seriously difficult modeling to show that it
worked well, and you could always find corner cases where it didn't.  That
may mean GETS-like services could reasonably work that way.  MLPP systems
would not; priority is absolute.

Brian
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2007 6:08 PM
> To: Janet P Gunn
> Cc: IETF SIP List
> Subject: Re: [Sip] What does draft-polk-sip-rph-in-responses-00 get us?
> Isthat what we want?
> 
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 26 Sep 2007 13:57:35 -0500

> is choked.  You are way past the point where anything like what you  

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.

Or it needs to be tied to a pushback "congestion notification" kind  
of approach, and we have SIP set up with no way to push back against  
responses, just against requests. So if a proxy is having to discard  
a response because of congestion, the proxy needs to inform the  
sender of the request that generated the response to back off.

Perhaps a proxy could MODIFY a response, turning it into a terminal  
"retry after" or something like that. Of course, then it wouldn't be  
a proxy -- it would be a B2BUA.

Maybe a header that says "I don't care if this looks like a 200 OK,  
but some proxy in the path has decided an overload applies, so  
abandon this request and don't retry" would work, but then we're in  
the middle-to-end authentication realm, and that's a mess all on its  
own.

Nope, I think SIP is just set up where trying to prioritize responses  
doesn't work.

--
Dean

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 26 Sep 2007 15:19:58 -0400

--

> mechanism (like a diffserv marking) that can allow for discard 
I would like to hear more on this approach.

---

From: Dean Willis <[email-masked]>
Date: Wed, 26 Sep 2007 14:57:33 -0500

> 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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Sep 2007 16:58:33 -0400

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

> Sent: Wednesday, September 26, 2007 3:58 PM
> To: Janet P Gunn
> Cc: Brian Rosen; 'IETF SIP List'

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 27 Sep 2007 16:37:11 +0000

I have the same concern with suggestions that we "infer" the priority of
responses from the cached state of the associated request - the issue
being that you have to parse the response, then fetch the state info, to
decide its disposition.  The extent to which that is a concern is of
course implementation specific.
 
In response Jeroen suggested an idea similar to Dean's.  He suggested
sending requests (hence, receiving the associated responses) on
different ports, based on priority.  You could then, under congestion,
make congestion -related decisions (which could include but are not
necessarily limited to, drop vs. enqueue decisions) based on the port on
which responses are received.
 
Works for me, as might a diffserv tie-in.  I don't know that any
mechanism needs to be mandated, but I think it would be useful to
document the expectation that responses are handled with priority
equivalent to that with which the associated request was handled.  I
think wording like that could support also the case that the element
(e.g., proxy) handles all requests with the same priority.
 
tim

________________________________

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: Wednesday, September 26, 2007 2:20 PM
	To: Dean Willis
	Cc: 'IETF SIP List'
	Subject: Re: [Sip] What does draft-polk-sip-rph-in-responses-00
get us? Isthatwhat we want?

	--

	Dean Willis <[email-masked]> wrote on 09/26/2007