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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
This is a very well written document. Before I turn my ballot into a YES I would like to DISCUSS one aspect of the SIP overload control which is related to manageability and specifically to observability. As I understand from the document and from the WG charter several methods of SIP overload control will be proposed and more than one may be supported by a SIP server. How can a network operator know what is supported on each device in the network? Also, for existing deployments, are there any mechanisms (alerts or status indication) that show whether one of the specific mechanism was triggered and activated? I believe that the design document needs to add some text refering to these operational aspects.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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/

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Design Considerations for Session Initiation Protocol (SIP) Overload Control) to Informational RFC


The IESG has received a request from the SIP Overload Control WG (soc) to
consider the following document:
- 'Design Considerations for Session Initiation Protocol (SIP) Overload
  Control'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Overload occurs in Session Initiation Protocol (SIP) networks when
  SIP servers have insufficient resources to handle all SIP messages
  they receive.  Even though the SIP protocol provides a limited
  overload control mechanism through its 503 (Service Unavailable)
  response code, SIP servers are still vulnerable to overload.  This
  document discusses models and design considerations for a SIP
  overload control mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

/Salvatore Loreto is the document Shepherd. He has reviewed this version (04) of the
document, and believes is ready for publication./


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

/The document has received significant review during its tenure in the
SoC WG. It has received review by key member of the SIPCORE wg.

The document underwent a first last call in September 2010. There were
two comments during that period related
- one related to how the draft discussion applied to SIP Server with media handling,
that result in the following text/

There are cases in which a SIP server runs other services that do not
            involve the processing of SIP messages (e.g., processing of RTP
            packets, database queries, software updates and event handling).
            These services may, or may not, be correlated with the SIP message
            volume.  These services can use up a substantial share of resources
            available on the server (e.g., CPU cycles) and leave the server in a
            condition where it is unable to process all incoming SIP requests.
            In these cases, the SIP server applies SIP overload control
            mechanisms to avoid congestion collapse on the SIP signaling plane.
            However, controlling the number of SIP requests may not significantly
            reduce the load on the server if the resource shortage was created by
            another service.  In these cases, it is to be expected that the
            server uses appropriate methods of controlling the resource usage of
            other services.  The specifics of controlling the resource usage of
            other services and their coordination is of scope for this document.

/
- the second one was related to how the system model described in section 4 can take
  into account the case where the receiving entity is a server farm,
that result in the following text/

In some cases, the servers D, E, and F are in a server farm and
            configured to appear as a single server to their upstream neighbors.
            In this case, server A can report overload on behalf of the server
            farm.  If the load balancer is not a SIP entity, servers D, E, and F
            can report the overall load of the server farm (i.e., the load of the
            virtual server) in their messages.  As an alternative, one of the
            servers (e.g., server E) can report overload on behalf of the server
            farm.  In this case, not all messages contain overload control
            information and it needs to be ensured that all upstream neighbors
            are periodically served by server E to received updated information.


/The document underwent a second last call in December of 2010. There were
only two spelling issues raised during that period.
/

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

//
The shepherd has no such concerns.//


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

/The shepherd has no such concerns. The shepherd is not aware of any
IPR assertions associated with this document.
/


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?


/The document represents agreement across a broad range of participants in the SOC working group
/

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

/No appeal has been threatened, nor has extreme discontent been expressed./

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See theInternet-Drafts Checklist 
        andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?


/The shepherd has checked ID nits./

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
/
The document only include informative references./
 

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

/The document does not require any IANA considerations.

/

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
/
This does not apply to this draft.
/

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

      Technical Summary
/The document discusses models and design considerations for a SIP overload control mechanism./

      Working Group Summary
/This document was originally started by an ad-hoc Design Team within the SIPPING wg.
The document was then adopted by the SIP Overload Control WG once it has been created.
/

      Document Quality
/The draft is a design considerations document and therefore there are no implementations.
There are implementations of drafts that are based on the design considerations draft.

The document was reviewed in an early stage by the transport area.
The current version (04) of the draft has also received a second review by Pasi Lassila an expert on control theory at Aalto university (in Finland)
identified by Lars Eggert.
/
      Personell
/Salvatore Loreto is the Document Shepherd
Robert Sparks is the Responsible RAI AD
/