[要約] 要約：RFC 3714は、インターネット上の音声トラフィックの過負荷制御に関するIABの懸念をまとめたものです。 目的：このRFCの目的は、音声トラフィックの過負荷制御に関する問題を議論し、解決策を提案することです。
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
インターネットでの音声トラフィックの混雑制御に関するIABの懸念
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）The Internet Society（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を待っていると想定していますが、現実には、Best-Effort Broadband Internet Connectionsをめぐる音声サービスは、需要が高まっている利用可能なサービスです。一部のISPはバックボーンにQOを展開し、一部の企業イントラネットはエンドツーエンドのQOを内部的に提供しますが、エンドツーエンドのQOは一般に現在のインターネットの顧客が利用できません。ベストエフォルトのメディア接続に関する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は、インターネット内のQoSアーキテクチャの展開に対する技術的な課題のいくつかを概説しています[RFC2990]。多くの場合、急速に成長するアプリケーションのサポートを提供する暫定的な措置が採用されており、より破壊的な技術の遍在する展開の圧力が削減される必要性を満たすのに十分成功しています。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メカニズムが含まれます。このようなローカル形式のQOは、渋滞からのベストエフォルトVoIPトラフィックの一部を保護することに非常に成功する可能性があります。ただし、これらのローカル形式のQOは、エンドツーエンドVOIP接続に直接表示されません。ベストエフォルト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テレフォニーの展開の可能性を考えると、エンドツーエンドの輻輳制御を実践していないリアルタイムの音声トラフィックの急速な成長により、輻輳崩壊の可能性についていくつかの懸念が生じます。このドキュメントは、ベストエフォルトネットワークのベストエフォルトテレフォニートラフィックの急速な成長から生じる、公平性、ユーザーの品質、および渋滞の崩壊の危険性に関するいくつかの懸念を提起します。送信率が最小であり、少なくとも1つの混雑したリンクを使用してパス上の他のベストエフォルトトラフィックと直接競合する最良のテレフォニー接続を検討し、そのようなトラフィックを終了する必要があるかどうかの特定の質問に対処します。送信速度を下げるときに、持続的で高いパケットドロップレートに直面して、一時的に送信を一時的に停止します。
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]。オーディオトラフィックは、ビデオやその他のリアルタイムトラフィックに比べて、このような低速度で送信されるため、オーディオトラフィックにはエンドツーエンドの混雑制御が必要ないと主張されることがあります。したがって、このドキュメントの懸念は一般的ですが、このドキュメントは、Best-Effortオーディオトラフィックの特定の問題に焦点を当てています。
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-Interestメーリングリスト[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、ダイヤルアップ、ケーブルモデムリンクなど）をネットワーク輻輳の主要なソースとして説明し、VoIPトラフィックは市販のISPのパケットのごくわずかな割合であると説明しました。トラフィック[A02]。プレゼンテーションでは、VoIPは5-40％[AUT]のパケットドロップレートの存在下で良質の品質を受け取ったと述べました。VoIPコールでは、ITU-T G.711コーデックに加えて、独自のFECエンコーディングに加えて、RTP/UDP/IPフレーミングを使用しました。結果として生じるインターネット上のトラフィック負荷は、コーデックで必要な64 kbpsを大幅に超えていました。デモンストレーションの経路に沿った主要な混雑ポイントは、ケニアの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を実行しているデータサービスがある場合、一部の音声パケットは追加の90ミリ秒を遅らせる可能性があります。音声トラフィックの150ミリ秒[G.114]の時間。これにより、ユーザーにとって顕著な遅延が発生し、遅延の変動が増加し、したがって、破裂したTCPトラフィックが出入りするにつれて、通話品質が発生します。前の段落からのナイロビコールなど、すでに高い遅延があるコールの場合、競合するTCPトラフィックによるジッターの増加は、受信機のジッターバッファーの要件も増加させます。それにもかかわらず、「キャリアクラス」サービスでのVoIPの優れたパフォーマンスに関係なく、混雑した最優秀リンクでのVoIPの使用は、近い将来に増加する可能性があります。64 kbpsでパケットを送信し、128 kbpsアクセスリンクの半分を消費し、40％のドロップレートに直面して持続するベストエフォルト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.
インターネットでのベストエフォートトラフィックには、通話の受け入れや拒否のメカニズムは含まれていません。代わりに、ベストエフォルトネットワーク自体は、リソース管理の点で大部分がニュートラルであり、アプリケーションのトランスポートセッションの相互作用は、合理的に公正な方法でネットワークリソースを相互に規制します。破壊的な方法で最高のエフォルト環境に音声をもたらす1つの方法は、コーデックに焦点を合わせ、既存の輸送プロトコル（例えば、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の自己修正を使用しているため、接続の2つの端が輻輳が検出された場合にパケット送信の速度を下げます。以下のセクションでは、持続的で高いパケットドロップ率によって引き起こされる問題のいくつかについて説明します。
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].
持続的で高いパケットドロップ率によって引き起こされる可能性のある問題の1つは、輻輳崩壊の問題です。1980年代半ばのインターネットの初期成長段階[RFC896]で輻輳崩壊が最初に観察され、修正はTCP実装で現在必要な混雑制御メカニズムを開発したヴァンジェイコブソンによって提供されました[jacobson88、rfc2581]。
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などの混雑したブロードバンド接続にある場合、またはコールが混雑している場合にcommingなブロードバンド接続にある場合、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.
持続的で高いパケットドロップレートの2番目の問題は、エンドユーザーが見たサービス品質に関するものです。上記のナイロビのデモンストレーションであるように、各フローが1つの混雑したリンクのみを横断するネットワークシナリオを考えてみましょう。たとえば、128 kbpsリンクを共有するn voipフローを想像してください。各フローは少なくとも64 kbpsを送信します。簡単にするために、128 kbpsリンクが唯一の混雑したリンクであり、n voip呼び出し以外にそのリンクにトラフィックがないと仮定します。また、FECおよびパケットヘッダーのテレフォニートラフィックで使用される追加の帯域幅、または沈黙の抑制による帯域幅の減少（多くの場合70％と推定）を無視します。また、双方向のVoIP呼び出しを構成する2つのストリームが、それぞれの方向に1つが実際にパスのいくつかのリンクの負荷を追加できるという事実を無視します。これらの単純化された仮定を考えると、そのリンクへの到着率は少なくともn*64 kbpsです。実際に転送されるトラフィックは最大2*64 kbps（リンク帯域幅）であるため、少なくとも（N-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]で詳細に調査されています。経験則の1つは、パケットの損失率が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リンクにはそれぞれ64 kbpsが送信されるn VoIP接続があり、その結果、混雑したリンクで少なくとも（N-2）/Nのパケットドロップレートが生じます。競合するTCPフローは、同じパケットドロップレートを経験します。ただし、同じパケットドロップレートを経験するTCPフローにより、64 kbps未満がかなり少なくなります。誰が帯域幅の量を得るかという観点から、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.
もちろん、これは公平性を見る1つの方法にすぎません。VoIPとTCPトラフィックの間の相対的な公平性は、パケットサイズと往復時間で行う仮定に応じて、いくつかの異なる方法を見ることができます。たとえば、固定パケットドロップレートの存在下では、より大きなパケットを備えたTCPフローは、パケットが小さいTCPフローよりも多く（BPS、BPS、バイト）、往復時間が短いTCPフローはより多く送信されます。（BPSでは）往復時間が大きいTCPフローよりも。パケットドロップレートが高い環境では、TCPの送信率は、再送信タイマー（RTO）を設定するためのアルゴリズムに依存します。TCP実装により、より積極的なRTOの実装がより積極的なRTO設定を送信するより積極的な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は高渋滞の時代のTCPの送信率に大きく影響します[RFC2988]。RFC 2988は、TCPのRTOをSRTT 4*RTTVARに設定する必要があることを指定します。RFC 2988はさらに、RTOの「最低値」の値が1秒であるはずだと述べています。ただし、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接続の場合、再送信パケットが正常に受信され、受信機によって認められたときに有効な往復時間測定が取得されます。この場合、バックオフ再送信タイマーも同様に解除される可能性があります。タイムスタンプのない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.
公正な点で時々提起された別の主張は、他の最高のエフォルトトラフィック（例：Webサーフィン、ピアツーピアトラフィック、またはマルチプレイヤーゲーム）、およびMulti-Playerゲーム）よりも本質的に重要であるということです。したがって、輻輳の時点で帯域幅のより大きなシェアに値します。このドキュメントでの私たちの仮定は、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の権利に挑戦して、claspedis膜のクラスへの帯域幅を選択する方法で帯域幅を割り当てる権利に挑戦していないことに注意してください。（たとえば、管理者は、ネットワーク内のいくつかのリンクでピアツーピアトラフィックで使用される帯域幅をレートに制限して、帯域幅が他のクラスのトラフィックにも利用できるようにすることを確認します。）この議論は、全体の理由がないと主張するだけです。エンドツーエンドの混雑制御から免除される最良のエフォルトトラフィックのクラス。
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では、RTP仕様のアップグレード、TFRC、DCCP、およびオーディオコーデックの作業など、IETFで現在進行中の4つの取り組みがあります。
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:
オーディオおよびビデオコントロールの元のRTPプロファイルであるRFC 1890は、混雑制御[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."
「Best-Effortサービスが使用されている場合、RTP受信機はパケットの損失を監視して、パケットの損失率が許容可能なパラメーター内にあることを確認する必要があります。同じネットワークパスを超えて同じネットワーク条件を経験する場合、パケット損失は許容可能であると見なされます。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スループットが測定されるタイムスケールは、接続の往復時間です。本質的に、これはこれは要件は、帯域幅をarbitrarily意的に消費する最高のエフォルトインターネットにアプリケーション（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トラフィックには、「インターネットに対する危険」が必要になります。「必須」[RFC2119]を使用するためにRFC 2119に与えられた2つの基準の1つです。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の可能性の1つです。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."
「TFRC ...は、TCPフローと帯域幅を競う場合に合理的に公平ですが、TCPと比較して時間の経過とともにスループットのバリエーションがはるかに低いため、比較的スムーズな送信率があるテレフォニーやストリーミングメディアなどのアプリケーションにより適しています。重要性。... TFRCは、固定パケットサイズを使用するアプリケーション向けに設計されており、輻輳に応じて1秒あたりのパケットの送信率を変化させます。一部のオーディオアプリケーションは、パケット間の固定時間間隔を必要とし、パケットサイズの代わりにパケットサイズを変更する必要があります。このドキュメントの混雑制御メカニズムは、それらのアプリケーションでは使用できません。TFRC-PS（TFRC-PACKETSIZEの場合）は、固定送信レートを持つが、応答してパケットサイズが異なるアプリケーションの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）は、信頼性の低いフローのためにIETFで標準化されているトランスポートプロトコルであり、アプリケーションはTCP様またはTFRC混雑制御[DCCP03]を指定できます。
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つの混雑制御識別子またはCCIDがあります。これらは、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は、Adaptive Multi-Rate（AMR）およびAdaptive Multi-Rate Wideband（AMR-WB）オーディオコーデック[RFC 3267]で使用するRTPペイロード形式を説明しています。AMRコーデックは、4.75から12.2 kbpsのビットレートを持つ8つの音声エンコードモードをサポートし、音声エンコードは20 msの音声フレームで実行され、沈黙期間中に伝送速度を下げることができます。RFC 3267で指定されたペイロード形式には、パケット損失に対する堅牢性を多少増加させるために、前方エラー補正（FEC）とフレームインターリーブが含まれます。AMRコーデックは、第3世代（3G）セルラーシステムの必須コーデックとして第3世代パートナーシッププロジェクト（3GPP）によって選択され、RFC 3267は、RFC 3267で指定されたRTPペイロード形式を使用してAMRまたはAMR-WBアプリケーションを使用して、Commention Controlを使用することを推奨しています。、特定のメカニズムは推奨されませんが。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は、IP [ILBRC]を介した堅牢な音声通信のためのIPRフリーコーデックを開発するためのIETFの取り組みです。コーデックは、失われたパケットの場合に優雅な音声品質の低下のために設計されており、30ミリ秒のフレームで13.33 kbps、20 msフレームで15.20 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（A.K.A。LQ2400）は、「Silence Detection」を許可する強化を備えた2400 bps LPCベースのコーデックです。2400 bpsコーデックは、「わずかなロボット品質」[A03]（パケット損失の追加の合併症がなくても）があると報告されています。[KFK79、KF82]に記載されている古いマルチレートコーデックは、2.4 kbpsと9.6 kbpsの2つのレートで動作する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.
G.711などの既製のITU-Tボコーダーは、一般にサーキットスイッチされたネットワーク向けに明示的に設計されており、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年に終了したDisideatiated Servicesワーキンググループ[DiffServ]は、IPv4およびIPv6ヘッダー[RFC2474]の差別化されたサービスフィールド（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?
次の方法で、最小送信率の問題ステートメントを策定できます。アプリケーションデータのN BPS（1秒あたりバイト）の最小送信率に適応できる最良の適応オーディオアプリケーションを考えてみてください。これは、輻輳のために最良のエフォルトフローが終了する必要がないか、さらにパケットの送信率をさらにさらに下げるために必要とされるほど十分に低い送信率ですか？言い換えれば、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.
VoIPについては、ネットワークの制限は、CPUサイクルまたはパケットあたり（PPS）ではなく、1秒あたりのバイト（BPS）で帯域幅にあると仮定します。ネットワークの制限が帯域幅にある場合、これはBPSの制限ですが、制限がパケットのルーター処理容量である場合、これはPPSの制限になります。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のネットワーク制限のこの仮定が誤っている場合、BPSの送信率が非常に緩やかである場合でも、PPSの送信率がうっ血に寄与する可能性があります。理想は、パスに沿ったボトルネックリンクがBPSまたはPPSで制限されているかどうかを検出できる輸送プロトコルを用意し、制限がPPSにある場合に適切に対応することです。そのような理想が達成されるまで、テレフォニートラフィックの混雑制御の展開を遅らせたくありません。さらに、PPSの逆パスに沿って制限がある環境では、現在のTCP混雑制御メカニズム自体があまり効果的ではないことに注意してください。TCPメカニズムは大規模なデータパケットを使用するインセンティブを提供しますが、TCPには、逆パス上の小さな確認パケットのストリームに効果的な混雑制御メカニズムは含まれていません。上記の議論を考えると、テレフォニートラフィックの最小送信率を考慮する際に、PPSではなくBPSのネットワークの制限を引き受けることは私たちにとって受け入れられているようです。
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.
40バイトのパケットヘッダー（IP、RTP、およびUDPまたはDCCP）を仮定すると、N BPSおよびM PPSのアプリケーションデータ送信率は、B = N 40m BPSのワイヤの送信率に変換されます。アプリケーションが追加の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 BPSのワイヤの送信レートとのTCP接続は、B/（p 40）ppsを送信しています。
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およびTCPの上記の式の観点から質問を修正します：最良のVoIP接続がDの永続的なパケットドロップレートを経験している場合、B BPのワイヤでの最小送信速度で、アプリケーションまたはいつ必要なのか輸送プロトコルは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.
この質問に対する答えの1つは、BPSのワイヤで同じレートで送信するTCP接続のPPRの送信率を見つけることであり、TCP応答関数を使用して、コンフォーマントTCP接続が送信率を維持できるかどうかを判断することです。同じ永続的なドロップレートでの送信レートに近いD. VoIP接続の送信率が同じ条件下でのコンフォーマントTCP接続の送信率よりも大幅に高い場合、VoIP接続は送信率を下げることができませんワイヤ、その後、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.
2) リンクを共有する混雑制御TCPトラフィックの公平性。
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.
反論の1つは、ユーザーがパケットドロップレートが高いととにかく電話を切るため、最低許容レートを実施することには意味がないということです。ユーザーは電話を切るかもしれませんが、数分以上の短い期間を待っている間、たまにノイズが得られるように、話し続けるだけかもしれません。別の反論は、永続的なパケットドロップレートが設定された最小送信レートの許容パケットドロップレートを超える場合、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.
次のセクションでは、それぞれ4.75と64 kbpsの最小送信率でVoIPフローについて上記のアプローチを示し、実際にはそのようなアプローチがVoIPトラフィックに対してそれほど負担がかからないように見えることを示しています。このアプローチは、VoIPのドロップ率が4.75 kbpsの最小送信率で40％を大幅に超えると、VoIPトラフィックが終了または中断することを意味します。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.
R = 0.1秒のRTTを使用した適応オーディオアプリケーションを考えてみましょう。これは、4.75 kbpsアプリケーションデータの最小送信率に適応し、1秒あたりM = 20パケットを送信します。この送信レートは、b = 1393 bpsのワイヤの送信レートに対して、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は、RTOセットとのTCP接続がRTTの2倍に経験されるパケットドロップレートを見て、PPRのTCP接続の対応する送信レートを示します。2番目の列は、標準の分析アプローチによって推定される送信速度を示し、3番目、4列、および5列目は、ランダムパケットドロップまたはマークを使用したシミュレーションからの平均送信率を示します。6番目の列は、4.8-リリースのFreeBSDマシンでの実験からの送信率を示します。分析的アプローチでは、RTTの倍数として表されるRTOが必要であり、表1はRTOセットの結果を2 RTTに示しています。シミュレーションでは、最小RTOがRTTの2倍に設定されています。詳細については、付録を参照してください。
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の送信速度と2 RTTへのRTOセットの場合、テーブル1は、分析アプローチが対応するパケットドロップレートを約50％で提供し、5番目の列のシミュレーションと6列目の実験はパケットを与えることを示しています。0.09 pprの送信率を維持するために、35％から40％の低下率。（4番目の列に示されているタイムスタンプを使用した参照TCP接続の場合、シミュレーションは55％のパケットドロップレートを与えて、送信率0.09 ppr。）を維持するために、送信レートとパケット間のTCPの関係を決定するための2つのアプローチのうち）ドロップレート、分析アプローチ、シミュレーションの使用は、付録で説明されている理由から、シミュレーションが最も現実的であると考えています。これは、40％のパケットドロップ率が、0.09 pprの平均送信率でTCP接続の場合に妥当であることを示唆しています。その結果、永続的なパケットドロップレートが40％を大幅に超える場合、0.1秒のRTTと最小送信レート4.75 kbpsのVoIP接続が終了または一時停止する必要があります。
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を送信することになります。ただし、0.1秒のTCP接続の最小RTOも想定しています。これは、この場合、少なくとも10 RTTのRTOを意味します。RTOのこの設定では、付録の表2を使用して、特定のパケットドロップレートの平均TCP送信率を決定します。表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と4.75 kbpsの最小送信レートを使用したVoIP接続の場合、永続的なパケットドロップレートが45％を超えた場合、VoIP接続は終了または一時停止する必要があります。
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のパケット送信率を検討してください。（これは、160バイトのデータパケットに相当し、パケットあたり20ミリ秒で。）ワイヤーの送信率は、ヘッダーを含むB = n 40m bpsまたは10000 bpsです。サイズp = 1460バイトのパケットとr = 0.1秒の往復時間を備えた送信率を持つTCP接続は、BR/（p 40）= 0.66 pprを送信します。表1の5番目の列から、2 RTTのRTOの場合、これは20〜25％のパケットドロップレートに対応します。[表1の4番目の列に示すように、細粒タイムスタンプを使用したTCP接続の場合、この送信速度は25％から35％のパケットドロップレートに対応します。]その結果、0.1のRTTとのVoIP接続SECおよび64 kbpsの最小送信率は、永続的なパケットドロップレートが25％を大幅に超える場合に終了または一時停止するために必要です。
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％のパケットドロップレートに対応します。64 kbpsの最小送信速度では、永続的なパケットドロップレートが30％を超えた場合、VoIP接続は終了または一時停止する必要があります。
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フロー間でかなり共有される可能性があります。
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.
輻輳を推定するための単純なヒューリスティックの1つは、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ミリ秒ですが、回復できません。理想的には、アプリケーションは30ミリ秒のパケットを必要とします。これがほとんどの音声コーデックが提供するものです。さらに、音声メディアストリームは、より低いデータレートでより大きな損失感度を示します。低データレートのコーデックは、より多くのエンドツーエンドの状態を維持し、その結果、一般に損失に対してより敏感です。
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トラフィックはそうではありません。ただし、このドキュメントは完全なプロトコル仕様ではないことを繰り返します。特に、UDPを介して実行されるアプリケーションがECNを使用するために安全になる前に、追加のメカニズムが必要になります。たとえば、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.
ブライアン・アダムソン、ラン・アトキンソン、フレッド・ベイカー、ジョン・クロウクロフト、クリストフ・ディオット、アラン・デュリック、ジェレミー・ジョージ、マーク・ハンドリー、オリオン・ホドソン、ジェフ・ヒューストン、エディ・コーラー、サイモン・レイネン、デビッド・マイヤー、ジャン・フランソワ・マール、コリン・パーキンス、ジョン・パーキンスピーターソン、マイク・ピアス、サイラス・シャウル、ヘニング・シュルツリンヌは、この文書に関するフィードバックをしています。（もちろん、これらの人々は必ずしもすべての文書に同意するわけではありません。）Ran AtkinsonとGeoff Hustonが文書のテキストに貢献しました。
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実験について、Alberto Medinaに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「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.、Westerlund、M.、Lakaniemi、A。and Q. Xie、 "リアルタイム輸送プロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）およびアダプティブマルチ - レートワイドバンド（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] ATKINSON、ISPリアリティチェック、IEPREPへのプレゼンテーション、55th IETF Meeting、2002年11月。URL「http://www.ietf.cnri.reston.va.us/proceedings/02Nov/219.htm＃スライド "。
[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] Deepak Bansal、Hari Balakrishnan、Sally Floyd、およびScott Shenker、ゆっくりと敏感な混雑制御アルゴリズムの動的な動作、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] Durham、D.、ed。、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R。and A. Sastry、「The Cops（Common Open Policy Service）Protocol」、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] Eddie Kohler、Mark Handley、Sally Floyd、およびJitendra Padhye、Datagram混雑制御プロトコル（DCCP）、インターネットドラフト作業中の2003年3月。「。
[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-interestメーリングリスト、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. Floyd、M。Handley、J。Padhye、J。Widmer、「ユニキャストアプリケーションの方程式ベースの渋滞制御」、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. FloydおよびR. Mahajan、高帯域幅の流れや骨材に対する保護のためのルータープリミティブ、インターネットドラフト（まだ提出されていません）。
[FWD] Free World Dialup, URL "www.pulver.com/fwd/".
[FWD]無料のWorld Dialup、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）、議事録、2002年11月、55回目のIETF会議。
[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. Jacobson、混雑回避と制御、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 JiangとHenning 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 JiangとHenning Schulzrinne、Bursty Loss、Nossdav、2002年のVoIP知覚品質に関するパケット損失修復方法の比較と最適化。
[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 Jiang、Kazummi Koguchi、およびHenning Schulzrinne、VoIPエンドポイントのQoS評価、ICC2003。
[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. Kang、L.J。Fransen、およびE.L.Kline、「デジタル音声通信用のマルチレートプロセッサ（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. KangおよびL.J. Fransen、「デジタル音声通信のためのマルチレートプロセッサ（MRP）の第2レポート」、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、「インターネットバックボーン上の音声通信の質の評価」、ネットワーキングに関するIEEE/ACMトランザクション、V。11N. 5、2003年10月。
[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] Joerg Widmer、Martin Mauve、Jan Peter Damm。適応不可能なフローの確率的輻輳制御。テクニカルレポート3/2001、マンハイム大学数学およびコンピューターサイエンス学科。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。Kurose、Modeling TCP Sultput：A Simple Model and Its Empirical Validation、Tech Report TF 98-008、U。Mass、1998年2月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[RFC896] Nagle、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group、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] Huston、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] Allman、M.、Balakrishnan、H。and S.、Floyd、「限定送信を使用した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] Ramakrishnan、K.、Floyd、S。およびD. Black、「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] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V。およびD. Stiliadis」PHB（PER-HOP行動）」、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] Handley、M.、Floyd、S.、Pahdye、J。およびJ. Widmer、「TCP Friendry Rate Control（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、Private Communication、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. Woodward、Speech Coding、Communications Research Group、サウサンプトン大学、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の平均送信レートを推定する標準的な方法は、[PFTK98]で推定されるTCP応答関数を使用することです。
S = 1/(sqrt(2p/3) + K min(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.
すべてのデータパケットに送信されるACKの場合、RTOはk*rttに設定されています。
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シミュレーターでは、再送信タイマーの最大バックオフは、UNBacked-Off値の64倍です。RFC 2988は、「少なくとも60秒である場合、RTOに最大値を配置できる」と指定しています。[TCPの実装は異なりますが、多くのTCP実装は、dropped 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）のもう1つの制限は、Reno 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).
以下の表は、式（1）のRTOセットと2 RTTに設定されたTCP接続の場合、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 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.
これらの推定値は、3番目、4列目、および5列目のシミュレーションと比較され、ECNを使用して、TCPのパケットドロップを微調整されたタイムスタンプを使用し、それぞれタイムスタンプなしのTCPのパケットドロップをドロップします。（シミュレーションスクリプトはhttp://www.icir.org/floyd/voip/simsから入手できます。）各シミュレーションは、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リリースのFreeBSDマシンを使用した実験のRTTあたりのパケットの平均送信率を示しています。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のパケットドロップレートPの関数としてレートSを2 RTTに設定し、RTTあたりのパケットのSを送信します。
The table below shows the average sending rate S, for TCP connections with the RTO set to 10 RTT.
以下の表は、RTOを10 RTTに設定した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のパケットドロップレートの関数としてのレートを10 RTTに設定し、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
バーナード・アボバ・ハラルド・アルベスランド（IETFチェア）ロブ・オーストイン・レスリー・ダイグル（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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。