Re: What does draft-polk-sip-rph-in-responses-00 get us? Is that what we want?

On Sep 25, 2007, at 2:35 PM, Janet P Gunn wrote:

> Dean Willis <dean.willissoftarmor.com> 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://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

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:dean.willissoftarmor.com]
> 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?
> 
> 
> On Sep 25, 2007, at 2:35 PM, Janet P Gunn wrote:
> 
> > Dean Willis <dean.willissoftarmor.com> 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://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



_______________________________________________
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