Henning Schulzrinne | Columbia University (original) (raw)

Papers by Henning Schulzrinne

When a large number of clients register with a SIP registrar server at approximately the same tim... more When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Register-Restart header in registration responses. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Register-Restart header value before sending out the first registration attempt. Thus, the mechanism spreads all the initial client registration requests and prevents them from overloading the registrar server. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at Shen, et al.

This document specifies an Internet standards track protocol for the Internet community, and requ... more This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. 1. Terminology DHCP client: A DHCP [1] client is an Internet host that uses DHCP to obtain configuration parameters such as a network address. DHCP server: A DHCP server is an Internet host that returns configuration parameters t...

Status of this Memo This document specifies an Internet standards track protocol for the Internet... more Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards ” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) The Internet Society (2002). All Rights Reserved. This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.

ArXiv, 2008

Voice Service Providers (VSPs) participating in VoIP peering frequently want to withhold their id... more Voice Service Providers (VSPs) participating in VoIP peering frequently want to withhold their identity and related privacy-sensitive information from other parties during the VoIP communication. A number of existing documents on VoIP privacy exist, but most of them focus on end user privacy. By summarizing and extending existing work, we present a unified privacy mechanism for both VoIP users and service providers. We also show a case study on how VSPs can use this mechanism for identity and topology hiding in VoIP peering.

A SIP server may be overloaded by emergency-induced call volume, “American Idol” style flash crow... more A SIP server may be overloaded by emergency-induced call volume, “American Idol” style flash crowd effects or denial of service attacks. The SIP server overload problem is interesting especially because the cost of serving and rejecting a SIP session could be in the same neighborhood. For this reason, the built-in SIP overload control mechanism based on generating rejection messages could not prevent the server from entering congestion collapse at heavy load. The SIP overload problem calls for a pushback control solution in which the potentially overloaded receiving server may notify its upstream sending servers to have them send only the amount of load within the receiving server’s processing capacity. The pushback framework can be achieved by SIP application layer rate-based feedback or window-based feedback. We propose three new window-based feedback algorithms and evaluate them together with two existing rate-based feedback algorithms. We compare the different algorithms in term...

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated s... more This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833.

Workshop on End-to-End Monitoring Techniques and Services, 2005.

A Next Step In Signaling (NSIS) protocol is currently under standardization by the Internet Engin... more A Next Step In Signaling (NSIS) protocol is currently under standardization by the Internet Engineering Task Force (IETF) to support various applications that need to manipulate control information along the flow path. This paper addresses the NSIS protocol and IP routing interaction problem. We conducted routing measurement experiments to characterize the current Internet path dynamics, and discussed the impact of the observations on NSIS protocol design. The focus of our study is route change. We introduce NSISaffecting route changes and define them in typical NSIS deployment models. With the NSIS deployment models in mind, we evaluate the simple packet TTL monitoring route change detection method. Finally, we propose a new route change detection method based on one-way-delay monitoring and provide preliminary evaluation.

2007 IEEE International Conference on Communications, 2007

ENUM is a protocol standard developed by the Internet Engineering Task Force (IETF) for translati... more ENUM is a protocol standard developed by the Internet Engineering Task Force (IETF) for translating the E.164 phone numbers into Internet Universal Resource Identifiers (URIs). It plays an increasingly important role as the bridge between Internet and traditional telecommunications services. ENUM is based on the Domain Name System (DNS), but places unique performance requirements on DNS server. In particular, ENUM server needs to host a huge number of records, provide high query throughput for both existing and non-existing records in the server, maintain high query performance under update load, and answer queries within a tight latency budget. In this report, we evaluate and compare performance of serving ENUM queries by three servers, namely BIND, PDNS and Navitas. Our objective is to answer whether and how these servers can meet the unique performance requirements of ENUM. Test results show that the ENUM query response time on our platform has always been on the order of a few milliseconds or less, so this is likely not a concern. Throughput then becomes the key. The throughput of BIND degrades linearly as the record set size grows, so BIND is not suitable for ENUM. PDNS delivers higher performance than BIND in most cases, while the commercial Navitas server presents even better ENUM performance than PDNS. Under our 5M-record set test, Navitas server with its default configuration consumes one tenth to one sixth the memory of PDNS, achieves six times higher throughput for existing records and an order of two magnitudes higher throughput for non-existing records than the bottom line PDNS server without caching. The throughput of Navitas is also the highest among the tested servers when the database is being updated in the background. We investigated ways to improve PDNS performance. For example, doubling CPU processing power by putting PDNS and its backend database in two separate machines can increase PDNS throughput for existing records by 45% and that for nonexisting records by 40%. Since PDNS is open source, we also instrumented the source code to obtain a detailed profile of contributions of various systems components to the overall latency. We found that when the server is within its normal load range, the main component of server processing latency is caused by backend database lookup operations. Excessive number of backend database lookups is the reason that makes PDNS throughput for non-existing records its key weakness. We studied using PDNS caching to reduce the number of database lookups. With a full packet cache and a modified cache maintenance mechanism, the PDNS throughput for existing records can be improved by 100%. This brings the value to one third of its Navitas counterpart. After enabling the PDNS negative query cache, we improved PDNS throughput for non-existing records to the level comparable to its throughput for existing records, but this result is still an order of magnitude lower than the corresponding value in Navitas. Further improvements of PDNS throughput for non-existing records will require optimization of related processing mechanism in its implementation.

Principles, Systems and Applications of IP Telecommunications. Services and Security for Next Generation Networks, 2008

A Session Initiation Protocol (SIP) server may be overloaded by emergency-induced call volume, "A... more A Session Initiation Protocol (SIP) server may be overloaded by emergency-induced call volume, "American Idol" style flash crowd effects or denial of service attacks. The SIP server overload problem is interesting especially because the costs of serving or rejecting a SIP session can be similar. For this reason, the built-in SIP overload control mechanism based on generating rejection messages cannot prevent the server from entering congestion collapse under heavy load. The SIP overload problem calls for a pushback control solution in which the potentially overloaded receiving server may notify its upstream sending servers to have them send only the amount of load within the receiving server's processing capacity. The pushback framework can be achieved by either a rate-based feedback or a window-based feedback. The centerpiece of the feedback mechanism is the algorithm used to generate load regulation information. We propose three new window-based feedback algorithms and evaluate them together with two existing rate-based feedback algorithms. We compare the different algorithms in terms of the number of tuning parameters and performance under both steady and variable load. Furthermore, we identify two categories of fairness requirements for SIP overload control, namely, user-centric and provider-centric fairness. With the introduction of a new double-feed SIP overload control architecture, we show how the algorithms can meet those fairness criteria.

Status of This Memo This document specifies an Internet standards track protocol for the Internet... more Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Lecture Notes in Computer Science, 2002

ABSTRACT

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a va... more Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes.

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a d... more NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5979.

This specification defines a load-control event package for the Session Initiation Protocol (SIP)... more This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7200.

Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops (PerComW'07), 2007

ABSTRACT

IEEE Globecom 2006, 2006

ABSTRACT

Principles, Systems and Applications of IP Telecommunications on - IPTComm '10, 2010

The Session Initiation Protocol (SIP) server overload management has attracted interest since SIP... more The Session Initiation Protocol (SIP) server overload management has attracted interest since SIP is being widely deployed in the Next Generation Networks (NGN) as a core signaling protocol. Yet all existing SIP overload control work is focused on SIP-over-UDP, despite the fact that TCP is increasingly seen as the more viable choice of SIP transport. This paper answers the following questions: is the existing TCP flow control capable of handling the SIP overload problem? If not, why and how can we make it work? We provide a comprehensive explanation of the default SIP-over-TCP overload behavior through server instrumentation. We also propose and implement novel but simple overload control algorithms without any kernel or protocol level modification. Experimental evaluation shows that with our mechanism the overload performance improves from its original zero throughput to nearly full capacity. Our work leads to the important general insight that the traditional notion of TCP flow control alone is incapable of managing overload for time-critical session-based applications, which would be applicable not only to SIP, but also to a wide range of other common applications such as database servers.

IP Multimedia Concepts and Services, 2006

When a large number of clients register with a SIP registrar server at approximately the same tim... more When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Register-Restart header in registration responses. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Register-Restart header value before sending out the first registration attempt. Thus, the mechanism spreads all the initial client registration requests and prevents them from overloading the registrar server. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at Shen, et al.

This document specifies an Internet standards track protocol for the Internet community, and requ... more This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. 1. Terminology DHCP client: A DHCP [1] client is an Internet host that uses DHCP to obtain configuration parameters such as a network address. DHCP server: A DHCP server is an Internet host that returns configuration parameters t...

Status of this Memo This document specifies an Internet standards track protocol for the Internet... more Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards ” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) The Internet Society (2002). All Rights Reserved. This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.

ArXiv, 2008

Voice Service Providers (VSPs) participating in VoIP peering frequently want to withhold their id... more Voice Service Providers (VSPs) participating in VoIP peering frequently want to withhold their identity and related privacy-sensitive information from other parties during the VoIP communication. A number of existing documents on VoIP privacy exist, but most of them focus on end user privacy. By summarizing and extending existing work, we present a unified privacy mechanism for both VoIP users and service providers. We also show a case study on how VSPs can use this mechanism for identity and topology hiding in VoIP peering.

A SIP server may be overloaded by emergency-induced call volume, “American Idol” style flash crow... more A SIP server may be overloaded by emergency-induced call volume, “American Idol” style flash crowd effects or denial of service attacks. The SIP server overload problem is interesting especially because the cost of serving and rejecting a SIP session could be in the same neighborhood. For this reason, the built-in SIP overload control mechanism based on generating rejection messages could not prevent the server from entering congestion collapse at heavy load. The SIP overload problem calls for a pushback control solution in which the potentially overloaded receiving server may notify its upstream sending servers to have them send only the amount of load within the receiving server’s processing capacity. The pushback framework can be achieved by SIP application layer rate-based feedback or window-based feedback. We propose three new window-based feedback algorithms and evaluate them together with two existing rate-based feedback algorithms. We compare the different algorithms in term...

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated s... more This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833.

Workshop on End-to-End Monitoring Techniques and Services, 2005.

A Next Step In Signaling (NSIS) protocol is currently under standardization by the Internet Engin... more A Next Step In Signaling (NSIS) protocol is currently under standardization by the Internet Engineering Task Force (IETF) to support various applications that need to manipulate control information along the flow path. This paper addresses the NSIS protocol and IP routing interaction problem. We conducted routing measurement experiments to characterize the current Internet path dynamics, and discussed the impact of the observations on NSIS protocol design. The focus of our study is route change. We introduce NSISaffecting route changes and define them in typical NSIS deployment models. With the NSIS deployment models in mind, we evaluate the simple packet TTL monitoring route change detection method. Finally, we propose a new route change detection method based on one-way-delay monitoring and provide preliminary evaluation.

2007 IEEE International Conference on Communications, 2007

ENUM is a protocol standard developed by the Internet Engineering Task Force (IETF) for translati... more ENUM is a protocol standard developed by the Internet Engineering Task Force (IETF) for translating the E.164 phone numbers into Internet Universal Resource Identifiers (URIs). It plays an increasingly important role as the bridge between Internet and traditional telecommunications services. ENUM is based on the Domain Name System (DNS), but places unique performance requirements on DNS server. In particular, ENUM server needs to host a huge number of records, provide high query throughput for both existing and non-existing records in the server, maintain high query performance under update load, and answer queries within a tight latency budget. In this report, we evaluate and compare performance of serving ENUM queries by three servers, namely BIND, PDNS and Navitas. Our objective is to answer whether and how these servers can meet the unique performance requirements of ENUM. Test results show that the ENUM query response time on our platform has always been on the order of a few milliseconds or less, so this is likely not a concern. Throughput then becomes the key. The throughput of BIND degrades linearly as the record set size grows, so BIND is not suitable for ENUM. PDNS delivers higher performance than BIND in most cases, while the commercial Navitas server presents even better ENUM performance than PDNS. Under our 5M-record set test, Navitas server with its default configuration consumes one tenth to one sixth the memory of PDNS, achieves six times higher throughput for existing records and an order of two magnitudes higher throughput for non-existing records than the bottom line PDNS server without caching. The throughput of Navitas is also the highest among the tested servers when the database is being updated in the background. We investigated ways to improve PDNS performance. For example, doubling CPU processing power by putting PDNS and its backend database in two separate machines can increase PDNS throughput for existing records by 45% and that for nonexisting records by 40%. Since PDNS is open source, we also instrumented the source code to obtain a detailed profile of contributions of various systems components to the overall latency. We found that when the server is within its normal load range, the main component of server processing latency is caused by backend database lookup operations. Excessive number of backend database lookups is the reason that makes PDNS throughput for non-existing records its key weakness. We studied using PDNS caching to reduce the number of database lookups. With a full packet cache and a modified cache maintenance mechanism, the PDNS throughput for existing records can be improved by 100%. This brings the value to one third of its Navitas counterpart. After enabling the PDNS negative query cache, we improved PDNS throughput for non-existing records to the level comparable to its throughput for existing records, but this result is still an order of magnitude lower than the corresponding value in Navitas. Further improvements of PDNS throughput for non-existing records will require optimization of related processing mechanism in its implementation.

Principles, Systems and Applications of IP Telecommunications. Services and Security for Next Generation Networks, 2008

A Session Initiation Protocol (SIP) server may be overloaded by emergency-induced call volume, "A... more A Session Initiation Protocol (SIP) server may be overloaded by emergency-induced call volume, "American Idol" style flash crowd effects or denial of service attacks. The SIP server overload problem is interesting especially because the costs of serving or rejecting a SIP session can be similar. For this reason, the built-in SIP overload control mechanism based on generating rejection messages cannot prevent the server from entering congestion collapse under heavy load. The SIP overload problem calls for a pushback control solution in which the potentially overloaded receiving server may notify its upstream sending servers to have them send only the amount of load within the receiving server's processing capacity. The pushback framework can be achieved by either a rate-based feedback or a window-based feedback. The centerpiece of the feedback mechanism is the algorithm used to generate load regulation information. We propose three new window-based feedback algorithms and evaluate them together with two existing rate-based feedback algorithms. We compare the different algorithms in terms of the number of tuning parameters and performance under both steady and variable load. Furthermore, we identify two categories of fairness requirements for SIP overload control, namely, user-centric and provider-centric fairness. With the introduction of a new double-feed SIP overload control architecture, we show how the algorithms can meet those fairness criteria.

Status of This Memo This document specifies an Internet standards track protocol for the Internet... more Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Lecture Notes in Computer Science, 2002

ABSTRACT

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a va... more Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes.

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a d... more NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5979.

This specification defines a load-control event package for the Session Initiation Protocol (SIP)... more This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7200.

Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops (PerComW'07), 2007

ABSTRACT

IEEE Globecom 2006, 2006

ABSTRACT

Principles, Systems and Applications of IP Telecommunications on - IPTComm '10, 2010

The Session Initiation Protocol (SIP) server overload management has attracted interest since SIP... more The Session Initiation Protocol (SIP) server overload management has attracted interest since SIP is being widely deployed in the Next Generation Networks (NGN) as a core signaling protocol. Yet all existing SIP overload control work is focused on SIP-over-UDP, despite the fact that TCP is increasingly seen as the more viable choice of SIP transport. This paper answers the following questions: is the existing TCP flow control capable of handling the SIP overload problem? If not, why and how can we make it work? We provide a comprehensive explanation of the default SIP-over-TCP overload behavior through server instrumentation. We also propose and implement novel but simple overload control algorithms without any kernel or protocol level modification. Experimental evaluation shows that with our mechanism the overload performance improves from its original zero throughput to nearly full capacity. Our work leads to the important general insight that the traditional notion of TCP flow control alone is incapable of managing overload for time-critical session-based applications, which would be applicable not only to SIP, but also to a wide range of other common applications such as database servers.

IP Multimedia Concepts and Services, 2006