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

From: Janet P Gunn <[email-masked]>
Date: Mon, 28 Mar 2011 16:44:29 -0400

My apologies for the lateness of these comnments.  Other work, and procrastination, were made worse by a major crash of my laptop.

But here are my comments on Appendix B of draft-ietf-soc-overload-control-02.

Assuming my temporary loaner laptop is up to the job, I'll be participating via jabber and audiostreaming on Tuesday.

Janet

Comments on draft-ietf-soc-overload-control-02.txt Appendix B RFC5390 requirements

Meeting Req 1

Change

“by requesting the upstream clients to reduce traffic destined downstream”

To

“by requesting the upstream clients to reduce traffic destined downstream only s much as is needed to prevent overloading the downstream nodes”

Meeting Req 2

But, the upstream node is permitted to send the rejected messages o other nodes, possibly overloading them.

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.

Meeeting REQ 6

Yes it is applicable.  The point is not whether it is a “new header” or a “part of an existing header”  but whether it is ambiguous, as opposed to being uniquely used for overload.  In this case, the header defined in this draft is ONLY used to signal overload information, so it satisfies REQ 6.

Meeting REQ 8

Change

“will not retry the request on another element”

to

“will not retry the request to another element it knows to be overloaded”

Meeting REQ  9

Change “to another element”

To

“to another element that has not indicated that it is overloaded”

Meeting REQ  10

Should be “No”.  There is no limit on the number of upstream clients, but the upstream clients MUST be enumerated (listed).

Meeting REQ 12

Add “as long as the domains themselves agree to honor the signals” (or something similar- technology OK, business policies may not be OK)

Meeting REQ 14

I don’t think the text here addresses the Requirement-  I do not think that this mechanism, on its own, mitigates the “avalanche restart” problem.

Meeting REQ 16

It is not clear to me why being in the Via header “minimizes overhead”.

Meeting REQ 17

If there is NO “confidential and authenticated channel”, then this mechanism CAN be used to DDoS.

Meeting REQ 18

I would say “partial”, as it leaves it to local policy.  The mechanism ITSELF does not address which messages to drop.

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.

Meeting REQ 23

Since it still “depends on the type of load balancer”, I think this should be “partial”.

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

[email-masked] wrote: -----

To: [email-masked]
From: "Vijay K. Gurbani" <[email-masked]>
Sent by: [email-masked]
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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Volker Hilt <[email-masked]>
Date: Thu, 31 Mar 2011 12:18:56 +0200

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

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

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

Thanks,

Volker