Subject: Re: [sip-overload] SIP overload control draft - sender behavior

From: Volker Hilt <[email-masked]>
Date: Mon, 19 Jul 2010 11:48:13 +0200

Shaun,

sorry for the delayed response. More inline.

On 6/22/2010 4:55 PM, Bharrat, Shaun wrote:
> It was my question that sent us down this rathole so I wanted to expand
> a bit on the my original question. I understand the tradeoffs between
> sending a rate versus a loss percentage. I don't question the logic or
> reasoning that led to the choice of a loss percentage. I am sure the
> rate
> choice has its own rat's nest of issues (how to appoportion the rate for
> example).
>
> So, assuming a loss percentage, my question was whether an
> sender would be allowed (but not required) to behave more sensibly
> without
> violating the letter (or spirit) of the draft. Specifically, if the
> sender *knows* its rate towards the overloaded peer, it can in theory
> adjust its rate to (100-oc%) of the rate that resulted in the overload
> indication. In abstract, this would seem to behave better if the load
> towards the overloaded peer is changing. But the concern is that this
> might affect the stability of the overall algorithm if some senders
> behave this way.
>
> So, is the draft prescribing the sender MUST send (100-oc%) of its load
> regardless of the variability of the load (because of stability
> concerns),
> or is it a must send NO MORE than 100-oc% thereby allowing the sender to
> use a higher drop percentage depending on its understanding of the load?
>
Interesting question.

If a server decides to throttle more requests than it is required to 
under the current oc value, it is in effect hiding the additional 
messages from the overloaded server. The overloaded server can use the 
current rate it is receiving from an upstream neighbor multiplied by the 
current loss percentage to determine the original load. If the neighbor 
has discarded more messages that it was required to, these extra 
messages will not be counted. This may be perfectly fine. It simply 
means that this neighbor is discarding more messages than it's neighbors 
that may follow the loss percentage more closely. In a sense, it is 
"friendlier" than other servers.

Thanks,

Volker (as individual contributor)

>> -----Original Message-----
>> From: Volker Hilt [mailto:[email-masked]]
>> Sent: Tuesday, June 22, 2010 10:24 AM
>> To: Vijay K. Gurbani
>> Cc: Bharrat, Shaun; [email-masked]; Henning Schulzrinne
>> Subject: Re: [sip-overload] SIP overload control draft
>>
>> On 6/22/2010 6:28 AM, Vijay K. Gurbani wrote:
>>> On 06/18/2010 08:20 AM, Bharrat, Shaun wrote:
>>>> Vijay:
>>>>
>>>> Some questions on the -00 version of the draft.
>>>
>>> Shaun: Thanks for the feedback.  More inline.
>>>
>>>> 3.2
>>>>
>>>> When a SIP server retransmits a response, it MUST use the 'oc'
>>>>       parameter value and 'oc-validity' parameter value
>> consistent with the
>>>>       overload state at the time the retransmitted response
>> is sent.  This
>>>>       implies that the values in the 'oc' and 'oc-validity'
>> parameters may
>>>>       be different then the ones used in previous
>> retransmissions of the
>>>>       response.
>>>>
>>>> I understand the desire for this but I would like to point
>> out that
>>>> some (many) implementations might balk at this. Is this the first
>>>> case where the retransmission of a response requires that the
>>>> implementation rebuild the SIP message rather than resend the
>>>> original? Determining the overload state and retransmission of a
>>>> response for a transaction might also be in two very
>> separated layers
>>>> so even getting the updated information might be problematic.
>>>
>>> That is a valid point.  One way to address it is to simply
>> downgrade
>>> the MUST to a SHOULD.  That way, if the overloaded server
>> chooses to
>>> provide finer-grained information to its upstream peer, the
>> upstream
>>> peer will gladly take it and update its state with respect to the
>>> overload condition of the overloaded downstream peer accordingly.
>>>
>> Indeed. It might be useful to add a timestamp to an oc value
>> that indicates when the oc value was created on a server. The
>> receiver of an oc value can then compare the timestamp of the
>> oc value with the most recent one it has received. That way,
>> it can discard older values that may be contained in a
>> retransmission from a device that does not update oc values.
>>
>>
>>>> 3.5
>>>>
>>>> This seems to be covered by this...
>>>>
>>>>      A SIP server compliant to this specification MUST honor 'oc'
>>>>       parameter values it receives from downstream
>> neighbors.  The SIP
>>>>       server MUST NOT forward more messages to a SIP server
>> than allowed by
>>>>       the current 'oc' parameter value from this server.
>>>> ..
>>>> The SIP server SHOULD use the following algorithm to
>> determine if it
>>>>       can forward the request.  The SIP server draws a random number
>>>>       between 1 and 100 for the current request.  If the
>> random number is
>>>>       less than or equal to the 'oc' parameter value, the
>> request is not
>>>>       forwarded.  Otherwise, the request is forwarded.  Any other
>>>>       algorithms that approximate the random number
>> algorithm may be used
>>>>       as well.
>>>>
>>>> Does this constrain the sender to blindly following a pure % drop
>>>> scheme?
>>>> Suppose the sender is capable of monitoring the rate to an
>> overloaded
>>>> server and the attempt rate changes significantly. The
>> goal (I would
>>>> think)
>>>> is that the sender send no more than oc % of the rate at
>> the time the
>>>> oc was issued. Does this text allow the sender to do this
>> (i.e. send
>>>> less than allowed by oc % when attempt rate goes up and
>> more than oc
>>>> % when attempt rate goes down)?
>>>
>> The draft is written in a way that the oc % fixes the
>> percentage of traffic that is dropped. If the traffic
>> increases, that will increase the rate that is forwarded as
>> the forwarded rate is a fixed fraction of the offered rate.
>> If that is too high, the server needs to increase the % in
>> its feedback.
>>
>> I think the bigger question is whether a fixed rate or a
>> fixed loss percentage is preferable as feedback.
>>
>> There is some discussion on this topic in section 9 of
>> https://datatracker.ietf.org/doc/draft-hilt-soc-overload-design/
>>
>> Comments are highly appreciated!
>>
>> Thanks,
>>
>> Volker
>>
>>
>>> I am not sure I follow.  The tact taken by this draft is that the
>>> overloaded server remains the authoritative entity to
>> provide backoff
>>> information to its upstream peers.  Asking the sender --- i.e., the
>>> upstream server sending requests to the overloaded one ---
>> to monitor
>>> the rate of the downstream (overloaded) server has its own set of
>>> problems, no?  Unless, of course, I misunderstood what you wrote
>>> above.
>>>
>>> Thanks,
>>>
>>> - vijay
>>