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

[Janet P Gunn <[e-mail]>]

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.

[e-mail] wrote: -----

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