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

Note: This ballot was opened for revision 08 and is now closed.

(Wesley Eddy) Yes

(Dan Romascanu) (was Discuss) Yes

(Robert Sparks) Yes

Comment (2011-06-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please take these editorial suggestions into account:

1) At "Introducing many such short-lived sybils" - I suggest s/sybils/servers. If you want to compare this to a sybil attack, an additional sentence
would be better.

2) I suggest s/affecting a reduce in the service/affecting a reduction in the service/

3) At "keep the receiver window fill", I suggest s/fill/full/

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-06-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2011-06-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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. 

(David Harrington) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2011-06-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Peter Saint-Andre) No Objection

Comment (2011-06-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Sean Turner) No Objection