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

From: Volker Hilt <[email-masked]>
Date: Wed, 11 Aug 2010 22:24:08 -0400

Michael,

On 7/27/2010 6:49 AM, Michael Hirschbichler wrote:
> 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?

Yes, the window size can be changed using explicit messages.

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

The response to the first request would not necessarily set the window 
size to 1. If it did, the flow below is correct. But then it is exactly 
what's desired by P2.
>
> 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?
>
It can use a window size larger than 1 to avoid this behavior.

Thanks,

Volker