Skip to main content

Design Considerations for Session Initiation Protocol (SIP) Overload Control
draft-ietf-soc-overload-design-08

Yes

(Dan Romascanu)
(Wesley Eddy)

No Objection

(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)

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

Dan Romascanu Former IESG member
(was Discuss) Yes
Yes () Unknown

                            
Robert Sparks Former IESG member
Yes
Yes (2011-06-23) Unknown
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/
Wesley Eddy Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-06-29) Unknown
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.
David Harrington Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2011-06-29) Unknown
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 Former IESG member
No Objection
No Objection (2011-06-28) Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2011-06-28) Unknown
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.