Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-09-22
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-07-31
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-07-18
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-05-15
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-05-14
15 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-05-14
15 (System) IANA Action state changed to Waiting on Authors
2014-05-14
15 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-05-14
15 (System) RFC Editor state changed to EDIT
2014-05-14
15 (System) Announcement was received by RFC Editor
2014-05-14
15 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-05-14
15 Amy Vezza IESG has approved the document
2014-05-14
15 Amy Vezza Closed "Approve" ballot
2014-05-14
15 Amy Vezza Ballot approval text was generated
2014-05-14
15 Amy Vezza Ballot writeup was changed
2014-05-14
15 Salvatore Loreto Tag Point Raised - writeup needed cleared.
2014-05-14
15 Salvatore Loreto IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2014-03-03
15 Vijay Gurbani IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-03-03
15 Vijay Gurbani New version available: draft-ietf-soc-overload-control-15.txt
2014-02-14
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-02-06
14 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2014-02-06
14 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-02-06
14 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-02-06
14 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2014-02-06
14 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-02-06
14 Ted Lemon
[Ballot comment]
Section 11, last paragraph:
  To prevent such attacks, servers should monitor client behavior to
  determine whether they are complying with overload …
[Ballot comment]
Section 11, last paragraph:
  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).

This is probably just my failure of comprehension, but it is not at all clear to me how a server can monitor client behavior.  How does the server distinguish between a situation where the client is not throttling, versus a situation where the client _is_ throttling, but load has increased proportionally to the amount of throttling requests, so that the observed load appears constant?  Are you simply gambling that this will never happen, or did I misunderstand something?
2014-02-06
14 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-02-06
14 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2014-02-06
14 Stephen Farrell
[Ballot comment]

Thanks for the good security considerations text on DoS!

I think the changes proposed from the secdir review [1]
look good and assume …
[Ballot comment]

Thanks for the good security considerations text on DoS!

I think the changes proposed from the secdir review [1]
look good and assume they'll be incorporated into a
revision.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04521.html

In addition, presumably a DDoS attack could cause an honest
server to start signalling an overload condition.  If such
a server had a long oc-validity time, then that validity
time might act as an accelerator for the DDoS attack. Even
the 500ms default might mean that a botnet could use this
perhaps. Is that worth an additional bit of security
consideration text? I guess the attack pattern there would
be that the botnet would pop up and try overload the server
every oc-validity milliseconds or so and go quiet in the
intervals. I've no idea if that could be confused with
nominal reactions to a real overload though.
2014-02-06
14 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-02-05
14 Pete Resnick
[Ballot comment]
1:

- First paragraph:

  In fact, overload may lead to
  a situation in which the throughput drops down to a small …
[Ballot comment]
1:

- First paragraph:

  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.

I don't think that's right. My lower-layer comrades can correct me if I'm wrong, but my understanding is that congestion collapse is when the congestion control mechanism itself (for example, retransmission in the face of packet loss) adds additional traffic to the network, eventually swamping the network such that no (or exceedingly little) new traffic can get into the network. A network at maximum capacity where traffic is slow because there's simply too much traffic for that network to handle is not "collapsed", as far as I understand the term. So long as everyone is holding back their traffic such that the network is not being flooded with retransmissions or the like, that's just overload, not collapse.

In any event, I don't think the use of the term adds anything to the discussion, so I would simply (a) strike the last two sentences of the first paragraph, (b) strike "and it cannot prevent congestion collapse" from the fourth paragraph, and (c) change "avoiding congestion collapse and" to "thereby" in the fifth paragraph.

- Please change "we only consider" to "this document only addresses".

- Please strike the last two sentences (the conformance sentences) of section 1. They add nothing to the document.

2, Last paragraph: I think normative language as described in this paragraph adds nothing but confusion to the text and is unnecessary. I suggest striking this paragraph and making the changes I note below to remove the unnecessary normative language. My suggestions below do not change the meaning of the protocol at all.

3: Please change "We now explain the" to "This section gives an" in the first sentence.

4.1: Change "MUST add" in paragraphs 2 & 3 to "adds".

4.2:

- Change "MUST add" in paragraph 2 to "adds".

- In the last sentence of paragraph 3, I suggest changing "must not assume" to "can not assume", to avoid confusion.

- In the fourth paragraph, change "it MUST choose one algorithm from the list and return the single selected algorithm" to "it chooses one algorithm from the list and MUST return the single selected algorithm".

4.3: Change "the client MUST behave as if overload control is not in effect between it and" to "overload control is not in effect between the client and".

4.4: Change "MUST be inserted" to "is inserted" in the first sentence.

5: Change "MUST determine" to "determines" in the second paragraph.

5.1:

- Change "MUST insert" (x2) with "inserts" in the first paragraph.

- Change "MUST determine" to "determines and change "MUST follow" to "follows" in the third paragraph.

5.2:

- Change "MAY" to "can" in the third paragraph.

- Change the last paragraph as follows:

  This specification provides a good overload control mechanism that
  can protect a SIP server from overload.  However, if a SIP server
  wanted to limit its overload control capability for privacy reasons,
  it might decide to perform overload control only for...

5.5: Change "MUST determine" (x2) to "determines" in paragraph 3.

5.7:

- Change "MUST set" to "sets" in the second paragraph.

- In the last paragraph, change the second sentence as follows:

  If the value of the "oc-validity" parameter is 0, this indicates to
  the client that overload control of messages destined to the server
  is no longer necessary and the traffic can flow without any
  reduction.

7.1:

- Change "MUST appear" to "appears" in the first paragraph.

- Change the third sentence of the second paragraph as follows:

  This value indicates to the client the percentage by which the client
  is to reduce the number of requests being forwarded to the overloaded
  server.
 
9: I suggest using the ABNF extension mechanism:

      via-params =/ oc / oc-validity / oc-seq / oc-algo

Much simpler.

10: I think this section should be moved to an appendix.
2014-02-05
14 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-02-05
14 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-02-05
14 Spencer Dawkins
[Ballot comment]
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

  …
[Ballot comment]
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!")
2014-02-05
14 Spencer Dawkins [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from Discuss
2014-02-05
14 Richard Barnes Intended Status changed to Proposed Standard from Internet Standard
2014-02-05
14 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-02-05
14 Jari Arkko
[Ballot discuss]
The intended status seems wrong (both on last call and data tracker). Should be Proposed Standard, not Internet Standard, unless we are missing …
[Ballot discuss]
The intended status seems wrong (both on last call and data tracker). Should be Proposed Standard, not Internet Standard, unless we are missing something. It was Brian Carpenter in his Gen-ART review who noticed this - thanks.
2014-02-05
14 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko
2014-02-05
14 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2014-02-04
14 Spencer Dawkins
[Ballot discuss]
I am very pleased to see this spec moving forward and expect to ballot Yes after we chat about one question. It's a …
[Ballot discuss]
I am very pleased to see this spec moving forward and expect to ballot Yes after we chat about one question. It's a borderline Discuss point, but seemed important.

Comment for context:

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.

Actual Discuss point:

The one that doesn't make sense to me is this one:

  A SIP client SHOULD honor the local policy for prioritizing SIP
  requests relating to emergency calls as identified by the SOS URN
  [RFC5031] indicating an emergency request.

Is there any guidance you can give on why that's not a MUST?
2014-02-04
14 Spencer Dawkins
[Ballot comment]
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

  …
[Ballot comment]
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 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!")
2014-02-04
14 Spencer Dawkins [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins
2014-02-04
14 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-02-03
14 Brian Carpenter Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Brian Carpenter.
2014-02-02
14 Joel Jaeggli [Ballot comment]
expect to see a 15 based on the secdir feedback proposal.
2014-02-02
14 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-01-31
14 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2014-01-31
14 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2014-01-30
14 Richard Barnes Ballot has been issued
2014-01-30
14 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-01-30
14 Richard Barnes Created "Approve" ballot
2014-01-30
14 Richard Barnes Placed on agenda for telechat - 2014-02-06
2014-01-30
14 Richard Barnes State changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-01-16
14 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey.
2013-12-23
14 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-12-23
14 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-soc-overload-control-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-soc-overload-control-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Header Field Parameters and Parameter Values registry in the Session Initiation Protocol (SIP) Parameters page at

http://www.iana.org/assignments/sip-parameters/

four new Header Field Parameters will be registered as follows:

Header Field: Via
Parameter Name: oc
Predefined Values: yes
Reference: [ RFC-to-be ]

Header Field: Via
Parameter Name: oc-validity
Predefined Values: yes
Reference: [ RFC-to-be ]

Header Field: Via
Parameter Name: oc-seq
Predefined Values: yes
Reference: [ RFC-to-be ]

Header Field: Via
Parameter Name: oc-algo
Predefined Values: yes
Reference: [ RFC-to-be ]

IANA understands that this action is the only one required upon approval.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-12-23
14 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-12-23)
2013-12-14
14 Brian Carpenter Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Brian Carpenter.
2013-12-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2013-12-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2013-12-12
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2013-12-12
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2013-12-12
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Juergen Quittek
2013-12-12
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Juergen Quittek
2013-12-09
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-12-09
14 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) Overload …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) Overload Control) to Internet Standard


The IESG has received a request from the SIP Overload Control WG (soc) to
consider the following document:
- 'Session Initiation Protocol (SIP) Overload Control'
  as Internet Standard

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 2013-12-23. 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 defines the behaviour of SIP servers involved in overload
  control, and in addition, it specifies a loss-based overload scheme
  for SIP.




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

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1364/



2013-12-09
14 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-12-09
14 Cindy Morgan Last call announcement was generated
2013-12-09
14 Richard Barnes Last call was requested
2013-12-09
14 Richard Barnes Ballot approval text was generated
2013-12-09
14 Richard Barnes State changed to Last Call Requested from AD Evaluation::AD Followup
2013-12-09
14 Richard Barnes Last call announcement was generated
2013-12-09
14 Richard Barnes Last call announcement was generated
2013-12-09
14 Richard Barnes Ballot writeup was changed
2013-12-09
14 Richard Barnes Ballot writeup was generated
2013-12-09
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-12-09
14 Vijay Gurbani New version available: draft-ietf-soc-overload-control-14.txt
2013-11-22
13 Richard Barnes State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2013-07-12
13 Richard Barnes State changed to AD Evaluation from Publication Requested
2013-06-13
13 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

    Internet Standard

  Why is this …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

    Internet Standard

  Why is this the proper type of RFC?

    It defines the actual mechanism and propose a default algorithm for
    the SIP? Overload Control Mechanism

  Is this type of RFC indicated in the title page header?

    Yes.


(2) 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:
    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 defines the protocol for communicating overload information
    between SIP servers and clients, so that clients can reduce the
    volume of traffic sent to overloaded servers, avoiding congestion
    collapse and increasing useful throughput.

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.
    There has been 13 versions of the document of the document since it
    has?been adopted as WG item, and the document has passed two
    WGLC?one in March 2012
    (http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html)
    and a second one in February 2013
    (http://www.ietf.org/mail-archive/web/sip-overload/current/msg00911.html).
    All the issues and the feedback raised have been addressed, and the
    wg is now happy with the status.


Document Quality:
Are there existing implementations of the protocol?

    I am not aware of any.

Have a significant number of vendors indicated their plan to implement
the specification?

    Yes, all the major vendors have indicated they have a plan to
    implement it.
    Moreover also 3GPP is supporting it and it will be referenced in its
    spec.

Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    No

Personnel:
Who is the Document Shepherd?

    Salvatore Loreto

Who is the Responsible Area Director?

    Richard Barnes

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

    The document is clear and very well written.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

    I don't have any concern about the document. The process has been a
    bit slow but the document is really solid now, it has passed 2 WGLCs
    that have?generated several comments, feedback and the authors have
    discussed and?eventually fixed all of them.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

    I don't have any particular concern with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?


(8) Has an IPR disclosure been filed that references this document?

            No!

(9) 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?

    This document has received unanimous consensus from all the wg
    participants.?Even if the number of participants in the wg has been
    always quite low.

(10) 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 publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    I haven't identified any nit.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
does not apply.
(13) Have all references within this document been identified as either
normative or informative?

    Yes.

(14) 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 plan for their completion?

    No. All the normative references are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    The IANA consideration section is consistent with the body of the
    document. All? the four new parameters for the SIP Via header for
    overload control are associated with the appropriate reservations in
    IANA registries.
    The wg has also discussed about the opportunity to establish for the
    "oc-algo" parameter
    (http://www.ietf.org/mail-archive/web/sip-overload/current/msg00925.html
    ), but there is a wg consensus on not to do it
    (http://www.ietf.org/mail-archive/web/sip-overload/current/msg00935.html
    )

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
2013-06-13
13 Cindy Morgan Changed document writeup
2013-06-13
13 Cindy Morgan Intended Status changed to Internet Standard
2013-06-13
13 Cindy Morgan IESG process started in state Publication Requested
2013-06-13
13 (System) Earlier history may be found in the Comment Log for draft-gurbani-soc-overload-control
2013-05-23
13 Vijay Gurbani New version available: draft-ietf-soc-overload-control-13.txt
2013-02-20
12 Salvatore Loreto Changed shepherd to Salvatore Loreto
2013-02-20
12 Salvatore Loreto IETF state changed to In WG Last Call from WG Document
2013-02-01
12 Vijay Gurbani New version available: draft-ietf-soc-overload-control-12.txt
2012-11-21
11 Vijay Gurbani New version available: draft-ietf-soc-overload-control-11.txt
2012-10-22
10 Vijay Gurbani New version available: draft-ietf-soc-overload-control-10.txt
2012-07-06
09 Vijay Gurbani New version available: draft-ietf-soc-overload-control-09.txt
2012-03-12
08 Vijay Gurbani New version available: draft-ietf-soc-overload-control-08.txt
2012-01-18
07 (System) New version available: draft-ietf-soc-overload-control-07.txt
2012-01-02
06 (System) New version available: draft-ietf-soc-overload-control-06.txt
2011-10-28
05 (System) New version available: draft-ietf-soc-overload-control-05.txt
2011-10-28
04 (System) New version available: draft-ietf-soc-overload-control-04.txt
2011-09-02
03 (System) New version available: draft-ietf-soc-overload-control-03.txt
2011-09-01
07 (System) Document has expired
2011-02-28
02 (System) New version available: draft-ietf-soc-overload-control-02.txt
2011-01-20
01 (System) New version available: draft-ietf-soc-overload-control-01.txt
2010-11-19
00 (System) New version available: draft-ietf-soc-overload-control-00.txt