Re: [sip-overload] Comments on draft-ietf-soc-overload-control-02 - was Re: draft-ietf-soc-overload-control-01 submitted

>
> Meeting Req 2
>
> But, the upstream node is permitted to send the rejected messages o
> other nodes, possibly overloading them.
>
The draft discourages this behavior.

> Meeting REQ 4
>
> But if an UPSTREAM node does not support this mechanism, it may generate
> more downstream traffic than has been throttles by the conforming nodes,
> and the downstreamnode9s0 will continue to be overloaded.
>
I believe this is within what is required by REQ 4:

    In other words, the mechanism should
    not work only in environments where all elements support it.  It is
    reasonable to assume that it works better in such environments, of
    course.

The draft discusses how to mitigate the impact of traffic from elements 
that don't support it and the reduction of traffic from elements that do 
support the draft will help to reduce overload.

> Meeting REQ 16
>
> It is not clear to me why being in the Via header “minimizes overhead”.
>
I believe the argument is that there is very little additional protocol 
complexity added by this mechanism.

> Meeting REQ 18
>
> I would say “partial”, as it leaves it to local policy.The mechanism
> ITSELF does not address which messages to drop.
>
REQ 18 is about identifying a server (not the messages to drop).

REQ 19 (which you were probably referring to): the draft does give 
guidance on which messages to drop. It does leave the possibility for 
local policy but that seems to be within this requirement.

> Meeting REQ 20.
>
> I think this should be NO.An upstream node that does not implement this
> mechanism WILL receive a significant measure of extra benefit.
>
I believe this should be a partial. The draft discusses how to address 
this problem using local overload control. As long as the overload from 
the non-compliant servers does not exceed the limit of what can be done 
using local overload control, it does not receive extra benefit. If the 
load from these servers passes that point, the server may run into 
overload (in which case all servers are affected).

> Meeting REQ 23
>
> Since it still “depends on the type of load balancer”, I think this
> should be “partial”.
>
The draft discusses both sip-aware and non-sip-aware load balancers. 
Which case is not addressed?

Thanks,

Volker

>
> -----sip-overload-bounces@ietf.org wrote: -----
>
>     To: sip-overload@ietf.org
>     From: "Vijay K. Gurbani" <vkg@bell-labs.com>
>     Sent by: sip-overload-bounces@ietf.org
>     Date: 02/09/2011 10:11AM
>     Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted
>
>     On 02/08/2011 04:10 PM, Volker Hilt wrote:
>      > Vijay, Bruno, following the discussion above - I believe that
>     REQ-23 can
>      > in fact be met for load balancers that are not SIP aware. Of course,
>      > there is always a way to build a system that does not work. But
>     the key
>      > point is that this requirement can be met with the correct design.
>      >
>      > My suggestion would be to document these approaches in the draft
>     as this
>      > will be very relevant for implementers.
>      >
>      > I think with this documentation, a "Yes" to REQ-23 is appropriate.
>
>     OK, this is more work for me then simply changing a "Yes" to "Partial".
>     But, I will go ahead and do so. If we need more discussion around
>     this, we should hold it now before I update the draft and summarize
>     the current discussion ...
>
>     Thanks,
>
>     - vijay
>     --
>     Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>     1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>     Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
>     Web: http://ect.bell-labs.com/who/vkg/
>     _______________________________________________
>     sip-overload mailing list
>     sip-overload@ietf.org
>     https://www.ietf.org/mailman/listinfo/sip-overload
>
>