Subject: [Sipping] comments regarding draft-hilt-sipping-overload-00.txt

From: Venkatesh <[email-masked]>
Date: Thu, 14 Dec 2006 00:24:13 -0800

Hi:

Apologize if this has already been discussed in the mailing list. While
reading this draft, it seemed to me that a bunch of requirements outlined in
the sipping-overload-requirements draft could be addressed by proxies/UA's
inspecting the Timestamp header in the 100 trying response rather than
solely relying on new header proposed.

Proxies could inspect the Timestamp header in the 100 response to decide how
long it took for the upstream entity to receive and process the request.
Proxies could infer delayed 100 responses to indicate overload of the next
hop and back off offering new requests and such based on some logic built
around the same. I was thinking, may be, to help the overloaded proxy
recover, not only could the previous hop stop offering new requests, but
also, tune retransmit intervals of existing/new requests based on the delay
rather than following RFC 3261 back off algorithms...... For example say a
proxy A is observing upto 2 second delays in receiving 100 Trying responses
from B, it could not only start reducing the number of new requests it
offers to B, but also start it's T1 timer for new requests (or retransmitted
requests) to begin at 2 sec and back off instead of the standard 500 ms?

The above would work with existing RFC 3261 compliant implementations (as
they are required to copy the Timestamp header as is when sending 100 Trying
responses) ?

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

---

From: [email-masked]
Date: Thu, 14 Dec 2006 14:31:52 +0100

Venkatesh,

essentially you are proposing to use "response time" as load indicator
("which relates to the sensor in the control loop for load regulation").
This is definitively a possibility. The main advantage of such a load
indicator type is the fact, that it doesn't consume any resources of the
overloaded entitiy itself (it relates to an external observation of the
overloaded system as a "black box"). This is in particular a crucial
criteria when systems are operated above the nominal load.

The main drawback of such a load indicator is the function: response time
as a function of load.
=> this is a non-linear function
=> and the slope of this function is typically very much increasing above
nominal load

This makes it difficult to design a stable control, together with the goal
of throughput maximization.

That's the reason why real systems use typically a second (or even third)
load indicator type (in addition to response times).
[Background: it's difficult to cover multiple time-scales, and/or multiple
load ranges by a single control. That's why often in practise two or three
control loops are used, which of course must "co-operate"...]

Albrecht

                      Venkatesh                                                                                                         
                      <vvenkatar@gmail         To:      sipping <[email-masked]>                                                      
                      .com>                    cc:      [email-masked], [email-masked], [email-masked],        
                                               [email-masked]                                                                      
                      14.12.2006 09:24         Subject: [Sipping] comments regarding draft-hilt-sipping-overload-00.txt                 

Hi:

Apologize if this has already been discussed in the mailing list. While
reading this draft, it seemed to me that a bunch of requirements outlined
in the sipping-overload-requirements draft could be addressed by
proxies/UA's inspecting the Timestamp header in the 100 trying response
rather than solely relying on new header proposed.

Proxies could inspect the Timestamp header in the 100 response to decide
how long it took for the upstream entity to receive and process the
request. Proxies could infer delayed 100 responses to indicate overload of
the next hop and back off offering new requests and such based on some
logic built around the same. I was thinking, may be, to help the overloaded
proxy recover, not only could the previous hop stop offering new requests,
but also, tune retransmit intervals of existing/new requests based on the
delay rather than following RFC 3261 back off algorithms...... For example
say a proxy A is observing upto 2 second delays in receiving 100 Trying
responses from B, it could not only start reducing the number of new
requests it offers to B, but also start it's T1 timer for new requests (or
retransmitted requests) to begin at 2 sec and back off instead of the
standard 500 ms?

The above would work with existing RFC 3261 compliant implementations (as
they are required to copy the Timestamp header as is when sending 100
Trying responses) ?

Venkatesh_______________________________________________

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 14 Dec 2006 17:22:14 -0600

Hello,

Intuitively, having a throttle point external to the protected element
rely on 100Trying timing to determine whether or not the message
originator is in overload and by how much should traffic be reduced does
not seem to be a good solution.
 
At such an operating level, an increase in 100Trying delay would likely
be hidden by variations in transmission delays. Only once the protected
element operates in overload, 100Trying delay would increase
significantly, but by then it would be too late (keep in mind the
standard M/M/1 delay/load curve).

Conversely, message timing internal to the protected element to identify
its internal overload state and estimate controlled load for external
overload control actually works well. Naturally, that method would not
protect against sudden traffic surges, which are best dealt with by
monitoring input queue length.

Cheers,

Martin 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, December 14, 2006 8:32 AM
To: Venkatesh
Cc: [email-masked]; [email-masked];
[email-masked]; sipping; [email-masked]
Subject: Re: [Sipping] comments regarding
draft-hilt-sipping-overload-00.txt

Venkatesh,

The main drawback of such a load indicator is the function: response
time
as a function of load.
=> this is a non-linear function
=> and the slope of this function is typically very much increasing
above
nominal load

This makes it difficult to design a stable control, together with the
goal
of throughput maximization.

That's the reason why real systems use typically a second (or even
third)
load indicator type (in addition to response times).
[Background: it's difficult to cover multiple time-scales, and/or
multiple
load ranges by a single control. That's why often in practise two or
three
control loops are used, which of course must "co-operate"...]

Albrecht

---

From: "Liu, Guang Xuan \(Mike\)" <[email-masked]>
Date: Fri, 15 Dec 2006 11:23:59 +0800

100 Trying "response time" is a possible candidate for external overload
detection. 

It is indeed based on client transaction response time. But since it is
possible for non-INVITE transactions not to have 100 Trying, it can only
cover INVITE transactions.

Another possible time based overload detection could be server
transaction based. The system can measure the interval between
transaction creation time and the first TU response time for server
transactions. The first TU response could be a provisional response or a
final response. This detection method is applicable for application
servers, registrars etc.

Both methods need to use the average response time by sampling several
thousands of transactions to avoid transaction response jittering. And
it is interesting how to have a normal transaction response time as a
reference point since the traffic model could change in different
scenarios.

Guangxuan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, December 14, 2006 9:32 PM
To: Venkatesh
Cc: [email-masked]; Widjaja, Indra (Indra);
[email-masked]; sipping; [email-masked]
Subject: Re: [Sipping] comments regarding
draft-hilt-sipping-overload-00.txt

Venkatesh,

The main drawback of such a load indicator is the function: response
time as a function of load.
=> this is a non-linear function
=> and the slope of this function is typically very much increasing
above nominal load

This makes it difficult to design a stable control, together with the
goal of throughput maximization.

That's the reason why real systems use typically a second (or even
third) load indicator type (in addition to response times).
[Background: it's difficult to cover multiple time-scales, and/or
multiple load ranges by a single control. That's why often in practise
two or three control loops are used, which of course must
"co-operate"...]

Albrecht

                      Venkatesh

                      <vvenkatar@gmail         To:      sipping
<[email-masked]>                                                      
                      .com>                    cc:
[email-masked], [email-masked], [email-masked],

                                               [email-masked]

                      14.12.2006 09:24         Subject: [Sipping]
comments regarding draft-hilt-sipping-overload-00.txt                 

Hi:

Apologize if this has already been discussed in the mailing list. While
reading this draft, it seemed to me that a bunch of requirements
outlined in the sipping-overload-requirements draft could be addressed
by proxies/UA's inspecting the Timestamp header in the 100 trying
response rather than solely relying on new header proposed.

Proxies could inspect the Timestamp header in the 100 response to decide
how long it took for the upstream entity to receive and process the
request. Proxies could infer delayed 100 responses to indicate overload
of the next hop and back off offering new requests and such based on
some logic built around the same. I was thinking, may be, to help the
overloaded proxy recover, not only could the previous hop stop offering
new requests, but also, tune retransmit intervals of existing/new
requests based on the delay rather than following RFC 3261 back off
algorithms...... For example say a proxy A is observing upto 2 second
delays in receiving 100 Trying responses from B, it could not only start
reducing the number of new requests it offers to B, but also start it's
T1 timer for new requests (or retransmitted requests) to begin at 2 sec
and back off instead of the standard 500 ms?

The above would work with existing RFC 3261 compliant implementations
(as they are required to copy the Timestamp header as is when sending
100 Trying responses) ?

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

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 15 Dec 2006 22:01:00 -0500

I think basing next-hop load on SIP response timing is a really bad idea.
There are just too many types of device behaviors and messages-specific
impact out there to make an implicit mechanism such as that workable.

Reasons:
1) 100 trying is sometimes sent by devices very early in their processing,
simply to shut up the upstream device. (stop it from retransmitting) In
distributed processing platforms it would be a completely misleading
indicator.
2) Non-invites typically have the responses sent from far-downstream nodes,
way past the next-hop.
3) Some methods have highly variable response times based on the processing.
For example a Register needing a database lookup vs. a cache hit on the
Registrar; or an Options message needing a capabilities lookup on some
devices, while in other cases it's simply used for a heartbeat.  Etc.

This mechanism needs to be explicit, IMHO.

-hadriel

> From: Liu, Guang Xuan (Mike) [mailto:[email-masked]]
> Sent: Thursday, December 14, 2006 10:24 PM
> To: [email-masked]; Venkatesh
> Cc: Xia, Zeng Wu (Jackey); [email-masked]; [email-masked];
> [email-masked]; sipping
> Subject: RE: [Sipping] comments regarding draft-hilt-sipping-overload-
> 00.txt
>

---

From: [email-masked]
Date: Sat, 16 Dec 2006 11:53:35 +0100

Thanks Martin, Mike, Hadriel for your feedback! No disagreement from my
side.
I did only comment on a small piece of the overall problem, the possible
applicability of observation variables for resources under overload.

The load indicators "response time" or "queue length" are indirect
variables in case that the considered resource is a processor element (or a
cluster of CPUs). In such a case, the best load indicator is still a direct
variable, which is here the "utilization" of the processor.

To:
>... significantly, but by then it would be too late (keep in mind the

Actually such a delay/load curve is perfect for feedback controls because
the delay as a function of load (and therefore also the response time as a
function of load) is a "strictly monotonic increasing" function without any
extrema within the control range.

But right, underlying assumption is a filter (like exponential smoothing),
which implies a series of measurements. This is definitely not the case
when a decision must be built on a single (SIP response) message. This
would be a single probe, including the uncertainity due to the underlying
distribution function.

Stefaan:
there are means to attenuate potential oscillations in such feedback
controls.

Hadriel:
agree to an explicit variable.

- Albrecht

PS
Like to point out an overload control, based on a feedback loop control,
which is principally also applicable here (due to their generic design):

Draft ETSI 283 039-2: Congestion & Overload Control; Part 2: Core GOCAP and
NOCA Entity Behaviours

                      "Hadriel Kaplan"                                                                                                  
                      <HKaplan@acmepac         To:      "'Liu, Guang Xuan \(Mike\)'" <[email-masked]>,                        
                      ket.com>                 <[email-masked]>, "'Venkatesh'" <[email-masked]>                
                                               cc:      "'Xia, Zeng Wu \(Jackey\)'" <[email-masked]>,                          
                      16.12.2006 04:01         <[email-masked]>, <[email-masked]>, <[email-masked]>,           
                                               "'sipping'" <[email-masked]>                                                           
                                               Subject: RE: [Sipping] comments regarding draft-hilt-sipping-overload-00.txt             

Reasons:
3) Some methods have highly variable response times based on the
processing.

-hadriel

---

From: Venkatesh <[email-masked]>
Date: Sat, 16 Dec 2006 10:50:31 -0800

Infact the reason #1 you mention below is one reason that supports why
measuring such delays and using this to decide retransmit timers might be
helpful. When such a device (that simply sends a 100 response to shut up
upstream devices) is unable to respond back to you in time, it indicates a
severe condition (either at the device or some other network element)....
continuing to use standard retransmits to the device isn't going to help it
recover or elicit any reasonable response to these requests....

The draft talks about recovering from overload by throttling new requests. I
am not sure if this will help overloaded systems recover 'faster'...... for
example your control function most probably will not take drastic steps to
advertise 100% load for momentary CPU spike or an increase in queue length.
However, should this situation persist for may be a reasonable number of
samples you might end up advertising overload.... in the meanwhile some of
the scenarios mentioned in the overload requirements draft (like avalanche
restart or sudden spike in traffic) can cause considerable damage to this
entity and take a longer time to recover from the same.... Assume a simple
example where a device can handle 50 requests/per second. Consider a
scenario where such a device receives 100 msg at t=0 and another 100 msgs at
t=1sec. Simple calculations show that tuning the retransmit timers for the
second batch of 100 msgs can help recover the overloaded system 25% sooner
against continuing to use the standard T1 timers for retransmits.

I am not advocating for using the delays to be the only measure for
determining load. I am suggesting that we use this as one of the inputs. You
still could have the Load header received in response to throttle new
requests.

Definitely with you w.r.t the scheme not working for non INVITE
transactions.

Thanks,
Venkatesh

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 16 Dec 2006 16:20:00 -0500

Howdy,

Comments inline.

  _____  

From: Venkatesh [mailto:[email-masked]] 
Sent: Saturday, December 16, 2006 1:51 PM
To: Hadriel Kaplan
Cc: Liu, Guang Xuan (Mike); [email-masked]; Xia, Zeng Wu
(Jackey); [email-masked]; [email-masked];
[email-masked]; sipping
Subject: Re: [Sipping] comments regarding draft-hilt-sipping-overload-00.txt

I was thinking the same thing before I sent my email, but I convinced myself
otherwise.  First there's the problem of merely lost packets, if udp is
used.  Or even just network delay variance.  So you'd have to have some
dampening or windowing anyway, which limits how fast you could react to such
things.  If the congested device is a multi-processor system, and responds
with 100 at a stage before a cpu which handles the heavy lifting, you
probably don't want it to artificially delay 100 responses when its internal
queue gets full just so the upstream slows down - instead it'll be setting
some throttle indication explicitly, in those 100 tryings or in other
responses.  If anything you want it to send those responses as fast as
possible.

Your point is that would still happen, but when 100 responses gets slower
then you can assume it's gotten to an even worse stage of overload.  If that
happened, then my argument is the earlier throttle indication wasn't doing
its job, because the dampening/windowing that would have to exist to ignore
transient losses/delay in the transport layer, would mean the reaction time
is long enough that the explicit indications should have kicked in.

entity and take a longer time to recover from the same.... 

Again, you can't take measures faster simply because of an instantaneous or
even momentary delay in 100 responses.  Your requests or the 100 responses
may have simply gotten lost, or the transport network may have reconverged.
The retransmits exist because of that, so you'll be competing with them.
Making assumptions about next-hop load based on something that can be
impacted at multiple layers, some of which are not correlated to load, is
something I think dangerous.

The avalanche restart problem specifically will not be helped by such
calculation, since its Registers and typically don't have 100 trying
responses. (though I have seen some devices send them for Registers in their
attempt to squelch retransmits)

Assume a simple example where a device can handle 50 requests/per second.
Consider a scenario where such a device receives 100 msg at t=0 and another
100 msgs at t=1sec. Simple calculations show that tuning the retransmit
timers for the second batch of 100 msgs can help recover the overloaded
system 25% sooner against continuing to use the standard T1 timers for
retransmits. 

Those assumptions are based on the idea that the next-hop actually got the
requests, or did not send the 100 responses. (i.e., they assume the next-hop
is in fact overloaded) 

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 16 Dec 2006 16:46:42 -0500

I'm actually not that convinced that the "utilization" variable has any
direct applicability to congestion control.  It may be useful for
load-balancing uses, i.e. for the previous-hop to pick otherwise-equal
next-hops using a variable which was not available to it previously; and it
may be useful for such in order to avoid reaching a congestion state on the
next-hop to begin with, but it's somewhat orthogonal to the mechanism of
congestion control.  And it's another can of worms.

Just because a cpu is at 80% may mean nothing in terms of congestion state
with respect to SIP transaction handling.  The device may have an
architecture which does lower-priority things that consume cpu, but still be
able to handle plenty more high-priority SIP transactions.  The device may
be dedicated to servicing the previous-hop at a higher priority, but other
previous-hops if it has headroom.  The device may be capable of
orders-of-magnitude more transactions than the previous-hop, and though its
cpu is busy from other previous-hops, it may easily handle anything the
specific previous-hop wants to dish out.

Since only the throttle indication has any input to the congestion reaction
in this draft, if I read it correctly, then I think it's bundling two
disparate concepts in one draft.  My 2 cents, anyway.

-hadriel

> From: [email-masked] [mailto:Albrecht.Schwarz@alcatel-
> lucent.de]
> Sent: Saturday, December 16, 2006 5:54 AM
> To: Hadriel Kaplan
> Cc: [email-masked]; 'Liu, Guang Xuan (Mike)';
> [email-masked]; 'sipping'; [email-masked]; 'Venkatesh';
> 'Xia, Zeng Wu (Jackey)'
>                       ket.com>                 <Albrecht.Schwarz@alcatel-
> lucent.de>, "'Venkatesh'" <[email-masked]>
>                                                cc:      "'Xia, Zeng Wu
>                       16.12.2006 04:01         <[email-masked]>,
> <[email-masked]>, <[email-masked]>,
>                                                "'sipping'"
> <[email-masked]>
>                                                Subject: RE: [Sipping]

---

From: Venkatesh <[email-masked]>
Date: Sat, 16 Dec 2006 14:59:23 -0800

Hi:

Replies inline....

On 12/16/06, Hadriel Kaplan <[email-masked]> wrote:
>
>  Howdy,
>
> Comments inline…
>
>
>   ------------------------------
>
> *From:* Venkatesh [mailto:[email-masked]]
> *Sent:* Saturday, December 16, 2006 1:51 PM
> *To:* Hadriel Kaplan
> *Cc:* Liu, Guang Xuan (Mike); [email-masked]; Xia,
> Zeng Wu (Jackey); [email-masked]; [email-masked];
> *Subject:* Re: [Sipping] comments regarding
> I was thinking the same thing before I sent my email, but I convinced
> myself otherwise.  First there's the problem of merely lost packets, if udp
> is used.  Or even just network delay variance.  So you'd have to have some
> queue gets full just so the upstream slows down – instead it'll be setting
[Venkatesh]: I am not sure I fully agree with you on this. Contrary to the
statement, if there was an ability to slow down the sender by delaying a
response and this will help mitigate your internal queues, you might just
want to do the same. From what I understand, other congestion
avoidance/control mechanisms like RED  or Weighted RED do exactly that to
slow down senders (drop packets). I definitely see your point of delays
being attributed to other network elements but this proposal would not only
help ease traffic on the next hop (if that was the one having overload
problems), but would also help restore other network elements having
congestion issues.

> is long enough that the explicit indications should have kicked in.

[Venkatesh]: Like I said (and agreed by you), one cannot take drastic
measures to a momentary increase in traffic. Part of the problem is that you
cannot predict if a sudden surge in traffic is a one-off event or is the
beginning of a real surge... It would take a sequence of measurements before
u can advertise un-availablity/reduce levels of service. Which means it will
make your 'throttle indicator' vulnerable to sudden changes in traffic
(which is what some of the examples mentioned in the overload requirements
document do)  Under such circumstances retransmissions end up making the
system under overload useless for a longer period of time.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Sun, 17 Dec 2006 20:40:01 -0500

Venkatesh wrote:
>>     Infact the reason #1 you mention below is one reason that supports
>>     why measuring such delays and using this to decide retransmit timers
>>     might be helpful. When such a device (that simply sends a 100
>>     response to shut up upstream devices) is unable to respond back to
>>     you in time, it indicates a severe condition (either at the device
>>     or some other network element).... continuing to use standard
>>     retransmits to the device isn't going to help it recover or elicit
>>     any reasonable response to these requests....
> 
>     I was thinking the same thing before I sent my email, but I
>     convinced myself otherwise.  First there's the problem of merely
>     lost packets, if udp is used.  Or even just network delay variance. 
>     So you'd have to have some dampening or windowing anyway, which
>     limits how fast you could react to such things.  If the congested
>     device is a multi-processor system, and responds with 100 at a stage
>     before a cpu which handles the heavy lifting, you probably don't
>     want it to artificially delay 100 responses when its internal queue
>     gets full just so the upstream slows down – instead it'll be setting
>     some throttle indication explicitly, in those 100 tryings or in
>     other responses.  If anything you want it to send those responses as
>     fast as possible. 
> 
> [Venkatesh]: I am not sure I fully agree with you on this. Contrary to 
> the statement, if there was an ability to slow down the sender by 
> delaying a response and this will help mitigate your internal queues, 
> you might just want to do the same. From what I understand, other 
> congestion avoidance/control mechanisms like RED  or Weighted RED do 
> exactly that to slow down senders (drop packets). I definitely see your 
> point of delays being attributed to other network elements but this 
> proposal would not only help ease traffic on the next hop (if that was 
> the one having overload problems), but would also help restore other 
> network elements having congestion issues.
> 
Measuring the 100 response time is an implicit mechanism to indicate 
overload. One of the advantages of having such a mechanism is that it 
does not require support from the downstream server. Each server could 
implement this mechanism locally and react to increases in the response 
time. The problem with 100 response time is that it only works well if 
the receiver uses active queue management techniques such as RED or REM 
to indicate early that the queue is filling up. By doing so, the 
receiver is required to delay the transmission of 100 trying to indicate 
overload, which may cause retransmissions that are highly undesired at 
this point. So instead of implicitly signaling overload by delaying a 
100 trying (which is bad), a receiver could as well put an explicit 
overload signal into its responses.

Volker

---

From: Volker Hilt <[email-masked]>
Date: Sun, 17 Dec 2006 22:38:36 -0500

> congestion control.  And it's another can of worms.
I agree that overload control does not depend on load feedback. However, 
as you've said, load feedback can help to balance load, find a less 
utilized target if a downstream proxy is overloaded and avoid highly 
loaded proxies, if possible, before overload control kicks in.

> specific previous-hop wants to dish out.
If a proxy has two downstream neighbors, it might be a reasonable 
strategy to distribute traffic so that they are at same level of load 
(e.g. 80%) even though their actual capacity may be vastly different. If 
distributing traffic to a downstream neighbor does not increase its load 
(because the traffic is squeezing out other traffic because of its 
higher priority) that seems to be fine as well. Overall, I think it is 
important to define the exact meaning of a load status so that it can be 
populated in a meaningful way for a device.

> disparate concepts in one draft.  

I think that load feedback can help to avoid overload by making sure 
traffic is distributed to available resources and therefore it seems to 
complement a pure overload control (i.e. throttling) mechanism.

Volker

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 18 Dec 2006 12:25:58 +0100

RFC 4320 provides a mandatory update to RFC 3261 with the following
words:

   An SIP element MUST NOT send any provisional response with a Status-
   Code other than 100 to a non-INVITE request.

   An SIP element MUST NOT respond to a non-INVITE request with a
   Status-Code of 100 over any unreliable transport, such as UDP, before
   the amount of time it takes a client transaction's Timer E to be
   reset to T2.

   An SIP element MAY respond to a non-INVITE request with a Status-Code
   of 100 over a reliable transport at any time.

   Without regard to transport, an SIP element MUST respond to a non-
   INVITE request with a Status-Code of 100 if it has not otherwise
   responded after the amount of time it takes a client transaction's
   Timer E to be reset to T2.

This essentially makes 100 (Trying) responses the same status as for
INVITE requests.

Regards

Keith 

> Sent: 15 December 2006 03:24
> To: Schwarz, Albrecht (Albrecht); Venkatesh
> Cc: Xia, Zeng Wu (Jackey); [email-masked]; 
> [email-masked]; [email-masked]; sipping
> 100 Trying "response time" is a possible candidate for 
> external overload detection. 
> 
> It is indeed based on client transaction response time. But 
> since it is possible for non-INVITE transactions not to have 
> 100 Trying, it can only cover INVITE transactions.
> 
> Another possible time based overload detection could be 
> server transaction based. The system can measure the interval 
> between transaction creation time and the first TU response 
> time for server transactions. The first TU response could be 
> a provisional response or a final response. This detection 
> method is applicable for application servers, registrars etc.
> 
> Both methods need to use the average response time by 
> sampling several thousands of transactions to avoid 
> transaction response jittering. And it is interesting how to 
> have a normal transaction response time as a reference point 
> since the traffic model could change in different scenarios.
> 
> Guangxuan
> 
> essentially you are proposing to use "response time" as load 
> indicator ("which relates to the sensor in the control loop 
> for load regulation").
> This is definitively a possibility. The main advantage of 
> such a load indicator type is the fact, that it doesn't 
> consume any resources of the overloaded entitiy itself (it 
> relates to an external observation of the overloaded system 
> as a "black box"). This is in particular a crucial criteria 
> when systems are operated above the nominal load.
> 
> The main drawback of such a load indicator is the function: 
> response time as a function of load.
> => and the slope of this function is typically very much 
> increasing above nominal load
> 
> This makes it difficult to design a stable control, together 
> with the goal of throughput maximization.
> 
> [Background: it's difficult to cover multiple time-scales, 
> and/or multiple load ranges by a single control. That's why 
> often in practise two or three control loops are used, which 
> of course must "co-operate"...]
> 
> Albrecht
> 
> 
> 
> 
>  
> 
>                       Venkatesh
> 
> Apologize if this has already been discussed in the mailing 
> list. While reading this draft, it seemed to me that a bunch 
> of requirements outlined in the sipping-overload-requirements 
> draft could be addressed by proxies/UA's inspecting the 
> Timestamp header in the 100 trying response rather than 
> Proxies could inspect the Timestamp header in the 100 
> response to decide how long it took for the upstream entity 
> to receive and process the request. Proxies could infer 
> delayed 100 responses to indicate overload of the next hop 
> and back off offering new requests and such based on some 
> logic built around the same. I was thinking, may be, to help 
> the overloaded proxy recover, not only could the previous hop 
> stop offering new requests, but also, tune retransmit 
> intervals of existing/new requests based on the delay rather 
> than following RFC 3261 back off algorithms...... For example 
> say a proxy A is observing upto 2 second delays in receiving 
> 100 Trying responses from B, it could not only start reducing 
> the number of new requests it offers to B, but also start it's
> T1 timer for new requests (or retransmitted requests) to 
> begin at 2 sec and back off instead of the standard 500 ms?
> 
> The above would work with existing RFC 3261 compliant 
> implementations (as they are required to copy the Timestamp 
> header as is when sending 100 Trying responses) ?
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Darshan Bildikar" <[email-masked]>
Date: Fri, 22 Dec 2006 13:02:02 +0530

1) How does this document relate to
"draft-rosenberg-sipping-overload-reqs-01"? Does it take into cognisance the
requirements defined in this document? 

2) It is envisioned that overload information is exchanged through a header
in response messages. Why not a more EXPLICIT mechanism like
SUBSCRIBE/NOTIFY? Define an event package for overload and define a body
that can be used to indicate a rich set of overload parameters to the
upstream entity. 

3) The draft talks about overload w.r.t certain resources. If a sub/not
mechanism was used, it would allow overload control to be more "fine
grained". For example, the SUBSCRIBE message would indicate what resource
the requester is wants the overload throttling and statistics for. 

A use case that I can think of 

I have two applications on my box; CRBT and video conferencing. I might be
fast running out of ports for video conferencing but might still be able to
do CRBT at 100%. I should be able to control the load based on the REQUEST
URI. 

I'm thinking that the SUBSCRIBE shall indicate, "Give me overload statistics
as if I were sending you this REQUEST URI". I'm assuming that a request URI
maps to a "resource" but there could be a better way this could be done. 

This mechanism would help throttling based on SIP method, URI, host, port
etc and will be able to support REQ 18 defined in
draft-rosenberg-sipping-overload-reqs-01". 

Two things that I haven't really thought through.

1) Throttling based on codecs and media lines would be useful. For example,
I can support audio right now, but NOT video. 
2) Is it possible to make this mechanism more generic? It is after all a
throttling mechanism and could be applied to domains OTHER than overload
control. For example, Tele voting applications where an application server
indicates filtering to a switch i.e. "Notify every 100'th INVITE to me"

BR,
Darshan