Design Considerations for Session Initiation Protocol (SIP) Overload Control
RFC 6357

In Section 1

   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.

Reading (and re-reading) this paragraph, I could not extract from the 
text whether the concern is the network throughput of SIP messages, or
the impact on the data flows that are controlled by the SIP messages. 
It seems to me that you need to make this clear up front, and that you
should spend some time distinguishing the impact of SIP overload on
existing data flows from the case you are describing.

It may be that this is obvious to the informed reader, but it should be
easy for you to explain, and that will make life easier for future
readers.

This is a nice piece of architectural work. How did this end up in a WG instead of the IRTF? :-)

One mostly editorial comment. From the Introduction:

   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.

That's not congestion collapse. The first paragraph of section 2 talks about what *is* congestion collapse: congestion-related retransmissions themselves increasing congestion. Something's missing from the above paragraph.

This is a fine document. Please expand acronyms on first use (e.g., "UA", "UAC", "UAS", "RPH"). A reference to RFC 4732 ("Internet Denial-of-Service Considerations") might be appropriate.

Nice document, with good security considerations. 
Thanks.

One possible additional security consideration - if an
attacker can convince senders that various other nodes 
are overloaded, then it could cause traffic to be 
directed towards attacker-chosen servers. That could 
either be part of a DoS on the attacker-chosen servers,
or, if the attacker-chosen servers are operated by or 
for the attacker, then the attacker could monitor 
possibly many more calls than otherwise.