1. Introduction

   While many in the telephony community assume that commercial VoIP
   service in the Internet awaits effective end-to-end QoS, in reality
   voice service over best-effort broadband Internet connections is an
   available service now with growing demand.  While some ISPs deploy
   QoS on their backbones, and some corporate intranets offer end-to-end
   QoS internally, end-to-end QoS is not generally available to
   customers in the current Internet.  Given the current commercial
   interest in VoIP on best-effort media connections, it seems prudent
   to examine the potential effect of real time flows on congestion.  In
   this document, we perform such an analysis.  Note, however, that this
   document is not making any recommendations about deployment paths for
   VoIP in terms of QoS support, and is not claiming that best-effort
   service can be relied upon to give acceptable performance for VoIP.
   This document is also not discussing signalling connections for VoIP.
   However, voice traffic is in fact occasionally deployed as best
   effort traffic over some links in the Internet today, and we expect
   this occasional deployment to continue.  This document expresses our
   concern over the lack of effective end-to-end congestion control for
   this best-effort voice traffic.

   Assuming that VoIP over best-effort Internet connections continues to
   gain popularity among consumers with broadband connections, the
   deployment of end-to-end QoS mechanisms in public ISPs may be slow.
   The IETF has developed standards for QoS mechanisms in the Internet
   [DIFFSERV, RSVP] and continues to be active in this area [NSIS, COPS].
   However, the deployment of technologies requiring change to the
   Internet infrastructure is subject to a wide range of commercial as

   well as technical considerations, and technologies that can be
   deployed without changes to the infrastructure enjoy considerable
   advantages in the speed of deployment.  RFC 2990 outlines some of the
   technical challenges to the deployment of QoS architectures in the
   Internet [RFC2990].  Often, interim measures that provide support for
   fast-growing applications are adopted, and are successful enough at
   meeting the need that the pressure for a ubiquitous deployment of the
   more disruptive technologies is reduced.  There are many examples of
   the slow deployment of infrastructure that are similar to the slow
   deployment of QoS mechanisms, including IPv6, IP multicast, or of a
   global PKI for IKE and IPsec support.

   Interim QoS measures that can be deployed most easily include
   single-hop or edge-only QoS mechanisms for VoIP traffic on individual
   congested links, such as edge-only QoS mechanisms for cable access
   networks.  Such local forms of QoS could be quite successful in
   protecting some fraction of best-effort VoIP traffic from congestion.
   However, these local forms of QoS are not directly visible to the
   end-to-end VoIP connection.  A best-effort VoIP connection could
   experience high end-to-end packet drop rates, and be competing with
   other best-effort traffic, even if some of the links along the path
   might have single-hop QoS mechanisms.

   The deployment of IP telephony is likely to include best-effort
   broadband connections to public-access networks, in addition to other
   deployment scenarios of dedicated IP networks, or as an alternative
   to band splitting on the last mile of ADSL deployments or QoS
   mechanisms on cable access networks.  There already exists a
   rapidly-expanding deployment of VoIP services intended to operate
   over residential broadband access links (e.g., [FWD, Vonage]).  At
   the moment, many public-access IP networks are uncongested in the
   core, with low or moderate levels of link utilization, but this is
   not necessarily the case on last hop links.  If an IP telephony call
   runs completely over the Internet, the connection could easily
   traverse congested links on both ends.  Because of economic factors,
   the growth rate of Internet telephony is likely to be greatest in
   developing countries, where core links are more likely to be
   congested, making congestion control an especially important topic
   for developing countries.

   Given the possible deployment of IP telephony over congested best-
   effort networks, some concerns arise about the possibilities of
   congestion collapse due to a rapid growth in real-time voice traffic
   that does not practice end-to-end congestion control.  This document
   raises some concerns about fairness, user quality, and the danger of
   congestion collapse that would arise from a rapid growth in best-
   effort telephony traffic on best-effort networks.  We consider best-
   effort telephony connections that have a minimum sending rate and

   that compete directly with other best-effort traffic on a path with
   at least one congested link, and address the specific question of
   whether such traffic should be required to terminate, or to suspend
   sending temporarily, in the face of a persistent, high packet drop
   rate, when reducing the sending rate is not a viable alternative.

   The concerns in this document about fairness and the danger of
   congestion collapse apply not only to telephony traffic, but also to
   video traffic and other best-effort real-time traffic with a minimum
   sending rate.  RFC 2914 already makes the point that best-effort
   traffic requires end-to-end congestion control [RFC2914].  Because
   audio traffic sends at such a low rate, relative to video and other
   real-time traffic, it is sometimes claimed that audio traffic doesn't
   require end-to-end congestion control.  Thus, while the concerns in
   this document are general, the document focuses on the particular
   issue of best-effort audio traffic.

   Feedback can be sent to the IAB mailing list at iab@ietf.org, or to
   the editors at floyd@icir.org and kempf@docomolabs-usa.com.  Feedback
   can also be sent to the end2end-interest mailing list [E2E].