Network Working Group S. Floyd, Ed.
Request for Comments: 3714 J. Kempf, Ed.
Category: Informational March 2004
IAB Concerns Regarding Congestion Control for
Voice Traffic in the Internet
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic.
この文書は、インターネットでのベストエフォート型の音声トラフィックのための効果的なエンド・ツー・エンドの輻輳制御に関するIABの懸念を説明します。これらの懸念は、公平性、ユーザーの品質で、かつ輻輳崩壊の危険性としなければなりません。懸念は、サービス（QoS）のインターネットでの展開、そしてこの状況は短期的にはあまり変化しないという可能性の広範な品質の不在の光に特に関連します。この文書では、QoSサポートの面で、インターネットプロトコル（VoIP）ボイスオーバーの配備パスに関するいかなる勧告を行うされていない、とベストエフォート型サービスは、VoIPのための許容可能な性能を与えるために頼ることができると主張されていません。私たちは、単にその音声トラフィックが時折、我々はこの時折展開が継続することを期待することを、私たちは、このための効果的なエンドツーエンドの輻輳制御の欠如に懸念を持っていることを、インターネットでいくつかのリンク上などのベストエフォート型トラフィックを展開されている観察していますベストエフォート型の音声トラフィック。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. An Example of the Potential for Trouble. . . . . . . . . . . . 4
3. Why are Persistent, High Drop Rates a Problem? . . . . . . . . 6
3.1. Congestion Collapse. . . . . . . . . . . . . . . . . . . 6
3.2. User Quality . . . . . . . . . . . . . . . . . . . . . . 7
3.3. The Amorphous Problem of Fairness. . . . . . . . . . . . 8
4. Current efforts in the IETF. . . . . . . . . . . . . . . . . . 10
4.1. RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Adaptive Rate Audio Codecs . . . . . . . . . . . . . . . 12
4.5. Differentiated Services and Related Topics . . . . . . . 13
5. Assessing Minimum Acceptable Sending Rates . . . . . . . . . . 13
5.1. Drop Rates at 4.75 kbps Minimum Sending Rate . . . . . . 17
5.2. Drop Rates at 64 kbps Minimum Sending Rate . . . . . . . 18
5.3. Open Issues. . . . . . . . . . . . . . . . . . . . . . . 18
5.4. A Simple Heuristic . . . . . . . . . . . . . . . . . . . 19
6. Constraints on VoIP Systems . . . . . . . . . . . . . . . . . . 20
7. Conclusions and Recommendations. . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
10. Appendix - Sending Rates with Packet Drops . . . . . . . . . . 26
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
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.
テレフォニーコミュニティの多くは、インターネットの商業のVoIPサービスはベストエフォート型のブロードバンドインターネット接続を介して現実音声サービスでは、効果的なエンド・ツー・エンドのQoSを待っていることを前提としながら、利用可能なサービスは、需要の高まりとなりました。いくつかのISPが彼らのバックボーン上でQoSを展開し、いくつかの企業のイントラネットは、内部的にエンドツーエンドのQoSを提供していますが、エンド・ツー・エンドのQoSは、現在のインターネットで顧客に一般的に使用できません。ベストエフォート型のメディア接続上のVoIPの現在の商業的関心を考えると、リアルタイムの潜在的な影響は、混雑を流れる検討することが賢明と思われます。この文書では、我々は、このような分析を行います。このドキュメントは、QoSサポートの面でのVoIPの展開パスに関するいかなる勧告を行うされていない、とベストエフォート型サービスは、VoIPのための許容可能な性能を与えるために頼ることができると主張されていないこと、しかし、注意してください。この文書はまた、VoIPのためのシグナリング接続を議論されていません。しかし、音声トラフィックは、実際には時折、今日のインターネットでいくつかのリンク上でベストエフォートトラフィックとして展開されており、我々はこの時折展開が続くと予想します。この文書では、ベストエフォート型の音声トラフィックのための効果的なエンドツーエンドの輻輳制御の欠如を超える私たちの懸念を表明します。
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.
ブロードバンド接続と消費者の間で人気を獲得し続けてVoIPはベストエフォート型のインターネット接続を介して、公共のISPでのエンドツーエンドのQoSメカニズムの展開が遅くなる可能性があると仮定すると。 IETFはインターネット[DIFFSERV、RSVP]におけるQoSメカニズムの規格を開発し、この領域[NSIS、COPS]でアクティブであり続けています。しかし、インターネットインフラストラクチャへの変更を必要とする技術の展開は、市販の広い範囲だけでなく、技術的な検討事項の対象となり、インフラを変更することなく展開することができる技術は、展開の速さにかなりの利点を享受します。 RFC 2990は、インターネット[RFC2990]でのQoSアーキテクチャの展開に技術的な課題のいくつかを概説します。多くの場合、急成長中のアプリケーションのサポートを提供する暫定措置を採用し、より破壊的技術のユビキタス展開するための圧力が低下していることの必要性を満たすには十分成功しているされています。 IPv6の、IPマルチキャスト、またはIKEおよびIPsecのサポートのためのグローバルなPKIのを含むQoSメカニズム、の遅い展開に類似しているインフラの遅い展開の多くの例があります。
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.
最も簡単に展開できる暫定QoSの対策は、シングルホップまたは、このようなエッジのみのケーブルアクセスネットワークのためのQoSメカニズムなどの個々の輻輳したリンク、上のVoIPトラフィックのためのエッジのみのQoSメカニズムが含まれます。 QoSのような局所的なフォームが混雑からベストエフォート型のVoIPトラフィックのいくつかの部分を保護する上で非常に成功した可能性があります。しかし、QoSのこれらの局所的な形式は、エンドツーエンドのVoIP接続に直接表示されません。 Aベストエフォート型のVoIP接続は、パスに沿ったリンクの一部は、シングルホップのQoSメカニズムを持っている可能性がある場合でも、高いエンドツーエンドのパケットドロップ率を体験することができ、およびその他のベストエフォートトラフィックと競合します。
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.
IPテレフォニーの展開は、専用のIPネットワークの他の展開シナリオに加えて、またはケーブル上のADSLの導入やQoSメカニズムのラストマイルの帯域分割の代替として、パブリック・アクセス・ネットワークへのベストエフォート型のブロードバンド接続を含まれている可能性が高いですアクセスネットワーク。すでに家庭用ブロードバンドアクセスリンク上で動作することを意図VoIPサービスの急速に拡大する展開が存在する（例えば、[FWD、Vonageの]）。現時点では、多くの公共アクセスIPネットワークは、リンク使用率の低いまたは中程度のレベルで、コアに非輻輳しているが、これは必ずしも最終ホップリンク上のケースではありません。 IPテレフォニーコールは、インターネット上で完全に実行されている場合は、接続が簡単に両端の混雑リンクを通過する可能性があります。そのため、経済的要因のため、インターネット電話の成長率は、輻輳が途上国にとって特に重要なトピックを制御すること、コアリンクが混雑する可能性が高い発展途上国で最大である可能性が高いです。
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.
混雑してベストエフォート型のネットワーク上でIPテレフォニーの有効な配置を考えると、いくつかの懸念は、エンドツーエンドの輻輳制御を練習していないリアルタイムの音声トラフィックの急増に伴う輻輳崩壊の可能性について生じます。この文書では、公平性、ユーザーの品質、及びベストエフォート型のネットワーク上のベストエフォート型テレフォニートラフィックの急増から生じるであろう輻輳崩壊の危険性についていくつかの懸念を提起します。私たちは、最小送信レートを持っており、それは少なくとも一つの混雑リンクを含むパス上の他のベストエフォートトラフィックと直接競合し、そのようなトラフィックが終了するように要求されるべきかどうかの特定の問題に取り組む、またはそれにベストエフォート型テレフォニー接続を考えます送信レートを低減することが実行可能な代替でない場合、永続的な、高いパケット損失率に直面して、一時的に送信を一時停止します。
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.
公正性については、この文書の懸念や輻輳崩壊の危険性が最小送信レートとテレフォニートラフィックに、だけでなく、ベストエフォートリアルタイムトラフィックビデオトラフィックに及び他のではないだけに適用されます。 RFC 2914は、既にベストエフォート型トラフィックは、エンドツーエンドの輻輳制御[RFC2914]を必要とするポイントになります。オーディオトラフィックは、ビデオおよび他のリアルタイムトラフィックに対するこのような低レートで送信するので、時々、音声トラフィックは、エンドツーエンドの輻輳制御を必要としないことを主張しています。この文書に記載されている懸念が一般的ですしつつ、文書には、ベストエフォート型のオーディオトラフィックの特定の問題に焦点を当てています。
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].
フィードバックはiab@ietf.orgでIABメーリングリストへの、またはfloyd@icir.orgとkempf@docomolabs-usa.comの編集者に送信することができます。フィードバックもend2end金利メーリングリスト[E2E]に送信することができます。
At the November, 2002, IEPREP Working Group meeting in Atlanta, a brief demonstration was made of VoIP over a shared link between a hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya. The link ran over the typical uncongested Internet backbone and access links to peering points between either endpoint and the Internet backbone. The voice quality on the call was very good, especially in comparison to the typical quality obtained by a circuit-switched call with Nairobi. A presentation that accompanied the demonstration described the access links (e.g., DSL, T1, T3, dialup, and cable modem links) as the primary source of network congestion, and described VoIP traffic as being a very small percentage of the packets in commercial ISP traffic [A02]. The presentation further stated that VoIP received good quality in the presence of packet drop rates of 5-40% [AUT]. The VoIP call used an ITU-T G.711 codec, plus proprietary FEC encoding, plus RTP/UDP/IP framing. The resulting traffic load over the Internet was substantially more than the 64 kbps required by the codec. The primary congestion point along the path of the demonstration was a 128 kbps access link between an ISP in Kenya and several of its subscribers in Nairobi. So the single VoIP call consumed more than half of the access link capacity, capacity that is shared across several different users.
2002年11月、アトランタのIEPREPワーキンググループの会合では、簡単なデモは、アトランタ、ジョージア州、米国、およびナイロビ、ケニアのホテルの部屋の間の共有リンク上のVoIPで作られました。リンクは、エンドポイントとインターネットバックボーンのいずれかの間でポイントをピアリングに、典型的な非輻輳インターネットバックボーンとアクセスリンクの上に走りました。コールの音声品質が特にナイロビでの回線交換呼によって得られた典型的な品質と比較して、非常に良好でした。デモンストレーションを伴うプレゼンテーションは、ネットワークの混雑の主要なソースとしてアクセスリンク（例えば、DSL、T1、T3、ダイヤルアップ、およびケーブルモデムのリンク）を説明し、商用ISPにパケットの非常に小さな割合であるとしてVoIPトラフィックを説明しましたトラフィック[A02]。プレゼンテーションでは、さらにVoIPは5から40パーセント[AUT]のパケットドロップ率の存在下で、良い品質を受けたと述べました。 VoIPコールは、ITU-T G.711コーデックを使用し、プラス独自のFEC符号化に加え、RTP / UDP / IPフレーミング。インターネット上で得られたトラフィック負荷は、コーデックによって必要と64kbpsのより実質的でした。デモのパスに沿って主要渋滞ポイントはケニアのISPとナイロビでその加入者のいくつかの間に128 kbpsのアクセスリンクでした。だから、単一のVoIPコールは、より多くの、いくつかの異なるユーザー間で共有されているアクセスリンク容量、容量の半分以上を消費していました。
Note that this network configuration is not a particularly good one for VoIP. In particular, if there are data services running TCP on the link with a typical packet size of 1500 bytes, then some voice packets could be delayed an additional 90 ms, which might cause an increase in the end to end delay above the ITU-recommended time of 150 ms [G.114] for speech traffic. This would result in a delay noticeable to users, with an increased variation in delay, and therefore in call quality, as the bursty TCP traffic comes and goes. For a call that already had high delay, such as the Nairobi call from the previous paragraph, the increased jitter due to competing TCP traffic also increases the requirements on the jitter buffer at the receiver. Nevertheless, VoIP usage over congested best-effort links is likely to increase in the near future, regardless of VoIP's superior performance with "carrier class" service. A best-effort VoIP connection that persists in sending packets at 64 Kbps, consuming half of a 128 Kbps access link, in the face of a drop rate of 40%, with the resulting user-perceptible degradation in voice quality, is not behaving in a way that serves the interests of either the VoIP users or the other concurrent users of the network.
このネットワーク構成は、VoIPのために特に良いものではないことに注意してください。具体的には、1500バイトの典型的なパケットサイズを持つリンク上でTCPを実行しているデータサービスがある場合は、その後、いくつかの音声パケットは、ITU-推奨以上の遅延をエンドツーエンドの増加を引き起こす可能性がある追加の90ミリ秒を、遅らせることができ音声トラフィックのために150ミリ秒[G.114]の時間。バースト性のTCPトラフィックが来て、行くようにこれは、遅延の増加変動と、ユーザーに目立つので、通話品質の遅れにつながります。すでに前の段落からナイロビ呼び出しとして、高遅延していたコールの場合、原因競合するTCPトラフィックにジッタの増加はまた、受信機におけるジッタバッファの要件が増加します。それにも関わらず、混雑ベストエフォート型リンク上のVoIPの使用量にかかわらず、「キャリアクラス」サービスでのVoIPの優れた性能の、近い将来増加する可能性があります。 A音声品質の結果として、ユーザー知覚低下し、40％の低下率に直面して、64 Kbpsでパケットを送信する128 Kbpsのアクセスリンクの半分を消費して持続するベストエフォート型のVoIP接続で動作していませんVoIPユーザまたはネットワークの他の同時ユーザーのいずれかの利益を提供しています方法。
As the Nairobi connection demonstrates, prescribing universal overprovisioning (or more precisely, provisioning sufficient to avoid persistent congestion) as the solution to the problem is not an acceptable generic solution. For example, in regions of the world where circuit-switched telephone service is poor and expensive, and Internet access is possible and lower cost, provisioning all Internet links to avoid congestion is likely to be impractical or impossible.
ナイロビの接続が示すように、ユニバーサルオーバープロビジョニングを処方する（またはより正確には、持続的な輻輳を回避するのに十分なプロビジョニング）問題への解決策としては、許容可能な汎用的なソリューションではありません。例えば、世界の地域における回線交換電話サービスが悪いと高価であり、およびインターネットアクセスは、混雑を避けるために、すべてのインターネットリンクをプロビジョニングすることは非現実的または不可能である可能性が高い、可能かつ低コストです。
In particular, an over-provisioned core is not by itself sufficient to avoid congestion collapse all the way along the path, because an over-provisioned core can not address the common problem of congestion on the access links. Many access links routinely suffer from congestion. It is important to avoid congestion collapse along the entire end-to-end path, including along the access links (where congestion collapse would consist of congested access links wasting scarce bandwidth carrying packets that will only be dropped downstream). So an over-provisioned core does not by itself eliminate or reduce the need for end-to-end congestion avoidance and control.
オーバープロビジョニングコアは、アクセスリンク上の混雑の共通の問題に対処することはできませんので、特に、オーバープロビジョニングコアは、それ自体ですべての道の経路に沿って混雑崩壊を回避するのに十分ではありません。多くのアクセスリンクは定期渋滞に苦しみます。 （輻輳崩壊だけ下流ドロップされるパケットを運ぶ希少な帯域幅を浪費混雑アクセスリンクで構成されます）アクセスリンクに沿っ含め、全体のエンド・ツー・エンドの経路に沿って混雑崩壊を回避することが重要です。だから、オーバープロビジョニングされたコアは、それ自体でエンドツーエンドの輻輳回避とコントロールの必要性を排除または低減していません。
There are two possible mechanisms for avoiding this congestion collapse: call rejection during busy periods, or the use of end-to-end congestion control. Because there are currently no acceptance/rejection mechanisms for best-effort traffic in the Internet, the only alternative is the use of end-to-end congestion control. This is important even if end-to-end congestion control is invoked only in those very rare scenarios with congestion in generally-uncongested access links or networks. There will always be occasional periods of high demand, e.g., in the two hours after an earthquake or other disaster, and this is exactly when it is important to avoid congestion collapse.
忙しい時間帯に拒絶反応を呼び出す、またはエンドツーエンドの輻輳制御の使用：2つの可能なこの輻輳崩壊を回避するためのメカニズムがあります。現在、インターネットでのベストエフォート型トラフィックのための受け入れ/拒否の仕組みがないため、唯一の選択肢は、エンドツーエンドの輻輳制御を使用することです。これは、エンドツーエンドの輻輳制御だけ一般的に、非輻輳アクセスリンクやネットワークの混雑を持つものは非常にまれなシナリオで呼び出された場合にも重要です。そこは常に地震などの災害後2時間で、例えば、高い需要の臨時の期間も、輻輳崩壊を回避することが重要であるとき、これは正確になります。
Best-effort traffic in the Internet does not include mechanisms for call acceptance or rejection. Instead, a best-effort network itself is largely neutral in terms of resource management, and the interaction of the applications' transport sessions mutually regulates network resources in a reasonably fair fashion. One way to bring voice into the best-effort environment in a non-disruptive manner is to focus on the codec and look at rate adaptation measures that can successfully interoperate with existing transport protocols (e.g., TCP), while at the same time preserving the integrity of a real-time, analog voice signal; another way is to consider codecs with fixed sending rates. Whether the codec has a fixed or variable sending rate, we consider the appropriate response when the codec is at its minimum data rate, and the packet drop rate experienced by the flow remains high. This is the key issue addressed in this document.
インターネットのベストエフォート型トラフィックは、呼受付または拒否するためのメカニズムが含まれていません。代わりに、ベストエフォート型のネットワーク自体が資源管理の観点から、主に中性であり、アプリケーションのトランスポートセッションの相互作用は、相互に合理的に公正な方法でネットワークリソースを調整します。非破壊的な方法でベストエフォート型の環境に声をもたらすための一つの方法は、同時に維持しながら、コーデックに焦点を当て、成功した既存のトランスポートプロトコル（例えば、TCP）と相互運用することができますレート適応策を見ていますリアルタイム、アナログ音声信号のインテグリティ。もう一つの方法は、固定された送信レートのコーデックを考慮することです。コーデックは固定または可変送信レートを持っているかどうか、コーデックが最小データレートであるとき、我々は適切な応答を考慮し、流れが経験するパケットのドロップ率が高いままです。これは、このドキュメントで扱う重要な問題です。
Persistent, high packet drop rates are rarely seen in the Internet today, in the absence of routing failures or other major disruptions. This happy situation is due primarily to low levels of link utilization in the core, with congestion typically found on lower-capacity access links, and to the use of end-to-end congestion control in TCP. Most of the traffic on the Internet today uses TCP, and TCP self-corrects so that the two ends of a connection reduce the rate of packet sending if congestion is detected. In the sections below, we discuss some of the problems caused by persistent, high packet drop rates.
永続的な、高いパケットドロップ率はほとんどのルーティング障害や他の主要な混乱のない状態で、今日のインターネットでは見られません。この幸せな状況は、主に、コア内のリンク使用率の低いレベルに、一般的に低容量のアクセスリンク上で見つけ渋滞で、およびTCPにおけるエンドツーエンドの輻輳制御の使用によるものです。接続の両端が輻輳が検出された場合、送信パケットのレートを下げるように、インターネット上のトラフィックの大部分は、今日は、TCPを使用し、TCPの自己補正します。以下のセクションでは、我々は、永続的な、高いパケットドロップ率に起因する問題のいくつかを議論します。
One possible problem caused by persistent, high packet drop rates is that of congestion collapse. Congestion collapse was first observed during the early growth phase of the Internet of the mid 1980s [RFC896], and the fix was provided by Van Jacobson, who developed the congestion control mechanisms that are now required in TCP implementations [Jacobson88, RFC2581].
永続的な、高いパケットドロップ率に起因する一つの可能性のある問題は、輻輳崩壊のことです。輻輳崩壊は、最初の[RFC896] 1980年代半ばのインターネットの初期の成長期に観察し、修正が[Jacobson88、RFC2581]今TCPの実装に必要とされている輻輳制御機構を開発したバン・ジェイコブソン、によって提供されました。
As described in RFC 2914, congestion collapse occurs in networks with flows that traverse multiple congested links having persistent, high packet drop rates [RFC2914]. In particular, in this scenario packets that are injected onto congested links squander scarce bandwidth since these packets are only dropped later, on a downstream congested link. If congestion collapse occurs, all traffic slows to a crawl and nobody gets acceptable packet delivery or acceptable performance. Because congestion collapse of this form can occur only for flows that traverse multiple congested links, congestion collapse is a potential problem in VoIP networks when both ends of the VoIP call are on an congested broadband connection such as DSL, or when the call traverses a congested backbone or transoceanic link.
RFC 2914に記載されているように、輻輳崩壊は、永続的な、高いパケット損失率[RFC2914]を有する複数の輻輳したリンクをトラバースフローにネットワークで発生します。具体的には、このシナリオでは、輻輳したリンク上に注入されたパケットは、これらのパケットが下流輻輳リンク上で、後だけ落とされるので乏しい帯域幅を浪費します。輻輳崩壊が発生した場合は、すべてのトラフィックは、クロールに減速し、誰もが許容できるパケット配信や許容可能なパフォーマンスを得ません。この形式の輻輳崩壊のみ複数輻輳したリンクをトラバースフローに対して発生する可能性があるため、VoIP呼の両端は、DSLのような混雑ブロードバンド接続上にある場合、または呼が輻輳を横断するとき、輻輳崩壊は、VoIPネットワークにおける潜在的な問題です背骨や大洋横断のリンク。
A second problem with persistent, high packet drop rates concerns service quality seen by end users. Consider a network scenario where each flow traverses only one congested link, as could have been the case in the Nairobi demonstration above. For example, imagine N VoIP flows sharing a 128 Kbps link, with each flow sending at least 64 Kbps. For simplicity, suppose the 128 Kbps link is the only congested link, and there is no traffic on that link other than the N VoIP calls. We will also ignore for now the extra bandwidth used by the telephony traffic for FEC and packet headers, or the reduced bandwidth (often estimated as 70%) due to silence suppression. We also ignore the fact that the two streams composing a bidirectional VoIP call, one for each direction, can in practice add to the load on some links of the path. Given these simplified assumptions, the arrival rate to that link is at least N*64 Kbps. The traffic actually forwarded is at most 2*64 Kbps (the link bandwidth), so at least (N-2)*64 Kbps of the arriving traffic must be dropped. Thus, a fraction of at least (N-2)/N of the arriving traffic is dropped, and each flow receives on average a fraction 1/N of the link bandwidth. An important point to note is that the drops occur randomly, so that no one flow can be expected statistically to present better quality service to users than any other. Everybody's voice quality therefore suffers.
永続的な、高いパケットドロップ率を有する第二の問題は、エンドユーザーから見たサービス品質に関するものです。上記ナイロビのデモでケースだったかもしれないとして、各フローは、一つだけ混雑リンクを通過するネットワークのシナリオを検討してください。例えば、N VoIPは、少なくとも64 Kbpsの送信を各フローに、128 Kbpsのリンクを共有するフロー想像。簡単にするために、128 Kbpsのリンクは唯一の混雑したリンクであると仮定し、そしてN VoIP通話以外にそのリンク上のトラフィックはありません。我々はまた、無音抑制に今のFECとパケットヘッダのテレフォニートラフィックによって使用される追加の帯域幅、または（多くの場合70％と推定）減少した帯域幅を無視します。また、双方向VoIP通話、各方向に1つを構成する2つのストリームが、実際にはパスのいくつかのリンク上の負荷に追加することができるという事実を無視します。これらの単純化の仮定を考えると、そのリンクへの到着率は、少なくともN * 64 Kbpsです。少なくとも（N-2）*到着トラフィックの64 Kbpsのがドロップしなければならないので、実際に転送されるトラフィックは、最大で2 * 64 Kbpsの（リンク帯域幅）です。したがって、少なくとも（N-2）の分画/到着トラフィックのNを滴下し、各フローは、リンク帯域幅の平均分数1 / Nで受信されます。注目すべき重要な点は、誰のフローが、統計的に他のどのよりユーザーに、より良い品質のサービスを提供することが期待できないようにドロップが、ランダムに発生することがあります。みんなの音声品質は、したがって、苦しんでいます。
It seems clear from this simple example that the quality of best-effort VoIP traffic over congested links can be improved if each VoIP flow uses end-to-end congestion control, and has a codec that can adapt the bit rate to the bandwidth actually received by that flow. The overall effect of these measures is to reduce the aggregate packet drop rate, thus improving voice quality for all VoIP users on the link. Today, applications and popular codecs for Internet telephony attempt to compensate by using more FEC, but controlling the packet flow rate directly should result in less redundant FEC information, and thus less bandwidth, thereby improving throughput even further. The effect of delay and packet loss on VoIP in the presence of FEC has been investigated in detail in the literature [JS00, JS02, JS03, MTK03]. One rule of thumb is that when the packet loss rate exceeds 20%, the audio quality of VoIP is degraded beyond usefulness, in part due to the bursty nature of the losses [S03]. We are not aware of measurement studies of whether VoIP users in practice tend to hang up when packet loss rates exceed some limit.
各VoIPフローは、エンドツーエンドの輻輳制御を使用し、帯域幅にビットレートを適応させることができますコーデックが実際に受信した場合には輻輳したリンクの上にベストエフォート型のVoIPトラフィックの品質を向上させることができるこの簡単な例からも明らかなようですその流れによります。これらの対策の全体的な効果は、このように、リンク上のすべてのVoIPユーザーのための音声品質を向上させること、集約パケットのドロップ率を減らすことです。今日は、インターネット電話の試みのためのアプリケーションや人気のコーデックは、それによって、さらにスループットを向上、より多くのFECを使用しますが、パケット流量が直接少ない冗長FEC情報、したがって、より少ない帯域幅を生じるはずで制御することで補償します。 FECの存在下でのVoIPに遅延やパケットロスの影響は、文献[JS00、JS02、JS03、MTK03]に詳細に検討されています。親指のルールは、パケット損失率が20％を超えると、のVoIPの音声品質による損失[S03]のバースト性に部分的に、有用性を超えて分解されることです。私たちは、実際にはVoIPユーザは、パケット損失率は、いくつかの制限を超えたときにハングアップする傾向があるかどうかの測定研究を認識していません。
The simple example in this section considered only voice flows, but in reality, VoIP traffic will compete with other flows, most likely TCP. The response of VoIP traffic to congestion works best by taking into account the congestion control response of TCP, as is discussed in the next subsection.
音声のみと考えられ、このセクションの簡単な例が流れますが、現実には、VoIPトラフィックを他のフロー、最も可能性の高いTCPと競合します。混雑へのVoIPトラフィックの応答は次のサブセクションで説明するように、考慮にTCPの輻輳制御応答を取ることによって、最適に動作します。
A third problem with persistent, high packet drop rates is fairness. In this document we consider fairness with regard to best-effort VoIP traffic competing with other best-effort traffic in the Internet. That is, we are explicitly not addressing the issues raised by emergency services, or by QoS-enabled traffic that is known to be treated separately from best-effort traffic at a congested link.
永続的な、高いパケットドロップ率を持つ第3の問題は公正です。この文書では、インターネットで他のベストエフォートトラフィックと競合ベストエフォート型のVoIPトラフィックに関して公平性を考慮してください。それは我々が明示的に緊急サービスが提起した問題に対処し、または混雑したリンクでのベストエフォートトラフィックから別々に処理されることが知られているQoS対応トラフィックによってされていない、です。
While fairness is a bit difficult to quantify, we can illustrate the effect by adding TCP traffic to the congested link discussed in the previous section. In this case, the non-congestion-controlled traffic and congestion-controlled TCP traffic [RFC2914] share the link, with the congestion-controlled traffic's sending rate determined by the packet drop rate experienced by those flows. As in the previous section, the 128 Kbps link has N VoIP connections each sending 64 Kbps, resulting in packet drop rate of at least (N-2)/N on the congested link. Competing TCP flows will experience the same packet drop rates. However, a TCP flow experiencing the same packet drop rates will be sending considerably less than 64 Kbps. From the point of view of who gets what amount of bandwidth, the VoIP traffic is crowding out the TCP traffic.
公平さを定量化することが少し難しいですが、私たちは前のセクションで説明混雑リンクにTCPトラフィックを追加することにより、効果を説明することができます。この場合、非輻輳制御トラフィックと輻輳制御のTCPトラフィック[RFC2914]これらのフローが経験したパケットのドロップ率によって決定輻輳制御トラフィックの送信速度で、リンクを共有しています。前節と同様に、128 Kbpsのリンク各輻輳リンク上の少なくとも（N-2）/ Nのパケットドロップ率が得られ、64 Kbpsでの送信N VoIP接続を有しています。 TCPフローを競合することは同じパケットのドロップ率が発生します。しかし、同じパケットドロップ率を経験してTCPフローはかなり未満の64Kbpsを送信されます。帯域幅のどのような量を誰の観点から、VoIPトラフィックはTCPトラフィックを締め出しています。
Of course, this is only one way to look at fairness. The relative fairness between VoIP and TCP traffic can be viewed several different ways, depending on the assumptions that one makes on packet sizes and round-trip times. In the presence of a fixed packet drop rate, for example, a TCP flow with larger packets sends more (in Bps, bytes per second) than a TCP flow with smaller packets, and a TCP flow with a shorter round-trip time sends more (in Bps) than a TCP flow with a larger round-trip time. In environments with high packet drop rates, TCP's sending rate depends on the algorithm for setting the retransmit timer (RTO) as well, with a TCP implementation having a more aggressive RTO setting sending more than a TCP implementation having a less aggressive RTO setting.
もちろん、これは公正を見てする唯一の方法です。 VoIPおよびTCPトラフィックとの間の相対的な公正さは、1つのパケットサイズと往復時間になり仮定に応じて、いくつかの異なる方法を表示することができます。固定パケットドロップレートの存在下で、例えば、より大きなパケットとTCPフローは、より小さなパケットでTCPフローよりも（bps単位、バイト毎秒）以上を送信し、短いラウンドトリップ時間とのTCPフローは、よりを送信します（bps単位）拡大往復時間とのTCPフローより。高いパケットドロップ率を持つ環境では、TCPの送信速度はあまり積極的でRTOの設定を持つTCPの実装よりも多くを送信して、より積極的なRTOの設定を持つTCPの実装と、同様に再送信タイマー（RTO）を設定するためのアルゴリズムに依存します。
Unfortunately, there is no obvious canonical round-trip time for judging relative fairness of flows in the network. Agreement in the literature is that the majority of packets on most links in the network experience round-trip times between 10 and 500 ms [RTTWeb].
残念ながら、ネットワークにおけるフローの相対的な公平性を判断するための明白な正規のラウンドトリップ時間がありません。文学の契約は10と500ミリ秒[RTTWeb]との間のネットワークの経験往復時間の中で最もリンク上のパケットの大半ということです。
(This does not include satellite links.) As a result, if there was a canonical round-trip for judging relative fairness, it would have to be within that range. In the absence of a single representative round-trip time, the assumption of this paper is that it is reasonable to consider fairness between a VoIP connection and a TCP connection with the same round-trip time.
（これは、衛星リンクを含まない。）その結果、相対的な公平性を判定するための正規のラウンドトリップが発生した場合、それはその範囲内でなければなりません。単一の代表往復時間がない場合には、本論文の仮定は、VoIP接続と同じラウンドトリップ時間とのTCPコネクション間の公平性を考慮することが妥当であるということです。
Similarly, there is no canonical packet size for judging relative fairness between TCP connections. However, because the most common packet size for TCP data packets is 1460 bytes [Measurement], we assume that it is reasonable to consider fairness between a VoIP connection, and a TCP connection sending 1460-byte data packets. Note that 1460 bytes is considerably larger than is typically used for VoIP packets.
同様に、TCP接続との間の相対的な公平性を判定するための正規のパケット・サイズは存在しません。 TCPデータパケットのための最も一般的なパケットサイズは1460バイト[測定]であるため、しかし、我々はVoIP接続、および1460バイトのデータパケットを送信するTCPコネクション間の公平性を考慮することが妥当であることを前提としています。 1460のバイトは通常、VoIPパケットのために使用されているよりもかなり大きいことに注意してください。
In the same way, while RFC 2988 specifies TCP's algorithm for setting TCP's RTO, there is no canonical value for the minimum RTO, and the minimum RTO heavily affects TCP's sending rate in times of high congestion [RFC2988]. RFC 2988 specifies that TCP's RTO must be set to SRTT + 4*RTTVAR, for SRTT the smoothed round-trip time, and for RTTVAR the mean deviation of recent round-trip time measurements. RFC 2988 further states that the RTO "SHOULD" have a minimum value of 1 second. However, it is not uncommon in practice for TCP implementations to have a minimum RTO as low as 100 ms. For the purposes of this document, in considering relative fairness, we will assume a minimum RTO of 100 ms.
RFC 2988は、TCPのRTOを設定するためのTCPのアルゴリズムを指定しながら、同じように、そこに最小RTOのための標準的な値ではない、と最小RTOは重く、高混雑[RFC2988]の時代におけるTCPの送信速度に影響を与えます。 RFC 2988は、TCPのRTOがSRTT + 4に設定されなければならないことを指定する* RTTVAR、SRTTのための平滑化往復時間、およびRTTVARのための最近のラウンドトリップ時間の測定値の平均偏差。 RTOは、1秒の最小値を有する「SHOULD」とRFC 2988の、さらに状態。 TCPの実装では、100ミリ秒ほどの低い最小RTOを持っているためしかし、それは実際には珍しいことではありません。このドキュメントの目的のために、相対的な公平性を考慮して、我々は100ミリ秒の最小RTOを仮定します。
As an additional complication, TCP connections that use fine-grained timestamps can have considerably higher sending rates than TCP connections that do not use timestamps, in environments with high packet drop rates. For TCP connections with fine-grained timestamps, a valid round-trip time measurement is obtained when a retransmitted packet is successfully received and acknowledged by the receiver; in this case a backed-off retransmit timer can be un-backed-off as well. For TCP connections without timestamps, a valid round-trip time measurement is only obtained when the transmission of a new packet is received and acknowledged by the receiver. This limits the opportunities for the un-backing-off of a backed-off retransmit timer. In this document, in considering relative fairness, we use a TCP connection without timestamps, since this is the dominant use of TCP in the Internet.
追加の合併症として、きめの細かいタイムスタンプを使用してTCP接続が高いパケットのドロップ率を持つ環境では、タイムスタンプを使用していないTCP接続よりもかなり高い送信レートを持つことができます。再送パケットが正常に受信機で受信し、承認されたときに、きめの細かいタイムスタンプを持つTCP接続の場合、有効な往復時間の測定が得られます。この場合にはバックオフ再送信タイマーがun-バックオフだけでなくすることができます。新しいパケットの送信を受信し、受信機によって認識されたときにタイムスタンプなしのTCP接続の場合、有効な往復時間の測定にのみ得られます。これは、バックオフ再送信タイマーの非バックオフの機会を制限します。これは、インターネットにおけるTCPの支配的な使用であることから、この文書では、相対的な公平性を考慮して、我々は、タイムスタンプなしのTCP接続を使用します。
A separate claim that has sometimes been raised in terms of fairness is that best-effort VoIP traffic is inherently more important that other best-effort traffic (e.g., web surfing, peer-to-peer traffic, or multi-player games), and therefore merits a larger share of the bandwidth in times of high congestion. Our assumption in this document is that TCP traffic includes pressing email messages, business documents, and emergency information downloaded from web pages, as well as the more recreational uses cited above. Thus, we do not agree that best-effort VoIP traffic should be exempt from end-to-end congestion control due to any claims of inherently more valuable content. (One could equally logically argue that because email and instant messaging are more efficient forms of communication than VoIP in terms of bandwidth usage, as a result email and instant messaging are more valuable uses of scarce bandwidth in times of high congestion.) In fact, the network is incapable of making a judgment about the relative user value of traffic. The default assumption is that all best-effort traffic has equal value to the network provider and to the user.
時々公正の観点から提起された個別の請求は、ベストエフォート型のVoIPトラフィックは、他のベストエフォートトラフィック（例えば、ウェブサーフィン、ピア・ツー・ピアトラフィック、またはマルチプレイヤーゲーム）本質的に重要であるということである、としたがって、メリットの高い輻輳時における帯域幅の大きなシェア。この文書に記載されている当社の仮定はTCPトラフィックが押して電子メールメッセージ、ビジネス文書、およびWebページからダウンロードした緊急情報だけでなく、上に引用しより多くのレクリエーションの用途が含まれていることです。したがって、我々はベストエフォート型のVoIPトラフィックが原因本質的価値のあるコンテンツのいずれかの請求にエンドツーエンドの輻輳制御を免除されるべきであると同意しません。 （一つは、論理的に電子メールやインスタントメッセージングは、結果の電子メールやインスタントメッセージングなどの帯域幅使用量の面でのVoIPよりもコミュニケーションをより効率的な形態は、あるため、高い混雑の時代に乏しい帯域幅をより貴重な用途があると主張する均等性があります。）実際には、ネットワークトラフィックの相対的なユーザー値についての判断を行うことができません。デフォルトの仮定はすべてベストエフォート型トラフィックは、ネットワークプロバイダに、ユーザに等しい値を有することです。
We note that this discussion of relative fairness does not in any way challenge the right of ISPs to allocate bandwidth on congested links to classes of traffic in any way that they choose. (For example, administrators rate-limit the bandwidth used by peer-to-peer traffic on some links in the network, to ensure that bandwidth is also available for other classes of traffic.) This discussion merely argues that there is no reason for entire classes of best-effort traffic to be exempt from end-to-end congestion control.
私たちは、相対的公正のこの議論はどのような方法で、彼らが選択したことをどのような方法でトラフィックのクラスに輻輳したリンク上の帯域幅を割り当てるためのISPの権利に挑戦しないことに注意してください。 （例えば、レート制限、その帯域幅を確保するために、ネットワーク内のいくつかのリンク上のピア・ツー・ピア・トラフィックによって使用される帯域幅を管理者にもトラフィックの他のクラスのために利用可能である。）この議論は、単に全体のための理由がないと主張ベストエフォート型トラフィックのクラスは、エンドツーエンドの輻輳制御を免除されるように。
There are four efforts currently underway in IETF to address issues of congestion control for real time traffic: an upgrade of the RTP specification, TFRC, DCCP, and work on audio codecs.
そこ現在進行中のリアルタイムトラフィックの輻輳制御の問題に対処するためのIETFの4つの取り組みです：RTP仕様のアップグレード、TFRC、DCCPは、オーディオコーデックに取り組みます。
RFC 1890, the original RTP Profile for Audio and Video Control, does not discuss congestion control [RFC1890]. The revised document on "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] discusses congestion control in Section 2. [RFC3551] says the following:
RFC 1890、オーディオとビデオのコントロールのためのオリジナルのRTPプロファイルは、輻輳制御[RFC1890]を議論していません。 「最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール」[RFC3551]は第2節[RFC3551]で輻輳制御を説明しに改訂されたドキュメントでは、次の言葉：
"If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high."
ベストエフォート型のサービスが使用されている場合は、」、RTP受信機は、パケット損失率が許容パラメータの範囲内であることを保証するために、パケットロスを監視する必要があります。同じネットワーク・パスと同じネットワークの状態を経験して全体のTCPフローが実現するかどうパケット損失が許容可能であると考えられますRTPの流れ以上である合理的なタイムスケールで測定した平均スループットが、達成される。この状態は、伝送速度（又は層状マルチキャストセッションのために加入層数）を適合させるために、輻輳制御メカニズムを実装することによって満たすことができます、損失率が許容できないほど高い場合や受信機のために配置することによって、セッションを終了します。」
"The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude."
「TCPとの比較を正確に特定することはできないが、として意図され、 『タイムスケールとスループットの桁違いの』比較。TCPスループットを測定する上でタイムスケールは、接続のラウンドトリップ時間である。本質的には、この要件は、任意の帯域幅を消費し、桁以内TCPと公平に競合しないベストエフォート型のインターネット上の（RTPまたは任意の他のトランスポートプロトコルを使用して）アプリケーションをデプロイすることは受け入れられないと述べています。」
Note that [RFC3551] says that receivers "SHOULD" monitor packet loss. [RFC3551] does not explicitly say that the RTP senders and receivers "MUST" detect and respond to a persistent high loss rate. Since congestion collapse can be considered a "danger to the Internet" the use of "MUST" would be appropriate for RTP traffic in the best-effort Internet, where the VoIP traffic shares a link with other traffic, since "danger to the Internet" is one of two criteria given in RFC 2119 for the use of "MUST" [RFC2119]. Different requirements may hold for a private best-effort IP network provisioned solely for VoIP, where the VoIP traffic does not interact with the wider Internet.
[RFC3551]は受信機がパケット損失を監視する「べきである」と述べていることに注意してください。 [RFC3551]は、明示的にRTPの送信側と受信側で検出し、持続的な高損失率に対応「しなければならない」と言うことはありません。輻輳崩壊は、「インターネットへの危険」「インターネットに危険」以来、VoIPトラフィックを他のトラフィックとのリンクを共有するベストエフォート型のインターネットでRTPトラフィックに適しているでしょう「MUST」の使用を考慮することができるので、 「MUST」[RFC2119]を使用するためのRFC 2119で指定された二つの基準の一つです。さまざまな要件は、VoIPトラフィックが広く、インターネットと相互作用しないVoIPのためだけにプロビジョニングされた民間のベストエフォート型のIPネットワークのために保持することができます。
As mentioned in RFC 3267, equation-based congestion control is one of the possibilities for VoIP. TCP Friendly Rate Control (TFRC) is the equation-based congestion control mechanism that has been standardized in the IETF. The TFRC specification, "TCP Friendly Rate Control (TFRC): Protocol Specification" [RFC3448], says the following:
RFC 3267で説明したように、方程式ベースの輻輳制御は、VoIPのための可能性の一つです。 TCPフレンドリーレート制御（TFRC）は、IETFで標準化された方程式ベースの輻輳制御メカニズムです。 TFRCの仕様は、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様" [RFC3448]は、次のように述べています：
"TFRC ... is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. ... TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document."
TCPフローと帯域幅を競合するとき、「TFRCは...合理的に公平であるが、そのような比較的滑らかな送付レートはである電話やストリーミングメディアなどのアプリケーションのためにそれをより適切なものに、TCPに比べて時間をかけてスループットのはるかに低い変動を持って重要。... TFRCは、固定されたパケット・サイズを使用するアプリケーション用に設計されており、混雑に応じて、秒あたりのパケットでの送信レートを変更している。一部のオーディオアプリケーションでは、パケット間の時間の一定の間隔を必要とし、代わりに彼らの彼らのパケット・サイズを変えます混雑に応じてパケットレートこの文書における輻輳制御機構は、それらのアプリケーションによって使用することができない;（TFRC-たPacketSize用）TFRC-PSは、固定された送信速度を有するが、応答して、そのパケットサイズを変化させる用途のためのTFRCの変異体であります混雑に。TFRC-PSは、後に文書で指定されます。」
There is no draft available for TFRC-PS yet, unfortunately, but several researchers are still working on these issues.
そこTFRC-PSのために利用可能な案は、残念ながら、まだありませんが、いくつかの研究者はまだ、これらの問題に取り組んでいます。
The Datagram Congestion Control Protocol (DCCP) is a transport protocol being standardized in the IETF for unreliable flows, with the application being able to specify either TCP-like or TFRC congestion control [DCCP03].
データグラム輻輳制御プロトコル（DCCP）は、トランスポートプロトコルは、TCP状またはTFRC輻輳制御[DCCP03]のいずれかを指定することができるアプリケーションで、信頼性の低いフローにIETFで標準化されています。
DCCP currently has two Congestion Control IDentifiers or CCIDs; these are CCID 2 for TCP-like congestion control and CCID 3 for TFRC congestion control. As TFRC-PS becomes available and goes through the standards process, we would expect DCCP to create a new CCID, CCID 4, for use with TFRC-PS congestion control.
DCCPは現在、2つの輻輳制御識別子またはのCCIDsを持っています。これらは、TCPのような輻輳制御のためのCCID 2とTFRCの輻輳制御のためのCCID 3です。 TFRC-PSが利用可能になると標準化プロセスを通過するように、私たちはDCCPのTFRC-PSの輻輳制御で使用するために、新しいCCID、CCID 4を作成することを期待します。
A critical component in the design of any real-time application is the selection of appropriate codecs, specifically codecs that operate at a low sending rate, or that will reduce the sending rate as throughput decreases and/or packet loss increases. Absent this, and in the absence of the response to congestion recommended in this document, the real-time application is likely to significantly increase the risk of Internet congestion collapse, thereby adversely impacting the health of the deployed Internet. If the codec is capable of reducing its bit rate in response to congestion, this improves the scaling of the number of VoIP or TCP sessions capable of sharing a congested link while still providing acceptable performance to users. Many current audio codecs are capable of sending at a low bit rate, in some cases adapting their sending rate in response to congestion indications from the network.
任意のリアルタイムアプリケーションの設計における重要な要素は、具体的には、低い送信レートで動作するコーデックの適切なコーデックの選択である、またはスループットが低下および/またはパケット損失が増加するにつれて、それは送信レートを低下させます。これがなけれおり、この文書で推奨混雑に応答がない場合には、リアルタイム・アプリケーションが大幅にそれによって悪影響展開インターネットの健康に影響を与える、インターネットの混雑崩壊のリスクを増加させる可能性が高いです。コーデックは輻輳に応答して、そのビットレートを低減することが可能であるならば、これはまだユーザーに許容可能なパフォーマンスを提供しながら、混雑リンクを共有できるのVoIPまたはTCPセッションの数のスケーリングを向上させます。現在の多くのオーディオコーデックは、ネットワークからの輻輳の指標に応じて、その送信レートを適応させるいくつかのケースでは、低ビットレートで送信することができます。
RFC 3267 describes RTP payload formats for use with the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs [RFC 3267]. The AMR codec supports eight speech encoding modes having bit rates between 4.75 and 12.2 kbps, with the speech encoding performed on 20 ms speech frames, and is able to reduce the transmission rate during silence periods. The payload format specified in RFC 3267 includes forward error correction (FEC) and frame interleaving to increase robustness against packet loss somewhat. The AMR codec was chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems, and RFC 3267 recommends that AMR or AMR-WB applications using the RTP payload format specified in RFC 3267 use congestion control, though no specific mechanism is recommended. RFC 3267 gives "Equation-Based Congestion Control for Unicast Applications" as an example of a congestion control mechanism suitable for real-time flows [FHPW00].
RFC 3267は、適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WB）音声コーデック[RFC 3267]との使用のためのRTPペイロードフォーマットを記述する。 AMRコーデックは20msの音声フレームに対して実行音声符号化を用いて、4.75および12.2 kbpsの間のビットレートを有する8つの音声符号化モードをサポートし、無音期間中に伝送速度を減少させることができます。 RFC 3267で指定されたペイロードフォーマットは、多少のパケット損失に対するロバスト性を高めるためにインターリーブ順方向誤り訂正（FEC）とフレームを含みます。 AMRコーデックは、第三世代のために必須コーデック（3G）セルラシステムのように、第3世代パートナーシップ・プロジェクト（3GPP）によって選択され、RFC 3267は、AMRまたはAMR-WBアプリケーションがRFC 3267用輻輳制御で指定されたRTPペイロードフォーマットを使用することをお勧めし、具体的なメカニズムが推奨されていないのに。 RFC 3267は、リアルタイムに適した輻輳制御機構の一例として、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」を与える[FHPW00]流れます。
The "Internet Low Bit Rate Codec", iLBC, is an IETF effort to develop an IPR-free codec for robust voice communication over IP [ILBRC]. The codec is designed for graceful speech quality degradation in the case of lost packets, and has a payload bit rate of 13.33 kbps for 30 ms frames or 15.20 kbps for 20 ms frames.
「インターネット低ビットレートコーデック」、iLBCのは、[ILBRC] IPオーバー堅牢な音声通信のための知的財産権フリーのコーデックを開発するIETFの努力です。コーデックは、失われたパケットの場合には優雅な音声品質の劣化のために設計され、および30ミリ秒のフレームまたは20ミリ秒のフレームに対して15.20 kbpsのため13.33 kbpsのペイロードのビットレートを有しています。
There are several unencumbered low-rate codec algorithms in Ivox (the Interactive VOice eXchange) [IVOX], with plans to add additional variable rate codecs. For example, LPC2400 (a.k.a. LQ2400) is a 2400 bps LPC based codec with an enhancement to permit "silence detection". The 2400 bps codec is reported to have a "slight robotic quality" [A03] (even without the additional complications of packet loss). The older multirate codec described in [KFK79, KF82] is an LPC codec that works at two rates, 2.4 kbps and 9.6 kbps, and can optionally send additional "residual" bits for enhanced quality at a higher bit rate.
Ivox（対話型音声交換機）にはいくつかの制約を受けない低レートのコーデックアルゴリズム[IVOX】さらなる可変レートコーデックを追加する計画であります。例えば、LPC2400（別名LQ2400）は、「無音検出」を可能にする拡張と2400bpsのLPCベースのコーデックです。 2400bpsのコーデックは「わずかなロボット品質」を有することが報告されている[A03]（でも、パケット損失の追加の合併症なし）。 [KFK79、KF82]に記載の古いマルチレートコーデックは、2つのレート、2.4 kbpsの9.6 kbpsで動作するLPCコーデックであり、そして必要に応じてより高いビットレートでの品質向上のために、追加の「残留」のビットを送信することができます。
Off-the-shelf ITU-T vocoders such as G.711 were generally designed explicitly for circuit-switched networks and are not as well-adapted for Internet use, even with the addition of FEC on top.
既製のITU-T G.711のようなそのようなボコーダは、一般に、回路交換ネットワークのために明示的に設計されたとのようなインターネットの使用のために十分に適合されていない、も上にFECを加えました。
The Differentiated Services Working Group [DIFFSERV], which concluded in 2003, completed standards for the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [RFC2474], including several per-hop forwarding behaviors [RFC2597, RFC3246]. The Next Steps in Signaling Working Group [NSIS] is developing an optimized signalling protocol for QoS, based in part on earlier work of the Resource Reservation Setup Protocol Working Group [RSVP]. We do not discuss these and related efforts further in this document, since this document concerns only that VoIP traffic that might be carried as best-effort traffic over some congested link in the Internet.
2003年に締結差別化サービスワーキンググループ[DIFFSERV]は、いくつかのホップごとの転送動作を含む[RFC2474]、[RFC2597、RFC3246] IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）のための基準を完了しました。シグナリングワーキンググループ[NSIS]で次のステップは、リソース予約セットアッププロトコルワーキンググループ[RSVP]の以前の作品に部分的に基づいてQoSの最適化されたシグナリングプロトコルを、開発しています。私たちは、この文書の懸念から、この文書でさらにインターネットでいくつかの混雑リンク上などのベストエフォート型トラフィックを運ばれる可能性があるだけで、VoIPトラフィックをこれらと関連した取り組みを議論しないでください。
Current IETF work in the DCCP and AVT working groups does not consider the problem of applications that have a minimum sending rate and are not able to go below that sending rate. This clearly must be addressed in the TFRC-PS draft. As suggested in the RTP document, if the loss rate is persistently unacceptably high relative to the current sending rate, and the best-effort application is unable to lower its sending rate, then the only acceptable answer is for that flow to discontinue sending on that link. For a multicast session, this could be accomplished by the receiver withdrawing from the multicast group. For a unicast session, this could be accomplished by the unicast connection terminating, at least for a period of time.
DCCPおよびAVTワーキンググループの現在のIETF仕事は最小送信レートを持っており、その送信レートを下回る行くことができないアプリケーションの問題を考慮していません。これは明らかにTFRC-PSドラフトで対処しなければなりません。損失率は、現在の送信レートに容認できないほど高い相対永続的であり、ベストエフォート型のアプリケーションは、その送信レートを下げることができない場合、RTP文書で示唆したように、その後、唯一の許容可能な答えはその流れがあることで、送信を中止するためのものですリンク。マルチキャストセッションのために、これは、マルチキャストグループからの撤退受信機によって達成することができます。ユニキャストセッションのために、これは、少なくともある期間、ユニキャスト接続終端することによって達成することができます。
We can formulate a problem statement for the minimum sending rate in the following way. Consider a best-effort, adaptive audio application that is able to adapt down to a minimum sending rate of N Bps (bytes per second) of application data, sending M packets per second. Is this a sufficiently low sending rate that the best-effort flow is never required to terminate due to congestion, or to reduce its sending rate in packets per second still further? In other words, is N Bps an acceptable minimum sending rate for the application, which can be continued in the face of congestion without terminating or suspending the application?
私たちは、次のように割合を送る最小のための問題文を策定することができます。毎秒Mパケットを送信し、アプリケーションデータの（バイト毎秒）NのBP速度を送信最小限まで適応することが可能であるベストエフォート型、適応型音声アプリケーションを考えます。これは、ベストエフォート型のフローが輻輳による終了するのに必要なことはありません、またはさらに他の秒あたりのパケットでの送信速度を低下させることを十分に低い送信レートですか？換言すれば、N BPSが終了またはアプリケーションを中断することなく、輻輳に直面して継続することができるアプリケーションのための許容される最小送信レート、ですか？
We assume, generously for VoIP, that the limitation of the network is in bandwidth in bytes per second (Bps), and not in CPU cycles or in packets per second (pps). If the limitation in the network is in bandwidth, this is a limitation in Bps, while if the limitation is in router processing capacity in packets, this would be a limitation in pps. We note that TCP sends fixed-size data packets, and reduces its sending rate in pps when it adapts to network congestion, thus reducing the load on the forward path both in Bps and in pps. In contrast, for adaptive VoIP applications, the adaption is sometimes to keep the same sending rate in pps, but to reduce the packet size, reducing the sending rate in Bps. This fits the needs of audio as an application, and is a good response on a network path where the limitation is in Bps. Such behavior would be a less appropriate response for a network path where the limitation is in pps.
我々は、ネットワークの制限は、秒（bps）をバイト単位ではなく、CPUサイクルまたは毎秒パケット（PPS）に帯域幅であること、寛大VoIPのため、想定しています。ネットワークの制限は、帯域幅内にある場合は制限がパケット内のルータの処理能力にある場合、これは、PPSの制限であろうが、これは、bps単位の制限です。私たちは、TCPは、固定サイズのデータパケットを送信し、それが輻輳をネットワークに適応したときに、PPSにその送信レートを減少させ、これbps単位とPPSの両方のフォワードパスの負荷を軽減することに注意してください。これとは対照的に、適応VoIPアプリケーションのために、適応はPPSに同じ送信レートを維持するが、bps単位の送信速度を下げる、パケットサイズを小さくすることが時々あります。これは、アプリケーションとして、オーディオのニーズに合った、そして制限がbps単位であるネットワークパス上の良好な応答です。そのような挙動は、制限はPPSであるネットワーク経路にはあまり適切な応答であろう。
If the network limitation in fact is in Bps, then all that matters in terms of congestion is a flow's sending rate on the wire in Bps. If this assumption of a network limitation in Bps is false, then the sending rate in pps could contribute to congestion even when the sending rate in Bps is quite moderate. While the ideal would be to have a transport protocol that is able to detect whether the bottleneck links along the path are limited in Bps or in pps, and to respond appropriately when the limitation is in pps, such an ideal is hard to achieve. We would not want to delay the deployment of congestion control for telephony traffic until such an ideal could be accomplished. In addition, we note that the current TCP congestion control mechanisms are themselves not very effective in an environment where there is a limitation along the reverse path in pps. While the TCP mechanisms do provide an incentive to use large data packets, TCP does not include any effective congestion control mechanisms for the stream of small acknowledgement packets on the reverse path. Given the arguments above, it seems acceptable to us to assume a network limitation in Bps rather than in pps in considering the minimum sending rate of telephony traffic.
実際にネットワークの制限はbps単位であれば、渋滞の面で重要なことはすべて、bps単位ワイヤ上のフローの送信レートです。 bps単位のネットワーク制限のこの仮定が偽である場合には、PPSで送信レートをbps単位送信レートが非常に緩やかである場合でも混雑に貢献できます。理想的な経路に沿ったボトルネックリンクがbps単位やPPSが制限されているかどうかを検出するために、及び制限がPPSである場合に適切に対応することができるトランスポートプロトコルを有することであろうが、そのような理想を達成することは困難です。私たちは、このような理想的が達成できるまでテレフォニートラフィックの輻輳制御の導入を遅らせるのは嫌です。また、当社は、現在のTCPの輻輳制御機構は、それ自体PPSで逆の経路に沿って制限がある環境では非常に効果的ではないことに注意してください。 TCP機構は大きなデータパケットを使用するためのインセンティブを提供しないが、TCPは逆の経路上の小さい確認応答パケットのストリームのための任意の効果的な輻輳制御機構を含んでいません。上記の引数を考えると、テレフォニートラフィックの最小送信レートを考慮にbps単位ではなく、PPSのネットワーク制限を前提とするために私達に許容可能なようです。
Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), the application data sending rate of N Bps and M pps translates to a sending rate on the wire of B = N+40M Bps. If the application uses additional FEC (Forward Error Correction), the FEC bits must be added in as well. In our example, we ignore bandwidth adjustments that are needed to take into account the additional overhead for FEC or the reduced sending rate for silence periods. We also are not taking into account the possible role of header compression on congested edge links, which can reduce significantly the number of bytes used for headers on those links.
BPSが40M NのBP速度を送信する40バイトのパケットヘッダ（IP、RTP及びUDPまたはDCCP）、アプリケーションデータを仮定し、M PPSはBのワイヤ上の送信レートに変換= N +。アプリケーションは、追加のFEC（前方誤り訂正）を使用している場合、FECビットは、同様に追加されなければなりません。この例では、FECまたは沈黙期間のために減少し、送信速度のアカウントに追加のオーバーヘッドを取るために必要な帯域幅の調整を無視します。我々はまた、有意にこれらのリンク上のヘッダーに使用されるバイトの数を減らすことができる混雑エッジリンク、上のアカウントにヘッダ圧縮の可能な役割を果たしていません。
Now, consider an equivalent-rate TCP connection with data packets of P bytes and a round-trip time of R seconds. Taking into account header size, such a TCP connection with a sending rate on the wire of B Bps is sending B/(P+40) pps, or, equivalently, BR/(P+40) ppr (packets per round-trip time).
さて、PバイトのデータパケットおよびR秒の往復時間と同等のレートのTCPコネクションを考えます。 、アカウントヘッダサイズにBのBPワイヤ上の送信レートはB /（P + 40）PPS、または、等価的に、BR /（P + 40）PPR（ラウンドトリップ時間あたりのパケットを送信しているこのようなTCP接続を取ります）。
Restating the question in terms of the above expressions for VoIP and TCP: if the best-effort VoIP connection is experiencing a persistent packet drop rate of D, and is at its minimum sending rate on the wire of B Bps, when should the application or transport protocol terminate or suspend the VoIP connection?
ベストエフォート型のVoIP接続は、Dの永続的なパケット廃棄率を経験し、そして、BのBPSワイヤ上のその最小送信レートであるされている場合すべきアプリケーションまたは：VoIPとTCPのための上記の式の面で問題を修正再表示トランスポートプロトコルは、VoIP接続を終了または一時停止しますか？
One answer to this question is to find the sending rate in ppr for a TCP connection sending at the same rate on the wire in Bps, and to use the TCP response function to determine whether a conformant TCP connection would be able to maintain a sending rate close to that sending rate with the same persistent drop rate D. If the sending rate of the VoIP connection is significantly higher than the sending rate of a conformant TCP connection under the same conditions, and the VoIP connection is unable to reduce its sending rate on the wire, then the VoIP connection should terminate or suspend.
この質問に対する一つの答えはbps単位ワイヤ上の同じ速度で送信TCP接続のためのPPRで送信レートを見つけること、および準拠のTCP接続が送信レートを維持することができるだろうかどうかを判断するためにTCP応答関数を使用することですVoIP接続の送信レートが同じ条件で準拠TCPコネクションの送信レートよりも有意に高く、VoIP接続が上の送信レートを削減することができない場合は、同じ永続ドロップ率Dとその送信レートに近いですワイヤーは、その後、VoIP接続が終了または一時停止する必要があります。
As discussed above, there are two reasons for requiring the application to terminate:
上述したように、終了するアプリケーションを要求するための2つの理由があります。
1) Avoiding congestion collapse, given the possibility of multiple congested links,
1）複数の輻輳リンクの可能性が与えられ、輻輳崩壊を回避
2) Fairness for congestion-controlled TCP traffic sharing the link.
リンクを共有する輻輳制御のTCPトラフィックのための2）公正。
In addition, if an application requires a minimum service level from the network in order to operate, and that service level is consistently not achieved, then the application should terminate or suspend sending.
また、アプリケーションが動作するために、ネットワークからの最小サービス・レベルを必要とし、そのサービスレベルが一貫して達成されない場合、アプリケーションが終了または送信中断すべきです。
One counter-argument is that users will just hang up anyway with a high packet drop rate so there is no point in enforcing a minimum acceptable rate. Users might hang up, but they might also just keep on talking, with the occasional noise getting though, for minutes or longer waiting for a short period of clarity. Another counter-argument is that nobody really benefits from VoIP connections being terminated or suspended when persistent packet drop rates exceed the allowable packet drop rate for the configured minimum sending rate. This is untrue, since the termination of these VoIP connections could allow competing TCP and VoIP traffic to make some progress.
一つの反論は、最小許容レートを適用さにはポイントがありませんので、ユーザーは単に高いパケット廃棄率をとにかくハングアップするということです。ユーザーがハングアップかもしれないが、彼らはまた、単に明確さの短い期間を待っ分以上、時折ノイズががきて、話を続けるかもしれません。もう一つの反論は、誰もが本当に永続的なパケットドロップ率が設定された最小送信レートの許容パケット廃棄率を超えたときに終了または中断されているVoIP接続の恩恵を受けていないということです。これらのVoIP接続の終了は、いくつかの進歩を遂げるためにTCPおよびVoIPトラフィックを競合する可能性がありますので、これは真実ではありません。
In the next section, we illustrate the approach outlined above for VoIP flows with minimum sending rates of 4.75 and 64 kbps respectively, and show that in practice such an approach would not seem too burdensome for VoIP traffic. This approach implies that the VoIP traffic would terminate or suspend when the packet drop rate significantly exceeds 40% for a VoIP flow with a minimum sending rate of 4.75 kbps. If VoIP is to deliver "carrier quality" or even near "carrier quality" on best-effort links, conditioning deployment on the ability to maintain maximum sending rates during periods of persistent packet drops rates exceeding 40% does not suggest a service model that will see widespread acceptance among consumers, no matter what the price differential. Good packet throughput is vital for the delivery of acceptable VoIP service.
次のセクションでは、説明のためのVoIPの上で概説したアプローチは、それぞれ4.75と64 kbpsの最小の送信速度で流れ、実際にはこのようなアプローチは、VoIPトラフィックのためにあまりにも負担に思えないだろうことを示しています。このアプローチは、VoIPトラフィックが終了したり、パケットのドロップ率が大幅に4.75 kbpsの最小の送信レートでのVoIPフローの40％を超えたときに中断することを意味します。 VoIPは「キャリア品質」、さらにはベストエフォート型リンク上の近くに「キャリア品質」を提供することであるならば、永続的なパケットの期間中に最大送信速度を維持する能力の調整の展開は、40％を超える金利をドロップその意志のサービスモデルを示唆していませんどんな価格差、消費者の間で広く受け入れを見ません。グッドパケットのスループットが許容できるVoIPサービスの提供のために不可欠です。
For a VoIP flow that stops sending because its minimum sending rate is too high for the steady-state packet drop rate, we have not addressed the question of when a VoIP flow might be able to start sending again, to see if the congestion on the end-to-end path has changed. This issue has been addressed in a proposal for Probabilistic Congestion Control [PCC].
その最小送信レートが定常状態のパケットのドロップ率は高すぎるので、送信を停止VoIPフローのために、我々は、VoIPフローが上の混雑かどうかを確認するために、再送信を開始することができるかもしれないときの問題に対処していませんエンドツーエンドのパスが変更されました。この問題は、確率的輻輳制御[PCC]の提案で解決されています。
We note that if the congestion indications are in the form of ECN-marked packets (Explicit Congestion Notification), as opposed to dropped packets, then the answers about when a flow with a minimum sending rate would have to stop sending are somewhat different. ECN allows routers to explicitly notify end-nodes of congestion by ECN-marking instead of dropping packets [RFC3168]. If packets are ECN-marked instead of dropped in the network, then there are no concerns of congestion collapse or of user quality (for the ECN-capable traffic, at any rate), and what remains are concerns of fairness with competing flows. Second, in regimes with very high congestion, TCP has a higher sending rate with ECN-marked than with dropped packets, in part because of different dynamics in terms of un-backing-off a backed-off retransmit timer.
我々は対照的に、渋滞表示は、ECN-マークされたパケット（明示的輻輳通知）の形態である場合、パケットをドロップすることに注意し、その後、最小送信レートを有するフローが送信を停止しなければならない時期についての回答は多少異なります。 ECNは、ルータが明示的ECNマーキングの代わりに、パケット[RFC3168]を滴下することにより、輻輳のエンドノードに通知することを可能にします。パケットがECN-マークの代わりに、ネットワーク内に落下している場合は、そこ（ECN対応のトラフィックのために、任意の割合で）輻輳崩壊のか、ユーザーの質のない懸念されるものではなく、どのような遺跡競合フローとの公平性の関心事です。第二に、非常に高い混雑して政権に、TCPがあるため、非バックオフバックオフの再送信タイマーの面で異なるダイナミクスの一部に、ドロップされたパケットよりもECN-マークでより高い送信レートを持っています。
Consider an adaptive audio application with an RTT of R=0.1 seconds that is able to adapt down to a minimum sending rate of 4.75 kbps application data, sending M=20 packets per second. This sending rate translates to N=593 Bps of application data, for a sending rate on the wire of B=1393 Bps. An equivalent-rate TCP connection with data packets of P=1460 bytes and a round-trip time of R=0.1 seconds would be sending BR/(P+40) = 0.09 ppr.
毎秒M = 20のパケットを送信し、4.75 kbpsのアプリケーションデータの最小送信レートまで適応することができるR = 0.1秒のRTTと適応音声アプリケーションを考えます。この送信レートは、B = 1393件のBPワイヤ上の送信レートのために、アプリケーション・データのN = 593 bpsに変換します。 P = 1460バイトのデータパケットおよびR = 0.1秒の往復時間と同等のレートのTCP接続は、BR /（P + 40）= 0.09 PPRを送信することになります。
Table 1 in the Appendix looks at the packet drop rate experienced by a TCP connection with the RTO set to twice the RTT, and gives the corresponding sending rate of the TCP connection in ppr. The second column gives the sending rate estimated by the standard analytical approach, and the third, fourth, and fifth columns give the average sending rate from simulations with random packet drops or marks. The sixth column gives the sending rates from experiments on a 4.8- RELEASE FreeBSD machine. The analytical approaches require an RTO expressed as a multiple of the RTT, and Table 1 shows the results for the RTO set to 2 RTT. In the simulations, the minimum RTO is set to twice the RTT. See the Appendix for more details.
付録の表1は、二回RTTにRTOが設定されたTCPコネクションが経験したパケットのドロップ率を見て、PPRにおけるTCPコネクションの対応する送信レートを提供します。第2列は、標準的な分析手法によって推定された送信レートを与え、第三、第四、及び第五列は、ランダムパケットドロップやマークとシミュレーションから速度を送信平均値を与えます。第6列は、4.8- RELEASE FreeBSDマシン上の実験から送信レートを提供します。分析的アプローチは、RTTの倍数として表され、表1は2 RTTにRTOセットの結果を示すRTOを必要とします。シミュレーションでは、最小RTOは二回RTTに設定されています。詳細については、付録を参照してください。
For a sending rate of 0.09 ppr and an RTO set to 2 RTT, Table 1 shows that the analytical approach gives a corresponding packet drop rate of roughly 50%, while the simulations in the fifth column and the experiments in the sixth column give a packet drop rate of between 35% and 40% to maintain a sending rate of 0.09 ppr. (For a reference TCP connection using timestamps, shown in the fourth column, the simulations give a packet drop rate of 55% to maintain a sending rate of 0.09 ppr.) Of the two approaches for determining TCP's relationship between the sending rate and the packet drop rate, the analytic approach and the use of simulations, we consider the simulations to be the most realistic, for reasons discussed in the Appendix. This suggests a packet drop rate of 40% would be reasonable for a TCP connection with an average sending rate of 0.09 ppr. As a result, a VoIP connection with an RTT of 0.1 sec and a minimum sending rate of 4.75 kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeds 40%.
0.09 PPRとRTOの送信レートが2 RTTに設定するための第5列目のシミュレーションおよび6列目の実験はパケットを与えながら、表1には、分析的アプローチは約50％の対応するパケットドロップ率を与えることを示しています0.09 PPRの送信レートを維持するために、％35％〜40の速度を落とします。 （第4列に示されているタイムスタンプを用いて基準TCP接続の場合、シミュレーションは0.09 PPRの送信レートを維持するために、55％のパケット損失率を与える。）送信レートとパケットとの間のTCPの関係を決定するための2つのアプローチの率、分析的なアプローチとシミュレーションの使用を落とし、我々は付録で説明する理由のために、シミュレーションが最も現実的であると考えています。これは、40％のパケット廃棄率は0.09 PPRの平均送信レートとのTCP接続のために合理的である示唆しています。その結果、0.1秒のRTTと4.75 kbpsの最小の送信レートとのVoIP接続を終了または永続的なパケットドロップ率が有意に40％を超えた場合に中断することを要求されます。
These estimates are sensitive to the assumed round-trip time of the TCP connection. If we assumed instead that the equivalent-rate TCP connection had a round-trip time of R=0.01 seconds, the equivalent-rate TCP connection would be sending BR/(P+40) = 0.009 ppr. However, we have also assumed a minimum RTO for TCP connections of 0.1 seconds, which in this case would mean an RTO of at least 10 RTT. For this setting of the RTO, we would use Table 2 from the appendix to determine the average TCP sending rate for a particular packet drop rate. The simulations in the fifth column of Table 2 suggest that a TCP connection with an RTT of 0.01 sec and an RTO of 10 RTT would be able to send 0.009 ppr with a packet drop rate of 45%. (For the same TCP connection using timestamps, shown in the fourth column, the simulations give a packet drop rate of 60-65% to maintain a sending rate of 0.009 ppr.)
これらの推定値は、TCPコネクションの仮定のラウンドトリップ時間に敏感です。私たちが代わりに仮定した場合の等価レートのTCP接続はR = 0.01秒の往復時間を持っていたこと、同等のレートのTCP接続がBR /（P + 40）= 0.009 PPRを送ることになります。しかし、我々はまた、この場合には少なくとも10 RTTのRTOを意味しており、0.1秒のTCP接続のための最低限のRTOを想定しています。 RTOのこの設定のために、我々は特定のパケットドロップ率の平均TCP送信レートを決定するために付録から表2を使用します。表2の第5列におけるシミュレーションは、0.01秒のRTT及び10 RTTのRTOとのTCP接続は、45％のパケット損失率と0.009 PPRを送信することができるであろうことを示唆しています。 （第4列に示されているタイムスタンプを使用して、同じTCP接続の場合、シミュレーションは0.009 PPRの送信レートを維持するために、60から65パーセントのパケットドロップ率を与えます。）
Thus, for a VoIP connection with an RTT of 0.01 sec and a minimum sending rate of 4.75 kbps, the VoIP connection would be required to terminate or suspend when the persistent packet drop rate exceeded 45%.
このように、0.01秒のRTTとのVoIP接続と4.75 kbpsの最小送信レートのため、VoIP接続は、永続的なパケットドロップ率が45％を超えたときに終了または一時停止するために必要とされるであろう。
The effect of increasing the minimum acceptable sending rate to 64 kbps is effectively to decrease the packet drop rate at which the application should terminate or suspend sending. For this section, consider a codec with a minimum sending rate of 64 kbps, or N=8000 Bps, and a packet sending rate of M=50 pps. (This would be equivalent to 160-byte data packets, with 20 ms. per packet.) The sending rate on the wire is B = N+40M Bps, including headers, or 10000 Bps. A TCP connection having that sending rate, with packets of size P=1460 bytes and a round-trip time of R=0.1 seconds, sends BR/(P+40) = 0.66 ppr. From the fifth column of Table 1, for an RTO of 2 RTT, this corresponds to a packet drop rate between 20 and 25%. [For a TCP connection using fine-grained timestamps, as shown in the fourth column of Table 1, this sending rate corresponds to a packet drop rate between 25% and 35%.] As a result, a VoIP connection with an RTT of 0.1 sec and a minimum sending rate of 64 kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeds 25%.
64 kbpsに最小許容送信率を増加させる効果は、アプリケーションが終了または送信中断すべきでパケットドロップ率を減少させるために効果的です。このセクションでは、64 kbpsの最小送信速度、またはN = 8000 bps単位、及びM = 50のPPSのパケット送信レートを有するコーデックを考慮する。 （これは、20ミリ秒と、160バイトのデータ・パケットに相当するであろう。パケットごとに）ワイヤ上の送信速度は、ヘッダー、または10000 bps単位を含む、= N + 40M bps単位Bです。サイズPのパケット= 1460バイトとR = 0.1秒の往復時間と、速度を送信する、BR /（P + 40）= 0.66 PPRを送信することを有するTCP接続。表1の5列目から、2 RTTのRTOのために、これは20と25％の間のパケットドロップ率に相当します。表1の4列目に示すように、この送信速度が25％と35％との間のパケットドロップ率に対応する、きめの細かいタイムスタンプを使用して、TCP接続の。その結果、0.1のRTTとのVoIP接続として永続的なパケットドロップ率が大幅に25％を超える場合秒、64 kbpsの速度を送信する最小終了または一時停止するために必要とされるであろう。
For an equivalent-rate TCP connection with a round-trip time of R=0.01 seconds and a minimum RTO of 0.1 seconds (giving an RTO of 10 RTT), we use the fifth column of Table 2, which shows that a sending rate of 0.066 ppr corresponds to a packet drop rate of roughly 30%. [For a TCP connection using fine-grained timestamps, as shown in the fourth column of Table 2, this sending rate corresponds to a packet drop rate of roughly 45%.] Thus, for a VoIP connection with an RTT of 0.01 sec and a minimum sending rate of 64 kbps, the VoIP connection would be required to terminate or suspend when the persistent packet drop rate exceeded 30%.
R = 0.01秒の往復時間および0.1秒の最小RTO（10 RTTのRTOを与える）と同等のレートのTCP接続のために、我々は示す。表2の第5列を、使用することの送信速度0.066 PPRは、約30％のパケット損失レートに対応します。 [表2の第4列に示されるようにきめの細かいタイムスタンプを使用して、TCP接続の場合、この送信レートは、およそ45％のパケット損失レートに対応する。]このように、0.01秒のRTTとのVoIP接続のための64 kbpsの最小の送信レートは、VoIP接続が終了または永続的なパケットドロップ率が30％を超えたときに一時停止することが要求されます。
This document does not attempt to specify a complete protocol. For example, this document does not specify the definition of a persistent packet drop rate. The assumption would be that a
この文書では、完全なプロトコルを指定しようとしません。たとえば、このドキュメントは、永続的なパケット廃棄率の定義を指定していません。仮定は、Aになります
"persistent packet drop rate" would refer to the packet drop rate over a significant number of round-trip times, e.g., at least five seconds. Another possibility would be that the time interval for measuring the persistent drop rate is a function of the lifetime of the connection, with longer-lived connections using longer time intervals for measuring the persistent drop rate.
「永続的なパケット廃棄率」、例えば、往復時間のかなりの数を介してパケットのドロップ率に少なくとも5秒を参照してくださいだろう。別の可能性は、永続的なドロップ率を測定するための時間間隔は、持続的なドロップ率を測定するために、より長い時間間隔を使用して長い寿命の接続との接続の寿命の関数であるということでしょう。
The time period for detecting persistent congestion also affects the potential synchronization of VoIP sessions all terminating or suspending at the same time in response to shared congestion. If flows use some randomization in setting the time interval for detecting persistent congestion, or use a time interval that is a function of the connection lifetime, this could help to prevent all VoIP flows from terminating at the same time.
持続的な輻輳を検出するための時間もすべて終了または共有の混雑に応じて、同時に停止のVoIPセッションの潜在的な同期に影響を与えます。フローが永続的な輻輳を検出するための時間間隔を設定するには、いくつかのランダム化を使用し、または接続寿命の関数である時間間隔を使用している場合、これはすべてのVoIPが同時に終端から流れを防止するのに役立つ可能性があり。
Another design issue for a complete protocol concerns whether a flow terminates when the packet drop rate is too high, or only suspends temporarily. For a flow that suspends temporarily, there is an issue of how long it should wait before resuming transmission. At the very least, the sender should wait long enough so that the flow's overall sending rate doesn't exceed the allowed sending rate for that packet drop rate.
パケットのドロップ率が高すぎる、または単に一時的に中断したときに完全なプロトコルへの懸念のための別の設計上の問題は、フローが終了するかどうか。一時的に中断し、フローのために、それは、送信を再開する前に待機する時間の問題があります。流れの全体的な送信レートは、そのパケットのドロップ率に対する許容送信レートを超えないように、最低でも、送信者は、十分な長待つ必要があります。
The recommendation of this document is that VoIP flows with minimum sending rates should have corresponding configured packet drop rates, such that the flow terminates or suspends when the persistent packet drop rate of the flow exceeds the configured rate. If the persistent packet drop rate increases over time, flows with higher minimum sending rates would have to suspend sending before flows with lower minimum sending rates. If VoIP flows terminate when the persistent packet drop rate is too high, this could lead to scenarios where VoIP flows with lower minimum sending rates essentially receive all of the link bandwidth, while the VoIP flows with higher minimum sending rates are required to terminate. However, if VoIP flows suspend sending for a time when the persistent packet drop rate is too high, instead of terminating entirely, then the bandwidth could end up being shared reasonably fairly between VoIP flows with different minimum sending rates.
本文書の勧告は、VoIPフローが終了するか、フローの持続的なパケットドロップ率が設定速度を超えたときに中断するように、対応する構成パケットドロップ率を有していなければならない最小の送信レートで流れるということです。永続的なパケットが時間をかけて速度が増加をドロップする場合は、下の最小送信レートで流れて前に送信中断しなければならない高い最小送信速度で流れています。永続的なパケット廃棄率が高すぎるとVoIPが終了流れるとVoIPが低く最小送信速度で流れてどこ、これはVoIPが終了するために必要とされる高い最小送信速度で流れている間、本質的に、リンク帯域幅の全てを受信シナリオにつながる可能性があります。 VoIPのフローではなく、完全に終了するの、永続的なパケット廃棄率が高すぎる時間のために送信中断場合VoIPが異なる最小送信レートで流れの間しかし、その後、帯域幅は、合理的にかなり共有されてしまう可能性があります。
One simple heuristic for estimating congestion would be to use the RTCP reported loss rate as an indicator. For example, if the RTCP-reported lost rate is greater than 30%, or N back-to-back RTCP reports are missing, the application could assume that the network is too congested, and terminate or suspend sending.
RTCPを用いることであろう輻輳を推定するための一つの簡単なヒューリスティックは、指標としての損失率を報告しました。例えば、RTCP報告失わ率が30％以上である場合、またはN背中合わせRTCPレポートが欠落している、アプリケーションは、ネットワークが混雑しすぎていると仮定し、終了または送信中断できます。
Ultimately, attempting to run VoIP on congested links, even with adaptive rate codecs and minimum packet rates, is likely to run into hard constraints due to the nature of real time traffic in heavily congested scenarios. VoIP systems exhibit a limited ability to scale their packet rate. If the number of packets decreases, the amount of audio per packet is greater and error concealment at the receiver becomes harder. Any error longer than phoneme length, which is typically 40 to 100 ms depending on the phoneme and speaker, is unrecoverable. Ideally, applications want sub 30ms packets and this is what most voice codecs provide. In addition, voice media streams exhibit greater loss sensitivity at lower data rates. Lower-data rate codecs maintain more end-to-end state and as a result are generally more sensitive to loss.
最終的に、でも適応レートコーデックおよび最小パケットレートで、輻輳したリンク上でのVoIPを実行しようと、非常に輻輳シナリオにおけるリアルタイムトラフィックの性質のためにハードな制約に遭遇する可能性があります。 VoIPシステムは、そのパケットレートをスケーリングする限られた能力を示します。パケットの数が減少した場合、パケットあたりのオーディオの量が大きく、受信機におけるエラー隠蔽が困難となります。音素とスピーカーに応じて、典型的には40〜100ミリ秒である音素長、より長いすべてのエラーが回復不能です。理想的には、アプリケーションはサブ30msのパケットをしたい、これはほとんどの音声コーデックが提供するものです。また、低いデータレートで音声メディアストリームの展示大きな損失感度。低データレートコーデックは、複数のエンド・ツー・エンドの状態を維持し、結果として一般損失に対してより敏感です。
We note that very-low-bit-rate codecs have proved useful, although with some performance degradation, in very low bandwidth, high noise environments (e.g., 2.4 kbps HF radio). For example, 2.4 kbps codecs "produce speech which although intelligible is far from natural sounding" [W98]. Figure 5 of [W98] shows how the speech quality with several forms of codecs varies with the bit rate of the codec.
我々は非常に低ビットレートのコーデックは非常に低い帯域幅、高ノイズ環境（例えば、2.4 kbpsのHF無線機）で、いくつかのパフォーマンスの低下であるが、有用であることが証明されていることに注意してください。例えば、2.4 kbpsのコーデックは、[W98]「分かりやすいがはるかに自然な響きからですがスピーチを作ります」。 [W98]の図5は、コーデックのいくつかの形態を有する音声品質は、コーデックのビットレートにどのように変化するかを示しています。
In the near term, VoIP services are likely to be deployed, at least in part, over broadband best-effort connections. Current real time media encoding and transmission practice ignores congestion considerations, resulting in the potential for trouble should VoIP become a broadly deployed service in the near to intermediate term. Poor user quality, unfairness to other VoIP and TCP users, and the possibility of sporadic episodes of congestion collapse are some of the potential problems in this scenario.
短期的には、VoIPサービスは、ブロードバンドベストエフォート型の接続を介して、少なくとも部分的には、展開される可能性があります。現在のリアルタイムメディアエンコーディングおよび伝送の練習は、VoIPは、中間期に近くで広く展開されたサービスになる必要があり、トラブルのための潜在的な結果として、渋滞考慮事項を無視します。悪いユーザーの質、他のVoIPおよびTCPユーザーに不公平、および輻輳崩壊の散発的なエピソードの可能性は、このシナリオにおける潜在的な問題のいくつかです。
These problems can be mitigated in applications that use fixed-rate codecs by requiring the best-effort VoIP application to specify its minimum bit throughput rate. This minimum bit rate can be used to estimate a packet drop rate at which the application would terminate.
これらの問題は、その最小ビットのスループット・レートを指定するには、ベストエフォート型のVoIPアプリケーションを必要とすることによって、固定レートのコーデックを使用するアプリケーションに緩和することができます。この最小ビットレートは、アプリケーションが終了することになるでのパケットドロップ率を推定するために使用することができます。
This document specifically recommends the following:
この文書では、具体的には、以下をお勧めします。
(1) In IETF standards for protocols regarding best-effort flows with a minimum sending rate, a packet drop rate must be specified, such that the best-effort flow terminates, or suspends sending temporarily, when the steady-state packet drop rate significantly exceeds the specified drop rate.
（1）ベストエフォートに関するプロトコルのIETF規格では、パケットドロップ率がベストエフォートフローが定常状態のパケットが大幅に速度を落としたときに、終了、または一時的に送信を中断するように、指定する必要があり、最小の送信レートで流れます。指定されたドロップ率を超えています。
(2) The specified drop rate for the minimum sending rate should be consistent with the use of Tables 1 and 2 as illustrated in this document.
この文書に示されているように（2）最小送信レートの指定されたドロップ率は、表1および表2の使用と一致しなければなりません。
We note that this is a recommendation to the IETF community, as a specific follow-up to RFC 2914 on Congestion Control Principles.
私たちは、輻輳制御の原理上のRFC 2914に固有のフォローアップとして、これはIETFコミュニティへの勧告であることに注意してください。
This is not a specific or complete protocol specification.
これは、特定のまたは完全なプロトコル仕様ではありません。
Codecs that are able to vary their bit rate depending on estimates of congestion can be even more effective in providing good quality service while maintaining network efficiency under high load conditions. Adaptive variable-bit-rate codecs are therefore preferable as a means of supporting VOIP sessions on shared use Internet environments.
輻輳の推定値に応じて、それらのビットレートを変化させることができるコーデックは、高負荷条件下で、ネットワーク効率を維持しながら、良質のサービスを提供する上でより効果的であることができます。適応可変ビットレートコーデックは、従って、共用インターネット環境でVOIPセッションをサポートする手段として好適です。
Real-time traffic such as VoIP could derive significant benefits from the use of ECN, where routers may indicate congestion to end-nodes by marking packets instead of dropping them. However, ECN is only standardized to be used with transport protocols that react appropriately to marked packets as indications of congestion. VoIP traffic that follows the recommendations in this document could satisfy the congestion-control requirements for using ECN, while VoIP traffic with no mechanism for terminating or suspending when the packet dropping and marking rate was too high would not. However, we repeat that this document is not a complete protocol specification. In particular, additional mechanisms would be required before it was safe for applications running over UDP to use ECN. For example, before using ECN, the sending application would have to ensure that the receiving application was capable of receiving ECN-related information from the lower-layer UDP stack, and of interpreting this ECN information as a congestion indication.
VoIPなどのリアルタイムトラフィックは、ルータがパケットをマーキングの代わりにそれらをドロップすることで、ノードを終了する輻輳を示すことECNの使用から大きな利益を引き出すことができます。しかし、ECNのみ輻輳の指標としてマーキングされたパケットに適切に反応するトランスポートプロトコルで使用するように規格化されています。率を終了または中断時にパケット廃棄やマーキングのための機構がないものがありVoIPトラフィックがないだろうが高すぎた一方で、ECNを使用するための輻輳制御要件を満たすことができ、このドキュメントの推奨事項を以下のVoIPトラフィック。しかし、私たちは、この文書は、完全なプロトコル仕様ではないことを繰り返します。それはECNを使用するには、UDP上で実行中のアプリケーションのための安全で前に具体的には、追加的なメカニズムが必要とされるであろう。例えば、ECNを使用する前に、送信側アプリケーションは、受信アプリケーションがUDPスタック、および輻輳表示としてこのECN情報を解釈するの下層からECN関連情報を受信することができたことを確認しなければなりません。
We thank Brian Adamson, Ran Atkinson, Fred Baker, Jon Crowcroft, Christophe Diot, Alan Duric, Jeremy George, Mark Handley, Orion Hodson, Geoff Huston, Eddie Kohler, Simon Leinen, David Meyer, Jean-Francois Mule, Colin Perkins, Jon Peterson, Mike Pierce, Cyrus Shaoul, and Henning Schulzrinne for feedback on this document. (Of course, these people do not necessarily agree with all of the document.) Ran Atkinson and Geoff Huston contributed to the text of the document.
私たちは、ブライアン・アダムソン感謝、アトキンソン、フレッド・ベイカー、ジョンクロウクロフト、クリストフDiot、アランDuric、ジェレミー・ジョージ、マーク・ハンドリー、オリオンホドソン、ジェフ・ヒューストン、エディー・コーラー、サイモンLeinen、デビッド・マイヤー、ジャン=フランソワラバ、コリンパーキンス、ジョン蘭このドキュメントに関するフィードバックのためのピーターソン、マイク・ピアース、サイラスShaoul、およびヘニングSchulzrinneと。 （もちろん、これらの人々は、必ずしも文書のすべてに同意しない。）アトキンソン蘭とジェフ・ヒューストンは、文書のテキストに貢献しました。
The analysis in Section 6.0 resulted from a session at the whiteboard with Mark Handley. We also thank Alberto Medina for the FreeBSD experiments showing TCP's sending rate as a function of the packet drop rate.
セクション6.0での分析では、マーク・ハンドリーとホワイトボードでのセッションから生じました。また、パケット廃棄率の関数としてTCPの送信レートを示すFreeBSDの実験のためにアルベルト・メディナに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A. and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[RFC3267] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.およびQ.謝、「適応マルチレート（AMR）と適応マルチのためのリアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットとファイルストレージのフォーマットレート広帯域（AMR-WB）オーディオコーデック」、RFC 3267、2002年6月。
[A02] Ran Atkinson, An ISP Reality Check, Presentation to ieprep, 55th IETF Meeting, November 2002. URL "http://www.ietf.cnri.reston.va.us/proceedings/ 02nov/219.htm#slides".
[A02]は、第55回IETFミーティング、2002年11月URL "http://www.ietf.cnri.reston.va.us/proceedings/ 02nov / 219.htm＃スライドを" ieprepするアトキンソン、ISP真偽の確認、プレゼンテーションを蘭。
[A03] Brian Adamson, private communication, June 2003.
[A03]ブライアン・アダムソン、民間の通信、2003年6月。
[BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001.
[BBFS01]ディーパック・バンソール、ハリ・バラクリシュナン、サリーフロイド、とスコット・シェンカー、ゆっくりと応答性輻輳制御アルゴリズムの動的挙動、SIGCOMM 2001。
[COPS] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[COPS]ダラム、D.、編、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、 2000年1月。
[DCCP03] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye, Datagram Congestion Control Protocol (DCCP), internet-draft Work in Progress, March 2003. URL "http://www.icir.org/kohler/dcp/".
[DCCP03]エディコーラー、マーク・ハンドリー、サリーフロイド、およびJitendra Padhye、データグラム輻輳制御プロトコル（DCCP）、進行中のインターネット・ドラフトの作業、2003年3月URL「http://www.icir.org/kohler/dcp/ 」。
[DIFFSERV] Differentiated Services (diffserv), Concluded Working Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/ OLD/diffserv-charter.html".
[DIFFSERV]差別化サービス（DiffServは）、ワーキンググループ、URL "http://www.ietf.cnri.reston.va.us/html.charters/ OLD / DiffServの-charter.html" を締結しました。
[E2E] The end2end-interest mailing list, URL "http://www.postel.org/mailman/listinfo/end2end-interest".
[E2E] end2end金利メーリングリスト、URL "http://www.postel.org/mailman/listinfo/end2end-interest"。
[FHPW00] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000.
【FHPW00] S.フロイド、M.ハンドレー、J. Padhye、J.ウィドマー、 "ユニキャストアプリケーションのための方程式ベースの輻輳制御"、ACM SIGCOMM 2000。
[FM03] S. Floyd and R. Mahajan, Router Primitives for Protection Against High-Bandwidth Flows and Aggregates, internet draft (not yet submitted).
[FM03] S.フロイドとR.マハジャン、保護に対する高帯域幅のフローと集約、インターネットドラフトのためのルータプリミティブは（まだ提出されていません）。
[FWD] Free World Dialup, URL "www.pulver.com/fwd/".
[FWD]フリー・ワールドダイアルアップ、URL "www.pulver.com/fwd/"。
[IEPREP02] Internet Emergency Preparedness (ieprep), Minutes, 55th IETF Meeting, November 2002. URL "http://www.ietf.cnri.reston.va.us/proceedings/ 02nov/219.htm#cmr".
[IEPREP02]インターネット防災（ieprep）、議事録、第55回IETFミーティング、2002年11月URL "http://www.ietf.cnri.reston.va.us/proceedings/ 02nov / 219.htm＃CMR"。
[ILBRC] S.V. Andersen, et. al., Internet Low Bit Rate Codec, Work in Progress, March 2003.
【ILBRC] S.V.アンデルセン、ら。 al。は、インターネット低ビットレートコーデックは、進歩、2003年3月に作業します。
[G.114] Recommendation G.114 - One-way Transmission Time, ITU, May 2003. URL "http://www.itu.int/itudoc/itu-t/aap/sg12aap/recaap/g.114/".
[G.114]勧告G.114 - 片道送信時間、ITU、2003年5月URL "http://www.itu.int/itudoc/itu-t/aap/sg12aap/recaap/g.114/" 。
[IVOX] The Interactive VOice eXchange, URL "http://manimac.itd.nrl.navy.mil/IVOX/".
[IVOX]対話型音声交換、URL "http://manimac.itd.nrl.navy.mil/IVOX/"。
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
[Jacobson88] V.ヤコブソン、輻輳回避とコントロール、ACM SIGCOMM '88、1988年8月。
[AUT] The maximum feasible drop rate for VoIP traffic depends on the codec. These numbers are a range for a variety of codecs; voice quality begins to deteriorate for many codecs around a 10% drop rate. Note from authors.
[AUT] VoIPトラフィックのための可能な最大のドロップ率は、コーデックに依存します。これらの数値は、コーデックのさまざまな範囲です。音声品質は、10％の低下率の周りの多くのコーデックのために悪化し始めます。著者から注意してください。
[JS00] Wenyu Jiang and Henning Schulzrinne, Modeling of Packet Loss and Delay and Their Effect on Real-Time Multimedia Service Quality, NOSSDAV, 2000. URL "http://citeseer.nj.nec.com/jiang00modeling.html".
[JS00] Wenyu江とヘニングSchulzrinneと、パケットロスや遅延およびリアルタイムのマルチメディアサービス品質、NOSSDAV、2000年URL「http://citeseer.nj.nec.com/jiang00modeling.html」上における効果のモデル化。
[JS02] Wenyu Jiang and Henning Schulzrinne, Comparison and Optimization of Packet Loss Repair Methods on VoIP Perceived Quality under Bursty Loss, NOSSDAV, 2002. URL "http://www1.cs.columbia.edu/~wenyu/".
[JS02] Wenyu江とヘニングSchulzrinneと、比較とバースト性の損失の下でVoIPの知覚品質上のパケット損失の修復方法の最適化、NOSSDAV、2002年URL「http://www1.cs.columbia.edu/~wenyu/」。
[JS03] Wenyu Jiang, Kazummi Koguchi, and Henning Schulzrinne, QoS Evaluation of VoIP End-points, ICC 2003. URL "http://www1.cs.columbia.edu/~wenyu/".
[JS03] Wenyu江、Kazummi小口、およびヘニングSchulzrinneと、VoIPのエンドポイントのQoS評価、ICC 2003 URL "http://www1.cs.columbia.edu/~wenyu/"。
[KFK79] G.S. Kang, L.J. Fransen, and E.L. Kline, "Multirate Processor (MRP) for Digital Voice Communications", NRL Report 8295, Naval Research Laboratory, Washington DC, March 1979.
【KFK79] G.S.カン、L.J. Fransen、及びE.L.クライン、「デジタル音声通信のためのマルチレートプロセッサ（MRP）」、NRLレポート8295、海軍研究所、ワシントンDC、1979年3月。
[KF82] G.S. Kang and L.J. Fransen, "Second Report of the Multirate Processor (MRP) for Digital Voice Communications", NRL Report 8614, Naval Research Laboratory, Washington DC, September 1982.
[KF82] G.S.カンとL.J. Fransen、 "デジタル音声通信のためのマルチレート・プロセッサ（MRP）の第二報告書"、NRLレポート8614、海軍研究所、ワシントンDC、1982年9月。
[Measurement] Web page on "Measurement Studies of End-to-End Congestion Control in the Internet", URL "http://www.icir.org/floyd/ccmeasure.html". The section on "Network Measurements at Specific Sites" includes measurement data about the distribution of packet sizes on various links in the Internet.
「インターネットでのエンドツーエンドの輻輳制御の測定学」、URL「http://www.icir.org/floyd/ccmeasure.html」の[測定] Webページ。 「特定の部位でネットワーク測定」のセクションでは、インターネットでさまざまなリンク上のパケットサイズの分布に関する測定データを含んでいます。
[MTK03] A. P. Markopoulou, F. A. Tobagi, and M. J. Karam, "Assessing the Quality of Voice Communications Over Internet Backbones", IEEE/ACM Transactions on Networking, V. 11 N. 5, October 2003.
【MTK03] A. P. Markopoulou、F. A. Tobagi、およびM. J. Karamの、 "音声通信オーバーインターネットバックボーンの品質を評価"、ネットワーク、V. 11 N. 5 2003年10月にIEEE / ACMトランザクション。
[NSIS] Next Steps in Signaling (nsis), IETF Working Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/nsis-charter.html".
シグナリング（NSIS）で[NSIS]次のステップ、IETFワーキンググループ、URL "http://www.ietf.cnri.reston.va.us/html.charters/nsis-charter.html"。
[PCC] Joerg Widmer, Martin Mauve, and Jan Peter Damm. Probabilistic Congestion Control for Non-Adaptable Flows. Technical Report 3/2001, Department of Mathematics and Computer Science, University of Mannheim. URL "http://www.informatik.uni-mannheim.de/informatik/pi4/projects/ CongCtrl/pcc/index.html".
[PCC]イェルクウィドマー、マーティン・モーヴ、とヤンペーター・ダム。非適応フローのための確率的輻輳制御。テクニカルレポート2001分の3、数学とコンピュータサイエンス学部、マンハイム大学。 URL "http://www.informatik.uni-mannheim.de/informatik/pi4/projects/ CongCtrl / PCC / index.htmlを"。
[PFTK98] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP Throughput: A Simple Model and its Empirical Validation, Tech Report TF 98-008, U. Mass, February 1998.
[PFTK98] J. Padhye、V. Firoiu、D. Towsley、J.黒瀬、モデルTCPスループット：簡単なモデルとその実証的検証、技術レポートTF 98から008、U.ミサ、1998年2月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPにおける輻輳制御"、RFC 896、1984年1月。
[RFC1890] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[RFC1890] Schulzrinneと、H.、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 1890、1996年1月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group, RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、「保証転送PHBグループ、RFC 2597、1999年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S., Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "IPに明示的輻輳通知（ECN）の追加"、RFC 3168、2001年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3448] Handley, M., Floyd, S., Pahdye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Pahdye、J.およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[RSVP] Resource Reservation Setup Protocol (rsvp), Concluded Working Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/ OLD/rsvp-charter.html".
[RSVP]リソース予約セットアッププロトコル（RSVP）、ワーキンググループ、URL "http://www.ietf.cnri.reston.va.us/html.charters/ OLD / RSVP-charter.htmlは" を締結しました。
[RTTWeb] Web Page on Round-Trip Times in the Internet, URL "http://www.icir.org/floyd/rtt-questions.html"
インターネットでのラウンドトリップ時間の[RTTWeb] Webページ、URL「http://www.icir.org/floyd/rtt-questions.html」
[S03] H. Schulzrinne, private communication, 2003.
[S03] H. Schulzrinneと、民間の通信、2003年。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 3551、2003年7月。
[Vonage] Vonage, URL "www.vonage.com".
[Vonageの] Vonageの、URL "www.vonage.com"。
[W98] J. Woodward, Speech Coding, Communications Research Group, University of Southampton, 1998. URL "http://www-mobile.ecs.soton.ac.uk/speech_codecs/",
[W98] J.ウッドワード、音声符号化、コミュニケーション研究グループ、サウサンプトン大学、1998年URL "http://www-mobile.ecs.soton.ac.uk/speech_codecs/"、
The standard way to estimate TCP's average sending rate S in packets per round-trip as a function of the packet drop rate would be to use the TCP response function estimated in [PFTK98]:
パケット廃棄率の関数としての往復あたりのパケットでTCPの平均送信速度Sを推定するための標準的な方法は、[PFTK98]で推定TCP応答機能を使用することです：
S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2)) (1)
S = 1 /（SQRT（2P / 3）+ Kの分（1,3- SQRT（3P / 8））、P（1 + 32 P ^ 2））（1）
for acks sent for every data packet, and the RTO set to K*RTT.
K * RTTにすべてのデータパケット、およびRTOのセットのために送られたACKのために。
The results from Equation (1) are given in the second column in Tables 1 and 2 below. However, Equation (1) overestimates TCP's sending rate in the regime with heavy packet drop rates (e.g., of 30% or more). The analysis behind Equation (1) assumes that once a single packet is successfully transmitted, TCP's retransmit timer is no longer backed-off. This might be appropriate for an environment with ECN, or for a TCP connection using fine-grained timestamps, but this is not necessarily the case for a non-ECN-capable TCP connection without timestamps. As specified in [RFC2988], if TCP's retransmit timer is backed-off, this back-off should only be removed when TCP successfully transmits a new packet (as opposed to a retransmitted packet), in the absence of timestamps.
式（1）の結果を以下の表1および2の第2列に示されています。しかし、式（1）重いパケットドロップ率（例えば、30％以上の）と政権におけるTCPの送信レートを過大評価します。式（1）の背後にある分析は、単一のパケットが正常に送信されると、TCPの再送信タイマーは、もはやバックオフであることを前提としていません。これは、ECNと環境のために、またはきめの細かいタイムスタンプを使用してTCP接続のために適切であるかもしれないが、これは必ずしもタイムスタンプのない非ECN対応のTCP接続のためのケースではありません。 [RFC2988]で指定されているようにTCPの再送信タイマーがオフに裏打ちされている場合、タイムスタンプの不存在下で、（再送パケットではなく）TCPが正常に新しいパケットを送信する場合、このバックオフだけで削除する必要があります。
When the packet drop rate is 50% or higher, for example, many of the successful packet transmissions can be of retransmitted packets, and the retransmit timer can remain backed-off for significant periods of time, in the absence of timestamps. In this case, TCP's throughput is determined largely by the maximum backoff of the retransmit timer. For example, in the NS simulator the maximum backoff of the retransmit timer is 64 times the un-backed-off value. RFC 2988 specifies that "a maximum value MAY be placed on RTO provided it is at least 60 seconds." [Although TCP implementations vary, many TCP implementations have a maximum of 45 seconds for the backed-off RTO after dropped SYN packets.]
パケットのドロップ率が50％以上である場合には、例えば、成功したパケット伝送の多くは、再送パケットにすることができ、かつ再送信タイマは、タイムスタンプが存在しない場合には、時間のかなりの期間のためのバックオフのまますることができます。この場合、TCPのスループットは、再送信タイマーの最大バックオフによって主に決定されます。例えば、NSシミュレータに再送タイマーの最大バックオフは64回非バックオフ値です。 RFC 2988には、「RTOが、それは少なくとも60秒で提供する上での最大値を配置することができる。」ことを指定します[TCP実装が異なるが、多くのTCP実装は後にSYNパケットをドロップされたバックオフRTOのための45秒の最大値を有します。]
Another limitation of Equation (1) is that it models Reno TCP, and therefore underestimates the sending rate of a modern TCP connection that used SACK and Limited Transmit.
式（1）の別の制限は、それはそれモデルリノTCPであるので、SACKとリミテッド送信を使用する現代のTCPコネクションの送信速度を過小評価します。
The table below shows estimates of the average sending rate S in packets per RTT, for TCP connections with the RTO set to 2 RTT for Equation (1).
RTOとのTCP接続が式2 RTT（1）に設定するために以下の表は、RTTあたりのパケットの平均送信速度Sの推定値を示します。
These estimates are compared with simulations in the third, fourth, and fifth columns, with ECN, packet drops for TCP with fine-grained timestamps, and packet drops for TCP without timestamps respectively. (The simulation scripts are available from http://www.icir.org/floyd/VoIP/sims.) Each simulation computes the
これらの推定値はECNと、パケットは、きめの細かいタイムスタンプとTCPのために低下し、パケットは、それぞれのタイムスタンプすることなくTCPのために低下する、第三、第四、及び第五列のシミュレーションと比較されます。 （シミュレーションスクリプトがhttp://www.icir.org/floyd/VoIP/simsから入手できます。）各シミュレーションは計算します
average sending rate over the second half of a 10,000-second simulation, and for each packet drop rate, the average is given over 50 simulations. For the simulations with very high packet drop rates, it is sometimes the case that the SYN packet is repeatedly dropped, and the TCP sender never successfully transmits a packet. In this case, the TCP sender also never gets a measurement of the round-trip time.
10,000秒のシミュレーションの後半にわたって、各パケットドロップ率の平均送信率は、平均50のシミュレーションにわたって与えられます。非常に高いパケットドロップ率のシミュレーションで、それは時々SYNパケットを繰り返しドロップされた場合で、かつTCPの送信者は、決して成功したパケットを送信します。この場合、TCPの送信者はまた、ラウンドトリップ時間の測定値を取得することはありません。
The sixth column of Table 1 shows the average sending rate S in packets per RTT for an experiment using a 4.8-RELEASE FreeBSD machine. For the low packet drop rates of 0.1 and 0.2, the sending rate in the simulations is higher than the sending rate in the experiments; this is probably because the TCP implementation in the simulations uses Limited Transmit [RFC3042]. With Limited Transmit, the TCP sender can sometimes avoid a retransmit timeout when a packet is dropped and the congestion window is small. With high packet drop rates of 0.65 and 0.7, the sending rate in the simulations is somewhat lower than the sending rate in the experiments. For these high packet drop rates, the TCP connections in the experiments would often abort prematurely, after a sufficient number of successive packet drops.
表1の第6列は、4.8-RELEASE FreeBSDマシンを用いた実験のためにRTTあたりのパケットの平均送信速度Sを示しています。 0.1と0.2の低いパケット損失率のために、シミュレーションにおける送信速度は、実験における送信レートよりも高くなります。シミュレーションでのTCP実装は限定ミット[RFC3042]を使用しているため、これはおそらくです。リミテッド送信すると、パケットがドロップされたときにTCPの送信者は、時々再送タイムアウトを回避することができますし、輻輳ウィンドウが小さいです。 0.65および0.7の高いパケット損失率と、シミュレーションにおける送信速度は、実験における送信レートよりも幾分低いです。連続したパケットの十分な数が低下した後、これらの高いパケットドロップ率について、実験でTCP接続は、多くの場合、途中で中止します。
We note that if the ECN marking rate exceeds a locally-configured threshold, then a router is advised to switch from marking to dropping. As a result, we do not expect to see high steady-state marking rates in the Internet, even if ECN is in fact deployed.
私たちは、ECNマーキング率がローカルで設定されたしきい値を超えた場合、ルータはドロップにマーキングを切り替えることをお勧めしていることに注意してください。その結果、私たちは、ECNが実際に配備されている場合でも、インターネットに高い定常状態マーキング率を確認することを期待しないでください。
Drop
Rate p Eq(1) Sims:ECN Sims:TimeStamp Sims:Drops Experiments
------ ----- -------- -------------- ---------- -----------
0.1 2.42 2.92 2.38 2.32 0.72
0.2 .89 1.82 1.26 0.82 0.29
0.25 .55 1.52 .94 .44 0.22
0.35 .23 .99 .51 .11 0.10
0.4 .16 .75 .36 .054 0.068
0.45 .11 .55 .24 .029 0.050
0.5 .10 .37 .16 .018 0.036
0.55 .060 .25 .10 .011 0.024
0.6 .045 .15 .057 .0068 0.006
0.65 .051 . .033 .0034 0.008
0.7 .041 .06 .018 .0022 0.007
0.75 .034 .04 .0099 .0011
0p.8 .028 .027 .0052 .00072
0.85 .023 .015 .0021 .00034
0.9 .020 .011 .0011 .00010
0.95 .017 .0079 .00021 .000037
Table 1: Sending Rate S as a Function of the Packet Drop Rate p, for RTO set to 2 RTT, and S in packets per RTT.
表1：RTOはRTTあたりのパケットに2 RTT、及びSに設定するために、パケットドロップ率pの関数としての速度Sを送信します。
The table below shows the average sending rate S, for TCP connections with the RTO set to 10 RTT.
以下の表は、10 RTTにRTOが設定されたTCP接続のための平均送信速度Sを示しています。
Drop
Rate p Eq(1) Sims:ECN Sims:TimeStamp Sims:Drops
------ ----- -------- -------------- ----------
0.1 0.97 2.92 1.67 1.64
0.2 0.23 1.82 .56 .31
0.25 0.13 .88 .36 .13
0.3 0.08 .61 .23 .059
0.35 0.056 .41 .15 .029
0.4 0.040 .28 .094 .014
0.45 0.029 .18 .061 .0080
0.5 0.021 .11 .038 .0053
0.55 0.016 .077 .022 .0030
0.6 0.013 .045 .013 .0018
0.65 0.010 . .0082 .0013
0.7 0.0085 .018 .0042
0.75 0.0069 .012 .0025 .00071
0.8 0.0057 .0082 .0014 .00030
0.85 0.0046 .0047 .00057 .00014
0.9 0.0041 .0034 .00026 .000025
0.95 0.0035 .0024 .000074 .000013
Table 2: Sending Rate as a Function of the Packet Drop Rate, for RTO set to 10 RTT, and S in packets per RTT.
表2：RTOはRTTあたりのパケットで10 RTT、及びSに設定するために、パケットドロップレートの関数としてレートを送信。
This document does not itself create any new security issues for the Internet community.
この文書は、それ自体は、インターネットコミュニティのための新たなセキュリティ問題を作成しません。
There are no IANA considerations regarding this document.
この文書に関する一切IANAの考慮事項はありません。
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャ委員会メールアドレス：iab@iab.org
Internet Architecture Board Members at the time this document was published were:
インターネットアーキテクチャ委員会のメンバーは、この文書が発行された時点でした。
Bernard Aboba Harald Alvestrand (IETF chair) Rob Austein Leslie Daigle (IAB chair) Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston (IAB Executive Director) Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
バーナードAbobaハラルドAlvestrand（IETFいす）ロブAusteinとレスリーDaigle氏（IABいす）パトリックFaltstromサリーフロイド6月-イチローいとぢゅん萩野マーク・ハンドリージェフ・ヒューストン（IABエグゼクティブ・ディレクター）チャーリー・カウフマンジェームス・ケンプ、エリックレスコラマイク・セントジョンズ
This document was created in January 2004.
この文書は2004年1月に作成されました。
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。