Session Initiation Protocol (SIP) Overload Control
draft-ietf-soc-overload-control-15

These are all non-blocking, but I'd appreciate it if you'd consider them along with any other comments you receive.

In 1.  Introduction

   As with any network element, a Session Initiation Protocol (SIP)
   [RFC3261] server can suffer from overload when the number of SIP
   messages it receives exceeds the number of messages it can process.
   Overload can pose a serious problem for a network of SIP servers.
   During periods of overload, the throughput of a network of SIP
   servers can be significantly degraded.  In fact, overload may lead to
   a situation in which the throughput drops down to a small fraction of
   the original processing capacity.  This is often called congestion
   collapse.

   Overload is said to occur if a SIP server does not have sufficient
   resources to process all incoming SIP messages.  These resources may
   include CPU processing capacity, memory, network bandwidth, input/
   output, or disk resources.

I'm struggling with including "network bandwidth" here, with no qualifications. That seems to conflate both SIP Overload and TSV congestion, thusly:

If UA A sends a request for UA B to a proxy:

   UA A -----------> Proxy -----------> UA B

But there's not enough bandwidth between the proxy and UA B, so:

   UA A -----------> Proxy ---->//      UA B

I'd be OK with characterizing that as "network bandwidth" SIP overload covered by this draft, but

if the problem of insufficient bandwidth is between UA A and the proxy:

   UA A --->//       Proxy               UA B 

the proxy never sees the request. That's not in scope for this draft, is it? 

If not, is there an obvious way to tighten this up a bit? (maybe something like "network bandwidth on the forwarding path"?)

In 2.  Terminology

   Unless otherwise specified, all SIP entities described in this
   document are assumed to support this specification.

In 10.2.  Backwards Compatibility, you lead me to think that if my path from conforming UAC to conforming UAS traverses some proxies that do support this specification and other proxies that do not, depending on where the non-conforming proxies are and what proxies are overloaded, you wouldn't do worse than today's behavior. It might be helpful to say that here.

In 5.10.1.  Message prioritization at the hop before the overloaded server, there are several items listed that a client SHOULD take into account when deciding what requests to prioritize. Most of them make sense to me, but it's not obvious that they are 2119 SHOULDs ("good advice, but not required for interoperability").

In 7.1.  Special parameter values for loss-based overload control

   The SIP client may use any
   algorithm that reduces the traffic it sends to the overloaded server
   by the amount indicated.  Such an algorithm SHOULD honor the message
   prioritization discussion of Section 5.10.1. 

since 5.10.1 is full of SHOULDs, this is saying that you SHOULD do what you SHOULD do. I'm only pointing that out because it struck me as funny ...

In 11.  Security Considerations

   Attacks that indicate false overload control can be mitigated by
   using TCP or Websockets [RFC6455], or better yet, TLS in conjunction
   with applying BCP 38 [RFC2827]. 

If you're already pointing implementers to TCP for better resistance to attacks, would it make sense to recommend TLS more strongly (in 2014!)? But it's not obvious that on-path attackers that can modify traffic wouldn't just drop anything they find inconvenient, I guess.

Also in 11.  Security Considerations

   A malicious SIP entity could gain an advantage by pretending to
   support this specification but never reducing the amount of traffic
   it forwards to the downstream neighbor.  If its downstream neighbor
   receives traffic from multiple sources which correctly implement
   overload control, the malicious SIP entity would benefit since all
   other sources to its downstream neighbor would reduce load.

      The solution to this problem depends on the overload control
      method.  For rate-based and window-based overload control, it is
      very easy for a downstream entity to monitor if the upstream
      neighbor throttles traffic forwarded as directed.  For percentage
      throttling this is not always obvious since the load forwarded
      depends on the load received by the upstream neighbor.

   To prevent such attacks, servers should monitor client behavior to
   determine whether they are complying with overload control policies.
   If a client is not conforming to such policies, then the server
   should treat it as a non-supporting client (see Section 5.10.2).

Is this text coming close to saying "malicious SIP entities can game this specification, so you ought to monitor client behavior, but there are some overload control methods you can't monitor reliably"? If so ... is the only required overload control method one you can't monitor reliably?

In Appendix B.  RFC5390 requirements

   REQ 4: The mechanism must be capable of dealing with elements that do
   not support it, so that a network can consist of a mix of elements
   that do and don't support it.  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.  Ideally, there should be incremental improvements in overall
   network throughput as increasing numbers of elements in the network
   support the mechanism.

   Meeting REQ 4: Partially.  The mechanism is designed to reduce
   congestion when a pair of communicating entities support it.  If a
   downstream overloaded SIP server does not respond to a request in
   time, a SIP client will attempt to reduce traffic destined towards
   the non-responsive server as outlined in Section 5.9.

I'm not understanding how this is "partially". What did you miss?

   REQ 5: The mechanism should not assume that it will only be deployed
   in environments with completely trusted elements.  It should seek to
   operate as effectively as possible in environments where other
   elements are malicious; this includes preventing malicious elements
   from obtaining more than a fair share of service.

   Meeting REQ 5: Partially.  Since overload control information is
   shared between a pair of communicating entities, a confidential and
   authenticated channel can be used for this communication.  However,
   if such a channel is not available, then the security ramifications
   outlined in Section 11 apply.

Does your point about not being able to monitor loss-based overload control methods also apply here?

   REQ 12: The mechanism should work between servers in different
   domains.

   Meeting REQ 12: Yes, there are no inherent limitations on using
   overload control between domains.

I'm hearing a particular operator's voice saying "I'm not telling my competitors _anything_ about the topology of my network OR the traffic within my network". Perhaps it's worth mentioning that operators have to be willing to expose at least a little information about their network to other operators, in order for this mechanism to work well.

("Don't clear all the oc Via parameters at your SBCs and expect this to work across your interconnect points!")