Subject: [sip-overload] Comment/question on draft-ietf-soc-overload-design-00

From: Michael Hirschbichler <[email-masked]>
Date: Tue, 27 Jul 2010 12:49:42 +0200

Hi all,

The following definition is not very clear for me:

[draft-ietf-soc-overload-design-00]
   Section 9.3. "Window-based Overload Control"

   ...
   The sender adjusts its window size as soon as it receives the
   corresponding feedback from the receiver.  If the new window size is
   smaller than the current unconfirmed message counter, the sender
   stops transmitting messages until more messages are confirmed and the
   current unconfirmed message counter is less than the window size.
   ...

Well, in my opinion, the window size can only be reduced, but never
increased, except when sending an explicit message containing a new
explicit window size. Is this correct?
When the downstream server is in a low-loaded state, the "overload
window"-size of an upstream proxy is decreased very quickly to "1" which
imho results in a very susceptible upstream-proxy-behaviour.

e.g.
P1: proxy with window size 3
P2: proxy2 in normal state

P1                           P2
| --------Request 1--------> |
(counter=1)
| <--Response to Request 1---|
(counter=0)
(new window size: 1)
| --------Request 2--------> |
(counter=1)
counter==(window size) -> waiting ....
| <--Response to Request 2---|
| --------Request 3--------> |
(counter=1)
counter==(window size) -> waiting ....

When I got this correctly, I do not see an advantage of this technique,
as the upstream Proxy P1 stopps every transmission after sending just
one request, which is imho in the opposite direction of the "window
size"-idea, istn't it?

thx for clarification and br
Michael

-- 
Michael Hirschbichler, Mag. Dipl.-Ing.
Institut fuer Breitbandkommunikation
Technische Universitaet Wien
A-1040 Wien, Favoritenstr. 9-11/388
Tel: +43 1 58801 38846