draft-ietf-dime-doic-rate-control-03.txt   draft-ietf-dime-doic-rate-control-04.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. Diameter Maintenance and Extensions (DIME) S. Donovan, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track E. Noel Intended status: Standards Track E. Noel
Expires: September 19, 2016 AT&T Labs Expires: April 7, 2017 AT&T Labs
March 18, 2016 October 4, 2016
Diameter Overload Rate Control Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-03.txt draft-ietf-dime-doic-rate-control-04.txt
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. This extension Indication Conveyance (DOIC) [RFC7683] base solution. This extension
adds a new overload control abatement algorithm. This abatement adds a new overload control abatement algorithm. This abatement
algorithm allows for a DOIC reporting node to specify a maximum rate algorithm allows for a DOIC reporting node to specify a maximum rate
at which a DOIC reacting node sends Diameter requests to the DOIC at which a DOIC reacting node sends Diameter requests to the DOIC
reporting node. reporting node.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2016. This Internet-Draft will expire on April 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 9 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 9
6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 9 6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 9
7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 9 7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 9
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11
7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 11 7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 11
7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 14 7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 14
7.3.3. Optional enhancement: avoidance of resonance . . . . 16 7.3.3. Optional enhancement: avoidance of resonance . . . . 16
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document defines a new Diameter overload control abatement This document defines a new Diameter overload control abatement
algorithm. algorithm.
The base Diameter overload specification [RFC7683] defines the loss The base Diameter overload specification [RFC7683] defines the loss
algorithm as the default Diameter overload abatement algorithm. The algorithm as the default Diameter overload abatement algorithm. The
loss algorithm allows a reporting node to instruct a reacting node to loss algorithm allows a reporting node to instruct a reacting node to
reduce the amount of traffic sent to the reporting node by abating reduce the amount of traffic sent to the reporting node by abating
(diverting or throttling) a percentage of requests sent to the (diverting or throttling) a percentage of requests sent to the
server. While this can effectively decrease the load handled by the server. While this can effectively decrease the load handled by the
server, it does not directly address cases where the rate of arrival server, it does not directly address cases where the rate of arrival
of service requests increase quickly. If the service requests that of service requests increases quickly. If the service requests that
result in Diameter transactions increases quickly then the loss result in Diameter transactions increases quickly then the loss
algorithm cannot guarantee the load presented to the server remains algorithm cannot guarantee the load presented to the server remains
below a specific rate level. The loss algorithm can be slow to below a specific rate level. The loss algorithm can be slow to
protect the stability of reporting nodes when subjected with rapidly protect the stability of reporting nodes when subjected with rapidly
changing loads. changing loads.
Consider the case where a reacting node is handling 100 service Consider the case where a reacting node is handling 100 service
requests per second, where each of these service requests results in requests per second, where each of these service requests results in
one Diameter transaction being sent to a reacting node. If the one Diameter transaction being sent to a reacting node. If the
reacting node is approaching an overload state, or is already in an reacting node is approaching an overload state, or is already in an
skipping to change at page 4, line 10 skipping to change at page 4, line 10
returns to 100 per second, this will result in just 9 transactions returns to 100 per second, this will result in just 9 transactions
per second being sent to the reporting node, requiring a new overload per second being sent to the reporting node, requiring a new overload
report setting the reduction percentage back to 10%. This control report setting the reduction percentage back to 10%. This control
feedback loop has the potential to make the situation worse. feedback loop has the potential to make the situation worse.
One of the benefits of a rate based algorithm is that it better One of the benefits of a rate based algorithm is that it better
handles spikes in traffic. Instead of sending a request to reduce handles spikes in traffic. Instead of sending a request to reduce
traffic by a percentage, the rate approach allows the reporting node traffic by a percentage, the rate approach allows the reporting node
to specify the maximum number of Diameter requests per second that to specify the maximum number of Diameter requests per second that
can be sent to the reporting node. For instance, in this example, can be sent to the reporting node. For instance, in this example,
the reporting node could send a rate based request specifying the the reporting node could send a rate-based request specifying the
maximum transactions per second to be 90. The reacting node will maximum transactions per second to be 90. The reacting node will
send the 90 regardless of whether it is receiving 100 or 1000 service send the 90 regardless of whether it is receiving 100 or 1000 service
requests per second. requests per second.
This document extends the base DOIC solution [RFC7683] to add support This document extends the base DOIC solution [RFC7683] to add support
for the rate based overload abatement algorithm. for the rate based overload abatement algorithm.
This document draws heavily on work in the RIA SIP Overload Control This document draws heavily on work in the SIP Overload Control
working group. The definition of the rate abatement algorithm is working group. The definition of the rate abatement algorithm is
copied almost verbatim from the SOC document [RFC7415], with changes copied almost verbatim from the SOC document [RFC7415], with changes
focused on making the wording consistent with the DOIC solution and focused on making the wording consistent with the DOIC solution and
the Diameter protocol. the Diameter protocol.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diameter Node Diameter Node
A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733 A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733
skipping to change at page 5, line 43 skipping to change at page 5, line 43
There may be local policy reasons that cause a DOIC node that There may be local policy reasons that cause a DOIC node that
supports the rate abatement algorithm to not include it in the OC- supports the rate abatement algorithm to not include it in the OC-
Feature-Vector. All reacting nodes, however, must continue to Feature-Vector. All reacting nodes, however, must continue to
include loss in the OC-Feature-Vector in order to remain compliant include loss in the OC-Feature-Vector in order to remain compliant
with [RFC7683]. with [RFC7683].
A reporting node MAY select one abatement algorithm to apply to host A reporting node MAY select one abatement algorithm to apply to host
and realm reports and a different algorithm to apply to peer reports. and realm reports and a different algorithm to apply to peer reports.
For host or realm reports the selected algorithm is reflected in For host or realm reports the selected algorithm is reflected in
the OC-Feature-Vector AVP sent as part of the OC-Selected-Features the OC-Feature-Vector AVP sent as part of the OC-Supported-
AVP included in answer messages for transaction where the request Features AVP included in answer messages for transaction where the
contained an OC-Supported-Features AVP. This is per the request contained an OC-Supported-Features AVP. This is per the
procedures defined in [RFC7683]. procedures defined in [RFC7683].
For peer reports the selected algorithm is reflected in the OC- For peer reports the selected algorithm is reflected in the OC-
Peer-Algo AVP sent as part of the OC-Supported-Features AVP Peer-Algo AVP sent as part of the OC-Supported-Features AVP
included answer messages for transactions where the request included answer messages for transactions where the request
contained an OC-Supported-Features AVP. This is per the contained an OC-Supported-Features AVP. This is per the
procedures defined in [I-D.ietf-dime-agent-overload]. procedures defined in [I-D.ietf-dime-agent-overload].
Editor's Node: The peer report specification is still under Editor's Node: The peer report specification is still under
development and, as such, the above paragraph is subject to development and, as such, the above paragraph is subject to
skipping to change at page 6, line 18 skipping to change at page 6, line 18
5. Overload Report Handling 5. Overload Report Handling
This section describes any changes to the behavior defined in This section describes any changes to the behavior defined in
[RFC7683] for handling of overload reports when the rate overload [RFC7683] for handling of overload reports when the rate overload
abatement algorithm is used. abatement algorithm is used.
5.1. Reporting Node Overload Control State 5.1. Reporting Node Overload Control State
A reporting node that uses the rate abatement algorithm SHOULD A reporting node that uses the rate abatement algorithm SHOULD
maintain reporting node OCS for each reacting node to which it sends maintain reporting node Overload Control State (OCS) for each
a rate OLR. reacting node to which it sends a rate Overload Report (OLR).
This is different from the behavior defines in [RFC7683] where a This is different from the behavior defined in [RFC7683] where a
single loss percentage sent to all reacting nodes. single loss percentage sent to all reacting nodes.
A reporting node SHOULD maintain OCS entries when using the rate A reporting node SHOULD maintain OCS entries when using the rate
abatement algorithm per supported Diameter application, per targeted abatement algorithm per supported Diameter application, per targeted
reacting node and per report-type. reacting node and per report-type.
A rate OCS entry is identified by the tuple of Application-Id, A rate OCS entry is identified by the tuple of Application-Id,
report-type and DiameterID of the target of the rate OLR. report-type and DiameterID of the target of the rate OLR.
A reporting node that supports the rate abatement algorithm MUST A reporting node that supports the rate abatement algorithm MUST
include the specified rate in the abatement algorithm specific include the rate of its abatement algorithm in the OC-Maximum-Rate
portion of the reporting node rate OCS when sending a rate OLR. AVP when sending a rate OLR.
All other elements for the OCS defined in [RFC7683] and All other elements for the OCS defined in [RFC7683] and
[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
when using the rate abatement algorithm. when using the rate abatement algorithm.
5.2. Reacting Node Overload Control State 5.2. Reacting Node Overload Control State
A reacting node that supports the rate abatement algorithm MUST A reacting node that supports the rate abatement algorithm MUST
indicate rate as the selected abatement algorithm in the reacting indicate rate as the selected abatement algorithm in the reacting
node OCS when receiving a rate OLR. node OCS when receiving a rate OLR.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
the Origin-Host AVP received in the request. the Origin-Host AVP received in the request.
o For Realm reports the target is the DiameterIdentity contained in o For Realm reports the target is the DiameterIdentity contained in
the Origin-Realm AVP received in the request. the Origin-Realm AVP received in the request.
o For Peer reports the target is the DiameterIdentity of the o For Peer reports the target is the DiameterIdentity of the
Diameter Peer from which the request was received. Diameter Peer from which the request was received.
5.4. Reacting Node Maintenance of Overload Control State 5.4. Reacting Node Maintenance of Overload Control State
When receiving an answer message indicating that the reacting node When receiving an answer message indicating that the reporting node
has selected the rate algorithm, a reaction node MUST indicate the has selected the rate algorithm, a reacting node MUST indicate the
rate abatement algorithm in the reacting node OCS entry for the rate abatement algorithm in the reacting node OCS entry for the
reporting node. reporting node.
A reacting node receiving an overload report for the rate abatement A reacting node receiving an overload report for the rate abatement
algorithm MUST save the rate received in the OC-Maximum-Rate AVP algorithm MUST save the rate received in the OC-Maximum-Rate AVP
contained in the OC-OLR AVP in the reacting node OCS entry. contained in the OC-OLR AVP in the reacting node OCS entry.
5.5. Reporting Node Behavior for Rate Abatement Algorithm 5.5. Reporting Node Behavior for Rate Abatement Algorithm
When in an overload condition with rate selected as the overload When in an overload condition with rate selected as the overload
skipping to change at page 8, line 10 skipping to change at page 8, line 10
When sending an overload report for the Rate algorithm, the OC- When sending an overload report for the Rate algorithm, the OC-
Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is
not included. not included.
5.6. Reacting Node Behavior for Rate Abatement Algorithm 5.6. Reacting Node Behavior for Rate Abatement Algorithm
When determining if abatement treatment should be applied to a When determining if abatement treatment should be applied to a
request being sent to a reporting node that has selected the rate request being sent to a reporting node that has selected the rate
overload abatement algorithm, the reacting node MAY use the algorithm overload abatement algorithm, the reacting node MAY use the algorithm
detailed in Section 6. detailed in Section 7.
Note: Other algorithms for controlling the rate can be implemented Note: Other algorithms for controlling the rate can be implemented
by the reacting node as long as they result in the correct rate of by the reacting node as long as they result in the correct rate of
traffic being sent to the reporting node. traffic being sent to the reporting node.
Once a determination is made by the reacting node that an individual Once a determination is made by the reacting node that an individual
Diameter request is to be subjected to abatement treatment then the Diameter request is to be subjected to abatement treatment then the
procedures for throttling and diversion defined in [RFC7683] and procedures for throttling and diversion defined in [RFC7683] and
[I-D.ietf-dime-agent-overload] apply. [I-D.ietf-dime-agent-overload] apply.
skipping to change at page 9, line 10 skipping to change at page 9, line 10
6.2. OC-OLR AVP 6.2. OC-OLR AVP
This extension defines the OC-Maximum-Rate AVP to be an optional part This extension defines the OC-Maximum-Rate AVP to be an optional part
of the OC-OLR AVP. of the OC-OLR AVP.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ OC-Source-ID ] [ SourceID ]
[ OC-Abatement-Algorithm ]
[ OC-Maximum-Rate ] [ OC-Maximum-Rate ]
* [ AVP ] * [ AVP ]
This extension makes no changes to the other AVPs that are part of This extension makes no changes to the other AVPs that are part of
the OC-OLR AVP. the OC-OLR AVP.
This extension does not define new overload report types. The This extension does not define new overload report types. The
existing report types of host and realm defined in [RFC7683] apply to existing report types of host and realm defined in [RFC7683] apply to
the rate control algorithm. The peer report type defined in the rate control algorithm. The peer report type defined in
[I-D.ietf-dime-agent-overload] also applies to the rate control [I-D.ietf-dime-agent-overload] also applies to the rate control
skipping to change at page 9, line 41 skipping to change at page 9, line 40
6.3. Attribute Value Pair flag rules 6.3. Attribute Value Pair flag rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
|OC-Maximum-Rate TBD1 x.x Unsigned64 | | V | |OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V |
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
7. Rate Based Abatement Algorithm 7. Rate Based Abatement Algorithm
This section is pulled from [RFC7415], with minor changes needed to This section is pulled from [RFC7415], with minor changes needed to
make it apply to the Diameter protocol. make it apply to the Diameter protocol.
7.1. Overview 7.1. Overview
The reporting node is the one protected by the overload control The reporting node is the one protected by the overload control
skipping to change at page 10, line 49 skipping to change at page 10, line 49
The reporting node may set the same rate for every reacting node, or The reporting node may set the same rate for every reacting node, or
may set different rates for different reacting node. may set different rates for different reacting node.
The maximum rate determined by the reporting node for a reacting node The maximum rate determined by the reporting node for a reacting node
applies to the entire stream of Diameter requests, even though applies to the entire stream of Diameter requests, even though
abatement may only affect a particular subset of the requests, since abatement may only affect a particular subset of the requests, since
the reacting node might apply priority as part of its decision of the reacting node might apply priority as part of its decision of
which requests to abate. which requests to abate.
When setting the maximum rate for a particular reacting node, the When setting the maximum rate for a particular reacting node, the
reporting node may need take into account the workload (e.g. cpu load reporting node may need take into account the workload (e.g. CPU
per request) of the distribution of message types from that reacting load per request) of the distribution of message types from that
node. Furthermore, because the reacting node may prioritize the reacting node. Furthermore, because the reacting node may prioritize
specific types of messages it sends while under overload restriction, the specific types of messages it sends while under overload
this distribution of message types may be different from the message restriction, this distribution of message types may be different from
distribution for that reacting node under non-overload conditions the message distribution for that reacting node under non-overload
(e.g., either higher or lower cpu load). conditions (e.g., either higher or lower CPU load).
Note that the AVP for the rate algorithm is an upper bound (in Note that the AVP for the rate algorithm is an upper bound (in
request messages per second) on the traffic sent by the reacting node request messages per second) on the traffic sent by the reacting node
to the reporting node. The reacting node may send traffic at a rate to the reporting node. The reacting node may send traffic at a rate
significantly lower than the upper bound, for a variety of reasons. significantly lower than the upper bound, for a variety of reasons.
In other words, when multiple reacting nodes are being controlled by In other words, when multiple reacting nodes are being controlled by
an overloaded reporting node, at any given time some reacting nodes an overloaded reporting node, at any given time some reacting nodes
may receive requests at a rate below its target maximum Diameter may receive requests at a rate below its target maximum Diameter
request rate while others above that target rate. But the resulting request rate while others above that target rate. But the resulting
request rate presented to the overloaded reporting node will converge request rate presented to the overloaded reporting node will converge
towards the target Diameter request rate. towards the target Diameter request rate.
Upon detection of overload, and the determination to invoke overload Upon detection of overload, and the determination to invoke overload
controls, the reporting node MUST follow the specifications in controls, the reporting node MUST follow the specifications in
[draft-ietf-dime-ovli] to notify its clients of the allocated target [RFC7683] to notify its clients of the allocated target maximum
maximum Diameter request rate and to notify them that the rate Diameter request rate and to notify them that the rate overload
overload abatement is in effect. abatement is in effect.
The reporting node MUST use the OC-Maximum-Rate AVP defined in this The reporting node MUST use the OC-Maximum-Rate AVP defined in this
specification to communicate a target maximum Diameter request rate specification to communicate a target maximum Diameter request rate
to each of its clients. to each of its clients.
7.3. Reacting Node Behavior 7.3. Reacting Node Behavior
7.3.1. Default algorithm 7.3.1. Default algorithm
In determining whether or not to transmit a specific message, the In determining whether or not to transmit a specific message, the
skipping to change at page 17, line 37 skipping to change at page 17, line 37
minimum time between admissions is uniformly distributed over minimum time between admissions is uniformly distributed over
[T/2, 3T/2], and the mean time between admissions is the same, [T/2, 3T/2], and the mean time between admissions is the same,
i.e. T+1/R where R is the request arrival rate. i.e. T+1/R where R is the request arrival rate.
o At high load randomization rarely occurs, so there is no loss of o At high load randomization rarely occurs, so there is no loss of
precision of the admitted rate, even though the randomized precision of the admitted rate, even though the randomized
'phasing' of the buckets remains. 'phasing' of the buckets remains.
8. IANA Consideration 8. IANA Consideration
TBD 8.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All
AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry.
8.2. New registries
There are no new IANA registries introduced by this document.
9. Security Considerations 9. Security Considerations
The rate overload abatement mechanism is an extension to the based The rate overload abatement mechanism is an extension to the base
Diameter overload mechanism. As such, all of the security Diameter overload mechanism. As such, all of the security
considerations outlined in [RFC7683] apply to the rate overload considerations outlined in [RFC7683] apply to the rate overload
abatement mechanism. abatement mechanism.
10. Acknowledgements 10. Acknowledgements
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dime-agent-overload] [I-D.ietf-dime-agent-overload]
Donovan, S., "Diameter Agent Overload", draft-ietf-dime- Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-00 (work in progress), December 2014. agent-overload-00 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 18, line 34 skipping to change at page 18, line 39
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <http://www.rfc-editor.org/info/rfc6733>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance", Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015, RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>. <http://www.rfc-editor.org/info/rfc7683>.
11.2. Informative References 11.2. Informative References
[Erramilli]
Erramilli, A. and L. Forys, "Traffic Synchronization
Effects In Teletraffic Systems", 1991.
[RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol [RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol
(SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415, (SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415,
February 2015, <http://www.rfc-editor.org/info/rfc7415>. February 2015, <http://www.rfc-editor.org/info/rfc7415>.
Authors' Addresses Authors' Addresses
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
17210 Campbell Road 17210 Campbell Road
Dallas, Texas 75254 Dallas, Texas 75254
United States United States
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Eric Noel Eric Noel
AT&T Labs AT&T Labs
200s Laurel Avenue 200s Laurel Avenue
Middletown, NJ 07747 Middletown, NJ 07747
United States United States
Email: ecnoel@research.att.com Email: ecnoel@research.att.com
 End of changes. 24 change blocks. 
35 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/