RFC3714 日本語訳
3714 IAB Concerns Regarding Congestion Control for Voice Traffic inthe Internet. S. Floyd, J. Kempf, Eds.. March 2004. (Format: TXT=81368 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Floyd, Ed. Request for Comments: 3714 J. Kempf, Ed. Category: Informational March 2004
ワーキンググループのS.フロイド、エドをネットワークでつないでください。コメントのために以下を要求してください。 3714 エドJ.ケンフ、カテゴリ: 情報の2004年3月
IAB Concerns Regarding Congestion Control for
Voice Traffic in the Internet
インターネットの音声トラヒックのための輻輳制御に関するIAB心配
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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心配について議論します。 これらの関心は、公正、ユーザ品質と関係があって、混雑という危険で崩れます。 この状況が近いうちにあまり変化しないという関心はインターネット、および見込みが、Service(QoS)展開の広範囲のQualityの不在の観点から特に関連しています。 このドキュメントは、QoSサポートでインターネットプロトコルの上のVoiceのための展開経路の周りの少しの推薦状も(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 問題の可能性に関する例。 . . . . . . . . . . . 4 3. Persistent、High Drop RatesはなぜProblemですか? . . . . . . . . 6 3.1. 混雑崩壊。 . . . . . . . . . . . . . . . . . . 6 3.2. ユーザ品質. . . . . . . . . . . . . . . . . . . . . . 7 3.3。 公正の無定形の問題。 . . . . . . . . . . . 8 4. IETFでの現在の努力。 . . . . . . . . . . . . . . . . . 10 4.1. RTP。 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. TFRC. . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3。 DCCP. . . . . . . . . . . . . . . . . . . . . . . . . . 12
Floyd & Kempf Informational [Page 1] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[1ページ]のRFC3714IAB心配は2004年3月に制御されます。
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
4.4. 適応型のレートオーディオコーデック. . . . . . . . . . . . . . . 12 4.5。 微分されたサービスと関連した話題. . . . . . . 13 5。 最小の許容できる送付レート. . . . . . . . . . 13 5.1を算定します。 4.75キロビット毎秒でMinimum Sending Rate.175.2にRatesを落としてください。 64キロビット毎秒でMinimum Sending Rate.185.3にRatesを落としてください。 問題を開いてください。 . . . . . . . . . . . . . . . . . . . . . . 18 5.4. 簡単なヒューリスティック. . . . . . . . . . . . . . . . . . . 19 6。 VoIPシステム. . . . . . . . . . . . . . . . . . 20 7における規制。 結論と推薦。 . . . . . . . . . . . . . . . 20 8. 承認. . . . . . . . . . . . . . . . . . . . . . . 21 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1。 引用規格. . . . . . . . . . . . . . . . . . 21 9.2。 有益な参照. . . . . . . . . . . . . . . . . 22 10。 付録--発信はパケット滴. . . . . . . . . . 26 11をみなします。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 29 12. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 29 13. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 30 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 31
1. Introduction
1. 序論
While many in the telephony community assume that commercial VoIP service in the Internet awaits effective end-to-end QoS, in reality voice service over best-effort broadband Internet connections is an available service now with growing demand. While some ISPs deploy QoS on their backbones, and some corporate intranets offer end-to-end QoS internally, end-to-end QoS is not generally available to customers in the current Internet. Given the current commercial interest in VoIP on best-effort media connections, it seems prudent to examine the potential effect of real time flows on congestion. In this document, we perform such an analysis. Note, however, that this document is not making any recommendations about deployment paths for VoIP in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. This document is also not discussing signalling connections for VoIP. However, voice traffic is in fact occasionally deployed as best effort traffic over some links in the Internet today, and we expect this occasional deployment to continue. This document expresses our concern over the lack of effective end-to-end congestion control for this best-effort voice traffic.
電話共同体の多くが、インターネットでの商業VoIPサービスが終わりから終わりへの有効なQoSを待つと仮定しますが、現在、高まる需要でベストエフォート型ブロードバンドインターネット回線の上の声のサービスはほんとうは、利用可能なサービスです。 いくつかのISPが彼らの背骨の上でQoSを配備します、そして、いくつかの企業イントラネットが内部的に終わりから終わりへのQoSを提供しますが、現在のインターネットの顧客には、一般に、終わりから終わりへのQoSは利用可能ではありません。 ベストエフォート型メディア接続でのVoIPへの現在の商業関心を考えて、リアルタイムの流れの混雑への潜在的効果を調べるのは慎重に思えます。 本書では、私たちはそのような分析を実行します。 しかしながら、このドキュメントが展開経路の周りでQoSサポートで少しの推薦状もしないで、VoIPのためにまたベストエフォート型サービスを当てにすることができると主張しないことであることに注意して、VoIPにおいて、許容している性能を与えてください。 また、このドキュメントは、VoIPのために接続に合図するとは議論していません。 しかしながら、いくつか上のベストエフォート型交通が今日、インターネットでリンクして、私たちが、この時々の展開が続けていると予想するように事実上、音声トラヒックは時折配備されます。 このドキュメントはこのベストエフォート型音声トラヒックのための終わりからエンドへの有効な輻輳制御の不足に関する私たちの心配を述べます。
Assuming that VoIP over best-effort Internet connections continues to gain popularity among consumers with broadband connections, the deployment of end-to-end QoS mechanisms in public ISPs may be slow. The IETF has developed standards for QoS mechanisms in the Internet [DIFFSERV, RSVP] and continues to be active in this area [NSIS,COPS]. However, the deployment of technologies requiring change to the Internet infrastructure is subject to a wide range of commercial as
ベストエフォート型インターネット接続の上のVoIPが、ブロードバンドの接続で人気を消費者に獲得し続けていると仮定する場合、公共のISPにおける、終わりから終わりへのQoSメカニズムの展開は遅いかもしれません。 IETFはインターネット[DIFFSERV、RSVP]のQoSメカニズムの規格を開発して、この領域[NSIS、COPS]でずっとアクティブです。 しかしながら、インターネット基盤への変化を必要とするのがさまざまなコマーシャルを条件としている技術の展開
Floyd & Kempf Informational [Page 2] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[2ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
よくインフラストラクチャへの変化なしで配備できる技術的な問題、および技術として、展開の速度における相当の便宜を楽しんでください。 RFC2990はインターネット[RFC2990]でのQoS構造の展開への技術的難関のいくつかについて概説します。 速く成長しているアプリケーションのサポートを提供する一時的な方策は、しばしば、採用されて、需要を満たすところにより破壊的な技術の遍在している展開に対する圧力が減少するほどうまくいっています。 インフラストラクチャの遅い展開のIKEとIPsecサポートに、IPv6、IPマルチキャストを含むQoSメカニズムかグローバルなPKIの遅い展開と同様の多くの例があります。
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測定は個々の混雑しているリンクにおけるVoIP交通へのただ一つのホップか縁だけのQoSメカニズムを含んでいます、ケーブルアクセスネットワークのための縁だけのQoSメカニズムなどのように。 QoSのそのような地方のフォームはベストエフォート型VoIPのある部分に混雑からの交通を保護するのにかなり成功しているかもしれません。 しかしながら、終わりから終わりとのVoIP接続において、QoSのこれらの地方のフォームは直接目に見えません。 ベストエフォート型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
混雑している最も良い努力ネットワークの上のIP電話技術の可能な展開を考えて、いくつかの関心が終わりからエンドへの輻輳制御を練習しないリアルタイムの音声トラヒックにおける急速な成長による混雑崩壊の可能性に関して起こります。 このドキュメントはベストエフォート型ネットワークで最も良い努力電話交通における急速な成長から起こる混雑崩壊の公正、ユーザ品質、および危険に関するいくつかの心配を高めます。 そして私たちが最小の送付レートを持っている最も良い努力電話接続を考える。
Floyd & Kempf Informational [Page 3] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[3ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
それは、経路で少なくとも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.
本書では公正に関する心配と混雑崩壊の危険は電話交通に適用するだけではなく、最小の送付レートでビデオ交通と他のベストエフォート型リアルタイムの交通にも適用されます。 RFC2914は既に、ベストエフォート型交通が終わりからエンドへの輻輳制御[RFC2914]を必要とするというポイントを指摘します。 オーディオ交通がそのような低率でビデオと他のリアルタイムの交通に比例して発信するので、時々オーディオ交通が終わりからエンドへの輻輳制御を必要としないと主張されます。 したがって、関心は本書では一般的ですが、ドキュメントはベストエフォート型オーディオ交通の特定の問題に焦点を合わせます。
Feedback can be sent to the IAB mailing list at iab@ietf.org, or to the editors at floyd@icir.org and kempf@docomolabs-usa.com. Feedback can also be sent to the end2end-interest mailing list [E2E].
iab@ietf.org のIABメーリングリスト、または、 floyd@icir.org と kempf@docomolabs-usa.com のエディタにフィードバックを送ることができます。 また、end2end-関心メーリングリスト[2EのE]にフィードバックを送ることができます。
2. An Example of the Potential for Trouble
2. 問題の可能性に関する例
At the November, 2002, IEPREP Working Group meeting in Atlanta, a brief demonstration was made of VoIP over a shared link between a hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya. The link ran over the typical uncongested Internet backbone and access links to peering points between either endpoint and the Internet backbone. The voice quality on the call was very good, especially in comparison to the typical quality obtained by a circuit-switched call with Nairobi. A presentation that accompanied the demonstration described the access links (e.g., DSL, T1, T3, dialup, and cable modem links) as the primary source of network congestion, and described VoIP traffic as being a very small percentage of the packets in commercial ISP traffic [A02]. The presentation further stated that VoIP received good quality in the presence of packet drop rates of 5-40% [AUT]. The VoIP call used an ITU-T G.711 codec, plus proprietary FEC encoding, plus RTP/UDP/IP framing. The resulting traffic load over the Internet was substantially more than the 64 kbps required by the codec. The primary congestion point along the path of the demonstration was a 128 kbps access link between an ISP in Kenya and several of its subscribers in Nairobi. So the single VoIP call consumed more than half of the access link capacity, capacity that is shared across several different users.
2002年11月、アトランタで会合するIEPREP作業部会では、アトランタ(ジョージア)(米国)のホテルの部屋とナイロビ(ケニア)との共有されたリンクの上にVoIPで簡潔なデモンストレーションをしました。 リンクはどちらかの終点とインターネットの基幹の間のじっと見るポイントへの典型的な非充血しているインターネットの基幹とアクセスリンクをひきました。 呼び出しでの音声の品質は非常に良かったです、特にナイロビとのサーキットで切り換えられた呼び出しで得られた典型的な品質との比較で。 デモンストレーションに伴ったプレゼンテーションは、アクセスリンク(例えば、DSL、T1、T3、ダイアルアップ、およびケーブルモデムリンク)をネットワークの混雑の一次資料と説明して、商業ISP交通[A02]でVoIP交通がパケットの非常にわずかな百分率であると記述しました。 プレゼンテーションは、VoIPが5-40%[AUT]のパケット低下率があるとき良質の状態で受信したとさらに述べました。 VoIP呼び出しはITU-T G.711コーデック、独占FECコード化、およびRTP/UDP/IP縁どりを使用しました。 インターネットの上の結果として起こるトラヒック負荷は64キロビット毎秒がコーデックが必要であるというよりも実質的に多かったです。デモンストレーションの経路に沿った第一の混雑ポイントはケニアのISPとナイロビのその数人の加入者との128キロビット毎秒アクセスリンクでした。 それで、ただ一つの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
このネットワーク・コンフィギュレーションがVoIPには、特に良いものでないことに注意してください。 そして、特に何らかの声1500バイトの典型的なパケットサイズとのリンクの上にTCPを走らせるデータサービスがあれば
Floyd & Kempf Informational [Page 4] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[4ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
パケットによる遅らせられて、追加90msであり結局の増加がどれで遅れを150のITUによるお勧めの時間より上まで終わらせるかもしれないかが[G.114]をスピーチ交通にmsするということであるかもしれません。 これはユーザにとって、めぼしい遅れをもたらすでしょう、遅れ、およびしたがって、呼び出し品質の増加する変化で、bursty TCP交通が来て、行くとき。 また、ナイロビなどの高い遅れが前のパラグラフから既に呼んだ呼び出しのために、競争しているTCP交通による増加するジターは受信機のジターバッファに関する要件を増加させます。それにもかかわらず、混雑しているベストエフォート型リンクの上のVoIP用法は近い将来増加しそうです、「キャリヤーのクラス」サービスによるVoIPの優れた性能にかかわらず。 音声の品質における結果として起こるユーザ知覚可能な退行に伴う40%の低下率に直面して128Kbpsアクセスリンクの半分を消費して、64Kbpsで送付パケットに固執するベストエフォート型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時間後で、そして、これはちょうど混雑崩壊を避けるのが重要である時です。
Floyd & Kempf Informational [Page 5] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[5ページ]のRFC3714IAB心配は2004年3月に制御されます。
Best-effort traffic in the Internet does not include mechanisms for call acceptance or rejection. Instead, a best-effort network itself is largely neutral in terms of resource management, and the interaction of the applications' transport sessions mutually regulates network resources in a reasonably fair fashion. One way to bring voice into the best-effort environment in a non-disruptive manner is to focus on the codec and look at rate adaptation measures that can successfully interoperate with existing transport protocols (e.g., TCP), while at the same time preserving the integrity of a real-time, analog voice signal; another way is to consider codecs with fixed sending rates. Whether the codec has a fixed or variable sending rate, we consider the appropriate response when the codec is at its minimum data rate, and the packet drop rate experienced by the flow remains high. This is the key issue addressed in this document.
インターネットのベストエフォート型交通は呼び出し承認か拒絶のためのメカニズムを含んでいません。 代わりに、ベストエフォート型ネットワーク自体は資源管理で主に中立です、そして、アプリケーションの輸送セッションの相互作用は合理的に公正なファッションで互いにネットワーク資源を規制します。 コーデックに焦点を合わせて、同時にリアルタイムで、アナログの音声信号の保全を保持する間に既存のトランスポート・プロトコル(例えば、TCP)で首尾よく共同利用できるレート適合測定を見ます非破壊的な方法でベストエフォート型環境に声を運び込む1つの方法がことである。 別の方法は固定送付レートがあるコーデックを考えることです。 最小のデータ信号速度にコーデックがあるとき、コーデックに修理されたか可変な送付レートがあるか否かに関係なく、私たちは適切な応答を考えます、そして、流れによって経験されたパケット低下率は高いままで残っています。 これは本書では記述された主要な問題です。
3. Why are Persistent, High Drop Rates a Problem?
3. Persistent、High Drop RatesはなぜProblemですか?
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は自己に検出されていた状態で混雑であるなら発信するaでは、接続がパケットのレートを低下させる2つの終わりがあるそうを修正します。 下のセクションで、私たちはしつこくて、高いパケット低下率によって引き起こされた問題のいくつかについて議論します。
3.1. Congestion Collapse
3.1. 混雑崩壊
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
RFC2914で説明されるように、混雑崩壊はしつこくて、高いパケット低下率[RFC2914]を持っている複数の混雑しているリンクを横断する流れでネットワークで起こります。 これらのパケットが後で落とされるだけであるので、このシナリオでは、特に、混雑しているリンクに注入されるパケットは不十分な帯域幅を浪費します、川下の混雑しているリンクの上に。 混雑崩壊が起こるなら、すべての交通が徐行に遅くなります、そして、だれも許容できるパケット配信か許容性能を得ません。 このフォームの混雑崩壊が複数の混雑しているリンクを横断する流れのためだけに起こることができるので、混雑崩壊はaです。
Floyd & Kempf Informational [Page 6] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[6ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
VoIPの潜在的な問題はいつ、DSLなどの混雑しているブロードバンドの接続にはVoIP呼び出しの両端があるか、そして、呼び出しがいつ鬱血した背骨を横断するか、そして、大洋横断のリンクをネットワークでつなぎます。
3.2. User Quality
3.2. ユーザ品質
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個の混雑しているリンクだけを横断するネットワークシナリオが上であると考えてください。 例えば、128Kbpsを共有するN VoIP流れが少なくとも64Kbpsを送る各流れにリンクされると想像してください。 簡単さには、128Kbpsリンクが唯一の混雑しているリンクであると仮定してください。そうすれば、N VoIP呼び出し以外のそのリンクの上に交通が全くありません。 また、私たちは当分沈黙抑圧のためFECとパケットのヘッダーか、減少している帯域幅に電話交通で使用される(70%としてしばしば見積もられています)余分な帯域幅を無視するつもりです。 また、私たちは双方向のVoIP呼び出しを構成する2つの流れ(各指示あたり1つ)が実際には経路のいくつかのリンクの上の負荷に加えることができるという事実を無視します。 これらの簡易型の仮定を考えて、そのリンクへの到着率は少なくともN*64Kbpsです。 実際に進められた交通が高々2*64Kbps(リンク帯域幅)であるので、少なくとも到着交通の(N-2)*64Kbpsを落とさなければなりません。 したがって、少なくとも到着交通の(N-2)/Nの部分は落とされます、そして、各流れはリンク帯域幅の部分1/Nを平均的に受けます。 注意する重要なポイントは低下が手当たりしだいに現れるということです、いかなる他のもいいえ1、流動がユーザに対する、より良質のサービスを提示すると統計的に予想できるように。 したがって、みんなの音声の品質に苦しみます。
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情報をもたらさないで、その結果、より少ない帯域幅をもたらすべきです、その結果、さらにさえスループットを改良します。 文学[JS00、JS02、JS03、MTK03]で詳細にFECの面前でVoIPにおける遅れとパケット損失の影響を調査してあります。 1つの経験則はパケット損失率が20%を超えているとき、VoIPのオーディオ音質が有用性を超えて下げられるということです、一部損失[S03]のbursty自然のため。 私たちはパケット損失率が何らかの限界を超えていると実際にはVoIPユーザが、ハングアップする傾向があるかどうかに関する測定研究を意識していません。
Floyd & Kempf Informational [Page 7] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[7ページ]のRFC3714IAB心配は2004年3月に制御されます。
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のそのままな輻輳制御応答を考慮に入れることによって、次の小区分で議論していた状態でうまくいきます。
3.3. The Amorphous Problem of Fairness
3.3. 公正の無定形の問題
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]はリンクを共有します、混雑で制御されたトラフィックの送付レートがそれらの流れによって経験されたパケット低下率によって測定されている状態で。 前項のように、N VoIP接続が128Kbpsリンクでそれぞれ64Kbpsを送ります、混雑しているリンクで少なくとも(N-2)/Nのパケット低下率をもたらして。 競争しているTCP流れは同じパケット低下率になるでしょう。 しかしながら、同じパケット低下率になるTCP流動はかなり64Kbpsを送るでしょう。 だれがどんな量の帯域幅、VoIP交通を得るかに関する観点から、TCP交通入らないようにするのは来ています。
Of course, this is only one way to look at fairness. The relative fairness between VoIP and TCP traffic can be viewed several different ways, depending on the assumptions that one makes on packet sizes and round-trip times. In the presence of a fixed packet drop rate, for example, a TCP flow with larger packets sends more (in Bps, bytes per second) than a TCP flow with smaller packets, and a TCP flow with a shorter round-trip time sends more (in Bps) than a TCP flow with a larger round-trip time. In environments with high packet drop rates, TCP's sending rate depends on the algorithm for setting the retransmit timer (RTO) as well, with a TCP implementation having a more aggressive RTO setting sending more than a TCP implementation having a less aggressive RTO setting.
もちろん、これは単に公正を見ることにおいて一方通行です。 VoIPとTCP交通の間の相対的な公正はいくつかの見られた異なった道であるかもしれません、1つがパケットサイズと往復の回でする前提によって。 固定パケット低下率があるとき例えば、より大きいパケットがあるTCP流動がTCP流動より小さいパケットと共に発信して(Bpsの1秒あたりのバイト)、より短い往復の間があるTCP流動は、より大きい往復の時間があるTCP流動より発信します(Bpsで)。 高いパケット低下率がある環境で、TCPの送付レートをまた、再送信タイマ(RTO)を設定するためにアルゴリズムに依存します、より攻撃的なRTOがそれほど攻撃的でないRTOにTCP実現より発信するのにセットさせるTCP実現で。
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のms[RTTWeb]になるということです。
Floyd & Kempf Informational [Page 8] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[8ページ]のRFC3714IAB心配は2004年3月に制御されます。
(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.
(これは衛星中継を含んでいません。) aは正準でした。aとして、なってください、そこであるなら親類が公正であると判断するのにおいて往復です、その範囲の中にそれはなければならないでしょう。 ただ一つの代表している往復の時間がないとき、この紙の仮定は同往復の時間との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.
同様に、RFC2988はTCPのRTOを設定するためのTCPのアルゴリズムを指定しますが、どんな最小のRTOに、正準な値もありません、そして、最小のRTOは高い混雑[RFC2988]の時代にずっしりとTCPの送付レートに影響します。 調節して、RTTVARのために。RFC2988は、TCPのRTOがSRTT+4*RTTVARに用意ができなければならないと指定します、SRTTのために平坦である、往復、最近の往復の時間測定値の平均偏差。 RFC2988は、RTO “SHOULD"には1秒の最小値があるとさらに述べます。 しかしながら、それが珍しくない、相対的な公正を考えることにおけるこのドキュメントの目的でありTCP実現がa最小のRTOを100原稿Forと同じくらい低くする習慣では、私たちが仮定するつもりである、100原稿のa最小の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,
公正で時々提起された別々のクレームはベストエフォート型VoIP交通が本来の、より重要なそんなにもう一方ベストエフォート型の交通(例えば、ウェブサーフィン、ピアツーピア交通、またはマルチプレーヤーゲーム)であり、したがって、高い混雑の時代に帯域幅の、より大きいシェアに値するということです。 私たちの仮定は本書ではTCP交通が、メールメッセージを押すのを含んでいるということです。
Floyd & Kempf Informational [Page 9] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[9ページ]のRFC3714IAB心配は2004年3月に制御されます。
business documents, and emergency information downloaded from web pages, as well as the more recreational uses cited above. Thus, we do not agree that best-effort VoIP traffic should be exempt from end-to-end congestion control due to any claims of inherently more valuable content. (One could equally logically argue that because email and instant messaging are more efficient forms of communication than VoIP in terms of bandwidth usage, as a result email and instant messaging are more valuable uses of scarce bandwidth in times of high congestion.) In fact, the network is incapable of making a judgment about the relative user value of traffic. The default assumption is that all best-effort traffic has equal value to the network provider and to the user.
業務用書類、ウェブページからダウンロードされた非常時の情報、および上で引用されたよりレクリエーションの用途。 したがって、私たちは、ベストエフォート型VoIP交通が本来より貴重な内容のどんなクレームによる終わりからエンドへの輻輳制御によっても免除されているべきであるのに同意しません。 (1つは、その結果、メールとインスタントメッセージングが帯域幅用法による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が彼らが選ぶどんな方法でも交通のクラスへの混雑しているリンクにおける帯域幅を割り当てる権利に挑戦しないことに注意します。 (例えば、ネットワークにおける帯域幅がいくつかにおけるピアツーピア交通で使用した管理者レート限界リンク、また、その帯域幅を確実にするのも他のクラスの交通に利用可能です。) この議論は、クラス全員のベストエフォート型交通が終わりからエンドへの輻輳制御によって免除されている理由が全くないと単に主張します。
4. Current efforts in the IETF
4. IETFでの現在の努力
There are four efforts currently underway in IETF to address issues of congestion control for real time traffic: an upgrade of the RTP specification, TFRC, DCCP, and work on audio codecs.
リアルタイムの交通のための輻輳制御の問題を記述するために、現在IETFの進行中の4つの努力があります: オーディオコーデックにおけるRTP仕様、TFRC、DCCP、および仕事のアップグレード。
4.1. RTP
4.1. RTP
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:
RFC1890(AudioとVideo ControlのためのオリジナルのRTP Profile)は輻輳制御[RFC1890]について議論しません。 [RFC3551]が輻輳制御について議論する「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」セクション2の改訂されたドキュメント。 [RFC3551]は以下を言います:
"If best-effort service is being used, RTP receivers SHOULD
monitor packet loss to ensure that the packet loss rate is within
acceptable parameters. Packet loss is considered acceptable if a
TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured
on a reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or
the number of layers subscribed for a layered multicast session),
or by arranging for a receiver to leave the session if the loss
rate is unacceptably high."
「ベストエフォート型サービスが利用されているなら、RTP受信機SHOULDは許容できるパラメタの中にパケット損失率があるのを保証するためにパケット損失をモニターします。」 同じネットワーク経路と同じネットワーク状態を経験することの向こう側のTCP流動が妥当なスケールで測定された少なくとも流れが実現しているRTPである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 「通信速度(層の数は層にされたマルチキャストセッションのために申し込まれた)を適合させるために混雑制御機構を実行するか、または損失率が容認できないほど高いなら受信機がセッションを出発するように手配することによって、この状態を満たすことができます。」
Floyd & Kempf Informational [Page 10] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[10ページ]のRFC3714IAB心配は2004年3月に制御されます。
"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との比較は、まさに指定できませんが、スケールとスループットにおける1「桁」比較として意図します。」 TCPスループットが測定されるスケールは接続の往復の時間です。 「本質では、この要件は、1桁以内で任意に帯域幅を消費して、TCPと公正に競争しないベストエフォート型インターネットでアプリケーション(RTPを使用するか、いかなる他のトランスポート・プロトコルも)を配備するのが許容できないと述べます。」
Note that [RFC3551] says that receivers "SHOULD" monitor packet loss. [RFC3551] does not explicitly say that the RTP senders and receivers "MUST" detect and respond to a persistent high loss rate. Since congestion collapse can be considered a "danger to the Internet" the use of "MUST" would be appropriate for RTP traffic in the best-effort Internet, where the VoIP traffic shares a link with other traffic, since "danger to the Internet" is one of two criteria given in RFC 2119 for the use of "MUST" [RFC2119]. Different requirements may hold for a private best-effort IP network provisioned solely for VoIP, where the VoIP traffic does not interact with the wider Internet.
[RFC3551]が、受信機“SHOULD"がパケット損失をモニターすると言うことに注意してください。 [RFC3551]は、RTP送付者と受信機“MUST"がしつこい高い損失率まで検出して、応じると明らかに言いません。 「インターネットへの危険」であると混雑崩壊を考えることができるので、VoIP交通が他の交通とのリンクを共有するベストエフォート型インターネットのRTP交通に、“MUST"の使用は適切でしょう、「インターネットへの危険」が“MUST"[RFC2119]の使用のためにRFC2119で与えられた2つの評価基準の1つであるので。 異なった要件は唯一VoIPのために食糧を供給された私設のベストエフォート型IPネットワークに当てはまるかもしれません。そこでは、VoIP交通が、より広いインターネットと対話しません。
4.2. TFRC
4.2. TFRC
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:
RFC3267で言及されるように、方程式ベースの輻輳制御はVoIPのための可能性の1つです。 TCP Friendly Rate Control(TFRC)はIETFで標準化された方程式ベースの混雑制御機構です。 TFRC仕様、「TCPの好意的なレートは以下を制御(TFRC)」。 「Specificationについて議定書の中で述べ」て[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に利用可能などんな草稿も残念ながらありませんが、数人の研究者がまだこれらの問題に取り組んでいます。
Floyd & Kempf Informational [Page 11] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[11ページ]のRFC3714IAB心配は2004年3月に制御されます。
4.3. DCCP
4.3. DCCP
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].
データグラムCongestion Controlプロトコル(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には、現在、2Congestion Control IDentifiersかCCIDsがあります。 これらは、TCPのような輻輳制御のためのCCID2とTFRC輻輳制御のためのCCID3です。 TFRC-PSが利用可能になって、標準化過程に直面しているとき、私たちは、DCCPが新しいCCIDを作成すると予想するでしょう、CCID4、TFRC-PS輻輳制御による使用のために。
4.4. Adaptive Rate Audio Codecs
4.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].
RFC3267は使用のためにAdaptive Multi-レート(AMR)とAdaptive Multi-レートWideband(AMR-WB)オーディオコーデック[RFC3267]でRTPペイロード形式について説明します。 AMRコーデックは、音声符号化が20個のmsスピーチフレームに実行されている状態でビット伝送速度4.75〜12.2キロビット毎秒を持っている8つの音声符号化モードを支持して、沈黙の期間、通信速度を減少させることができます。 RFC3267で指定されたペイロード形式は、パケット損失に対して丈夫さをいくらか増加させるように前進型誤信号訂正(FEC)とフレームインターリービングを含んでいます。 AMRコーデックは第三世代(3G)セルラ方式のための義務的なコーデックとしてThird Generation Partnership Project(3GPP)によって選ばれました、そして、RFC3267はRFC3267で指定されたRTPペイロード形式を使用するAMRかAMR-WBアプリケーションが輻輳制御を使用することを勧めます、どんな特定のメカニズムもお勧めがではありませんが。 リアルタイムに適した混雑制御機構に関する例が流れるとき[FHPW00]、RFC3267は「ユニキャストアプリケーションのための方程式ベースの輻輳制御」を与えます。
Floyd & Kempf Informational [Page 12] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[12ページ]のRFC3714IAB心配は2004年3月に制御されます。
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個のmsフレームへの13.33キロビット毎秒か20個のmsフレームへの15.20キロビット毎秒のペイロードビット伝送速度を持っています。
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(Interactive VOice eXchange)[IVOX]にあります、追加変動金利コーデックを加える計画で。 例えば、LPC2400(通称LQ2400)は「沈黙検出」を可能にする増進がある2400年のビーピーエスのLPCのベースのコーデックです。 2400年のビーピーエスコーデックには「わずかなロボットの品質」[A03](パケット損失の追加複雑ささえのない)があると報告されます。 コーデックが[KFK79、KF82]で説明したより古い多速度は2つのレート、2.4キロビット毎秒、および9.6キロビット毎秒で働いて、高められた品質のために、より高いビット伝送速度で任意に追加「残り」のビットを送ることができるLPCコーデックです。
Off-the-shelf ITU-T vocoders such as G.711 were generally designed explicitly for circuit-switched networks and are not as well-adapted for Internet use, even with the addition of FEC on top.
すぐ入手できるITU-tボコーダ、G.711は一般に、回路交換ネットワークのために明らかに設計されて、インターネットの利用のためによく適合するようにないFECの添加さえ先端にあるそのようなもの。
4.5. Differentiated Services and Related Topics
4.5. 微分されたサービスと関連した話題
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.
Differentiated Services作業部会[DIFFSERV](2003年に結論を下した)はIPv4とIPv6 Headers[RFC2474]でDifferentiated Services Field(DS Field)の規格を完成しました、いくつかの1ホップあたりの推進の振舞い[RFC2597、RFC3246]を含んでいて。 Signaling作業部会[NSIS]におけるNext StepsはQoSのために最適化された合図プロトコルを開発しています、一部Resource予約Setupプロトコル作業部会[RSVP]の以前の仕事に基づきます。 私たちはこれらについて議論しません、そして、このドキュメントはいくつか上のベストエフォート型交通が充血したので運ばれるかもしれないそのVoIP交通だけに関係があって以来のさらにこのドキュメントにおける関連する努力はインターネットでリンクされます。
5. Assessing Minimum Acceptable Sending Rates
5. 最小の許容できる送付レートを算定します。
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ドキュメントに示されるように、唯一の歓迎すべき返答は損失率が現在の送付レートに比例して容認できないほど持続して高く、ベストエフォート型アプリケーションが送付レートを下げることができないならその流れが、そのリンクを転送するのを中止することです。 マルチキャストセッションのために、マルチキャストグループから引き下がる受信機はこれを達成できました。 ユニキャストセッションのために、少なくともしばらく終わるユニキャスト接続はこれを達成できました。
Floyd & Kempf Informational [Page 13] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[13ページ]のRFC3714IAB心配は2004年3月に制御されます。
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?
私たちは最小の送付レートのために以下の方法で問題声明を定式化できます。 1秒あたりのパケットにMをアプリケーションデータ、発信のN Bps(1秒あたりのバイト)の最小の送付レートまで適合させることができるベストエフォート型の、そして、適応型のオーディオアプリケーションを考えてください。 混雑のため終わるか、または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ではなく、2番目の(bps)あたりの帯域幅にコネであることが気前よく、循環するか、またはパケットで2番目の(pps)単位でそうすると思います。 ネットワークにおける制限が帯域幅にあるなら、これは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にあるとき適切にこたえることができるトランスポート・プロトコルを持つだろうことですが、そのような理想は達成しにくいです。 そのような理想を達成できるまで電話交通のための輻輳制御の展開を遅らせたいと思わないでしょう。 さらに、私たちは、現在のTCP混雑制御機構がppsの逆の経路に沿って制限があるところで環境で自分たちでそれほど効果的でないことに注意します。 TCPメカニズムは大きいデータ・パケットを使用するために動機を提供しますが、TCPは逆の経路における小さい確認応答パケットの流れのための少しの有効な混雑制御機構も含んでいません。 上の議論を考えて、ppsでというよりむしろBpsでの考慮におけるネットワーク制限が電話交通の最小の送付速度であると仮定するように私たちにとって許容できるように思えます。
Floyd & Kempf Informational [Page 14] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[14ページ]のRFC3714IAB心配は2004年3月に制御されます。
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のアプリケーションデータ送付レートはN+40Bのワイヤ=MのBpsで送付レートに翻訳されます。 アプリケーションが追加FEC(前進のError Correction)を使用するなら、また、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のデータ・パケットとの同等なレートTCP接続がバイトとR秒の往復の時間であると考えてください。 ヘッダーサイズを考慮に入れて、B Bpsのワイヤの送付レートとのそのようなTCP関係は、発信B/(P+40)pps、または同等にBR/(P+40)ppr(往復の時間あたりのパケット)です。
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 Bpsのワイヤの最小の送付レートであるなら、アプリケーションかトランスポート・プロトコルが、いつ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つの答えは、pprのTCP接続の送付速度がBpsのワイヤの同じレートで発信するのがわかって、conformant TCP接続が同じしつこい低下率Dに従ったその送付レートの近くで送付レートを維持できるかどうか決定するのにTCPレスポンス関数を使用することです; VoIP接続の送付速度がconformant 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.
さらに、アプリケーションが作動するためにネットワークから最小のサービスレベルを必要として、そのサービスレベルが一貫して実現されないなら、アプリケーションは、発信を終えるべきであるか、または中断させるべきです。
Floyd & Kempf Informational [Page 15] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[15ページ]のRFC3714IAB心配は2004年3月に制御されます。
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接続の利益を得ないということです。 これは虚偽です、競争しているTCPとVoIP交通がこれらのVoIP接続の終了でいくらかの進歩をすることができるかもしれないので。
In the next section, we illustrate the approach outlined above for VoIP flows with minimum sending rates of 4.75 and 64 kbps respectively, and show that in practice such an approach would not seem too burdensome for VoIP traffic. This approach implies that the VoIP traffic would terminate or suspend when the packet drop rate significantly exceeds 40% for a VoIP flow with a minimum sending rate of 4.75 kbps. If VoIP is to deliver "carrier quality" or even near "carrier quality" on best-effort links, conditioning deployment on the ability to maintain maximum sending rates during periods of persistent packet drops rates exceeding 40% does not suggest a service model that will see widespread acceptance among consumers, no matter what the price differential. Good packet throughput is vital for the delivery of acceptable VoIP service.
次のセクションでは、私たちは実際にはそのようなアプローチがそうするVoIP交通においてあまりに重荷になるように見えない最小限がそれぞれ4.75と64キロビット毎秒のレートを送るVoIP流れ、およびショーのために上に概説されたアプローチを例証します。 このアプローチは、VoIP交通がいつを終えるか、または中断させるかを含意します。パケット低下率は4.75キロビット毎秒の最小の送付レートに従ったVoIP流動のために40%をかなり超えています。 VoIPがベストエフォート型リンクの上に「キャリヤー品質」か近い「キャリヤー品質」さえ渡すつもりであるなら、最大の発信が、しつこいパケット滴の期間レートが上回っている40%であると評定すると主張する能力を展開を条件とさせるのは消費者の中で広範囲の承認を見るサービスモデルを示しません、価格格差が何であっても。 許容できるVoIPサービスの配送に、良いパケット効率は重大です。
For a VoIP flow that stops sending because its minimum sending rate is too high for the steady-state packet drop rate, we have not addressed the question of when a VoIP flow might be able to start sending again, to see if the congestion on the end-to-end path has changed. This issue has been addressed in a proposal for Probabilistic Congestion Control [PCC].
定常状態パケット低下率には、最小の送付レートが高過ぎるので発信するのを止めるVoIP流動のために、私たちはVoIP流動が終わりから端への経路における混雑が変化したかどうかを見るために再び発信し始めることができるかもしれない時に関する質問を記述していません。 Probabilistic Congestion Control[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.
私たちは、混雑指摘が低下しているパケットと対照的にパケット(明白なCongestion Notification)であるとマークされた電子証券取引ネットワークの形にあるなら最小の送付レートに従った流れが発信するのを止めなければならない時に関する答えがいくらか異なっていることに注意します。 電子証券取引ネットワークで、ルータは、パケットを落とすことの代わりに[RFC3168]をマークしながら、明らかに電子証券取引ネットワークによる混雑のエンドノードに通知できます。 パケットがネットワークで低下の代わりにマークされた電子証券取引ネットワークであるなら、混雑崩壊かユーザ品質(いずれにせよ電子証券取引ネットワークできる交通に)の関心が全くありません、そして、どんな残りが競争するのがある公正の関心であるかは流れます。 TCPが非常に高い混雑がある政権により高い送付レートを持っている2番目は一部低下しているパケット、異なった力学による不-引き返すことに関する引き返している再送信タイマを電子証券取引ネットワークでマークしました。
Floyd & Kempf Informational [Page 16] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[16ページ]のRFC3714IAB心配は2004年3月に制御されます。
5.1. Drop Rates at 4.75 kbps Minimum Sending Rate
5.1. 4.75キロビット毎秒Minimum Sending RateでRatesを落としてください。
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.
4.75のキロビット毎秒アプリケーションデータの最小の送付レートまで適合できるR=0.1秒のRTTとの適応型のオーディオアプリケーションを考えてください、1秒あたり20のM=パケットを送って。 この送付レートはB=1393 Bpsのワイヤの送付レートのためのアプリケーションデータのN=593 Bpsに翻訳されます。 R=0.1秒のP=1460バイトと往復の時間のデータ・パケットとの同等なレートTCP接続は0.09BR/(P+40)=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.
Appendixのテーブル1は、RTTの2倍に用意ができているRTOとのTCP接続によって経験されたパケット低下率を見て、pprでTCP接続の対応する送付速度を与えます。 第2コラムは標準の解析手法、および3日までに見積もられていた送付レートを与えます、4番目、反逆者は無作為のパケット滴かマークがあるシミュレーションから平均した送付レートを与えます。 第6コラムは4.8RELEASE無料OSの一つマシンの実験から送付レートを与えます。 解析手法はRTT、およびRTOのための結果が2RTTに設定するTable1ショーを倍数として急送されたRTOに要求します。 シミュレーションで、最小のRTOはRTTの2倍に用意ができています。 その他の詳細に関してAppendixを見てください。
For a sending rate of 0.09 ppr and an RTO set to 2 RTT, Table 1 shows that the analytical approach gives a corresponding packet drop rate of roughly 50%, while the simulations in the fifth column and the experiments in the sixth column give a packet drop rate of between 35% and 40% to maintain a sending rate of 0.09 ppr. (For a reference TCP connection using timestamps, shown in the fourth column, the simulations give a packet drop rate of 55% to maintain a sending rate of 0.09 ppr.) Of the two approaches for determining TCP's relationship between the sending rate and the packet drop rate, the analytic approach and the use of simulations, we consider the simulations to be the most realistic, for reasons discussed in the Appendix. This suggests a packet drop rate of 40% would be reasonable for a TCP connection with an average sending rate of 0.09 ppr. As a result, a VoIP connection with an RTT of 0.1 sec and a minimum sending rate of 4.75 kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeds 40%.
0.09の送付レートのために、pprとRTOは2RTT(第5コラムにおけるシミュレーションと第6コラムにおける実験がパケット低下率を与えますが、解析手法がおよそ50%の対応するパケット低下率に0.09pprの送付レートに維持する35%から40%を与えるTable1ショー)にセットしました。 (第4コラムに示されたタイムスタンプを使用している参照TCP接続のために、シミュレーションは0.09pprの送付レートに維持する55%のパケット低下率を与えます。) 私たちは、シミュレーションが最も現実的であると考えます、送付レートと、パケット低下率と、分析的なアプローチとシミュレーションの使用とのTCPの関係を決定するための2つのアプローチではAppendixで議論した理由で。 これは、0.09pprの平均した送付レートとのTCP関係に、40%のパケット低下率が妥当であると示唆します。 しつこいパケット低下率が40%をかなり超えているとき、結果、0.1秒のRTTとのVoIP接続、および4.75キロビット毎秒の最小の送付レートが終えるか、または中断するのに必要であるだろうというときに。
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
これらの見積りはTCP接続の想定された往復の時間に敏感です。 私たちが、同等なレートTCP接続がR=0.01秒の往復の時間を過したと代わりに思うなら、同等なレートTCP接続は0.009BR/(P+40)=pprを送るでしょうに。 しかしながら、また、私たちは0.1秒のTCP接続のために最小のRTOを仮定しました。(この場合、秒は少なくとも10RTTのRTOを意味するでしょう)。 RTOのこの設定に、私たちは、特定のパケットの平均したTCP送付レートを測定するのに付録からTable2を使用するでしょう。
Floyd & Kempf Informational [Page 17] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[17ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.)
レートを落としてください。 Table2の反逆者でのシミュレーションは、0.01秒のRTTと10RTTのRTOとのTCP接続が45%のパケット低下率と共に0.009pprを送ることができると示唆します。 (第4コラムに示されたタイムスタンプを使用している同じTCP接続のために、シミュレーションは0.009pprの送付レートに維持する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%.
しつこいパケット低下率が45%を超えていたとき、したがって、0.01秒のRTTと4.75キロビット毎秒の最小の送付レートとのVoIP関係において、VoIP接続が、終えるか、または中断するのに必要でしょう。
5.2. Drop Rates at 64 kbps Minimum Sending Rate
5.2. 64キロビット毎秒Minimum Sending RateでRatesを落としてください。
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キロビット毎秒に増加させるという効果は事実上、アプリケーションが発信を終えるべきであるか、または中断させるべきであるパケット低下速度を減少させることです。 このセクションと、64キロビット毎秒、またはN=8000 Bpsの最小の送付レート、および50M=ppsのパケット送付レートがあるコーデックを考えてください。 (これは1パケットあたりの20原稿によって160バイトのデータ・パケットに同等でしょう。) ワイヤの送付レートはヘッダー、または10000Bpsを含むN+40B=MのBpsです。 サイズP=1460バイトのパケットとR=0.1秒の往復の時間と共にその送付レートを持っているTCP接続は0.66BR/(P+40)=pprを送ります。 Table1の反逆者から、2RTTのRTOに関して、これは20〜25%のパケット低下率に対応しています。 [Table1に関する第4コラムに示されるようにきめ細かに粒状のタイムスタンプを使用しているTCP接続のために、この送付レートは25%と35%の間のパケット低下率に対応しています。] しつこいパケット低下率が25%をかなり超えているとき、結果、0.1秒のRTTとのVoIP接続、および64キロビット毎秒の最小の送付レートが終えるか、または中断するのに必要であるだろうというときに。
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(10RTTをRTOに与える)との同等なレートTCP関係のために、私たちはTable2の反逆者を使用します。(Tableは0.066pprの送付レートがおよそ30%のパケット低下率に対応するのを示します)。 [Table2に関する第4コラムに示されるようにきめ細かに粒状のタイムスタンプを使用しているTCP接続のために、この送付レートはおよそ45%のパケット低下率に対応しています。] しつこいパケット低下率が30%を超えていたとき、したがって、0.01秒のRTTと64キロビット毎秒の最小の送付レートとのVoIP関係において、VoIP接続が、終えるか、または中断するのに必要でしょう。
5.3. Open Issues
5.3. 未解決の問題
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でしょう。
Floyd & Kempf Informational [Page 18] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[18ページ]のRFC3714IAB心配は2004年3月に制御されます。
"persistent packet drop rate" would refer to the packet drop rate over a significant number of round-trip times, e.g., at least five seconds. Another possibility would be that the time interval for measuring the persistent drop rate is a function of the lifetime of the connection, with longer-lived connections using longer time intervals for measuring the persistent drop rate.
「しつこいパケット低下率」は往復の何回(例えば、少なくとも5秒)も上にもパケット低下率を示すでしょう。 別の可能性はしつこい低下率を測定するための時間間隔が接続の生涯の機能であるということでしょう、より長く送られた接続がしつこい低下率を測定するために、より長い時間間隔を費やしていて。
The time period for detecting persistent congestion also affects the potential synchronization of VoIP sessions all terminating or suspending at the same time in response to shared congestion. If flows use some randomization in setting the time interval for detecting persistent congestion, or use a time interval that is a function of the connection lifetime, this could help to prevent all VoIP flows from terminating at the same time.
また、しつこい混雑を検出するための期間は同時に共有にされるに対応して混雑を終えるか、または中断させるVoIPセッションのすべて、潜在的同期に影響します。 流れがしつこい混雑を検出するのに時間間隔を設定する際に何らかの無作為化を使用するか、またはコネクション存続期間の機能である時間間隔を費やすなら、これは、すべてのVoIP流れが同時に終わるのを防ぐのを助けるかもしれません。
Another design issue for a complete protocol concerns whether a flow terminates when the packet drop rate is too high, or only suspends temporarily. For a flow that suspends temporarily, there is an issue of how long it should wait before resuming transmission. At the very least, the sender should wait long enough so that the flow's overall sending rate doesn't exceed the allowed sending rate for that packet drop rate.
デザインがパケット低下率であるときに、流れが終わるかどうかが、高過ぎるという完全なプロトコル関心のために発行するか、または一時中断させるだけである別のもの。 それが一時中断させる流れのために、トランスミッションを再開する前にどれくらい長い間待つべきであるかに関する問題があります。 少なくとも、送付者が十分長い間待つべきであるので、流れの総合的な送付レートはそのパケット低下率の許容送付レートを超えていません。
The recommendation of this document is that VoIP flows with minimum sending rates should have corresponding configured packet drop rates, such that the flow terminates or suspends when the persistent packet drop rate of the flow exceeds the configured rate. If the persistent packet drop rate increases over time, flows with higher minimum sending rates would have to suspend sending before flows with lower minimum sending rates. If VoIP flows terminate when the persistent packet drop rate is too high, this could lead to scenarios where VoIP flows with lower minimum sending rates essentially receive all of the link bandwidth, while the VoIP flows with higher minimum sending rates are required to terminate. However, if VoIP flows suspend sending for a time when the persistent packet drop rate is too high, instead of terminating entirely, then the bandwidth could end up being shared reasonably fairly between VoIP flows with different minimum sending rates.
このドキュメントの推薦は最小の送付レートに従ったVoIP流れには対応する構成されたパケット低下率(流れのしつこいパケット低下速度が構成されたレートを超えていると、流れが終えるか、または中断させるそのようなもの)があるべきであるということです。 しつこいパケット低下率が時間がたつにつれて増加するなら、より高い最小の送付レートに従った流れは低い最小の送付レートに従った流れの前の発信を中断させなければならないでしょう。 しつこいパケット低下率が高過ぎるときに、VoIP流れが終わるなら、これはVoIPがレートが本質的には受ける下側の最小の発信であふれる終えるVoIPが、より高い最小の送付レートであふれる間のリンク帯域幅のすべてが必要であるシナリオに通じるかもしれません。 しかしながら、VoIP流れが完全に終わることの代わりにしつこいパケット低下率が高過ぎる時の発信を中断させるなら、VoIP流れの間で合理的に異なった最小の送付レートと公正に共有されていて、帯域幅は終わるかもしれません。
5.4. A Simple Heuristic
5.4. 簡単なヒューリスティック
One simple heuristic for estimating congestion would be to use the RTCP reported loss rate as an indicator. For example, if the RTCP- reported lost rate is greater than 30%, or N back-to-back RTCP reports are missing, the application could assume that the network is too congested, and terminate or suspend sending.
混雑がRTCPを使用することであると見積もるための1つの簡単なヒューリスティックがインディケータとして損失率を報告しました。 例えば、無くなると報告されたRTCPレートが30%以上であるかN背中合わせのRTCPレポートがなくなるなら、アプリケーションは、発信をネットワークが混雑し過ぎていると仮定して、終えるか、または中断させるかもしれません。
Floyd & Kempf Informational [Page 19] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[19ページ]のRFC3714IAB心配は2004年3月に制御されます。
6. Constraints on VoIP Systems
6. VoIPシステムにおける規制
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システムはそれらのパケットレートをスケーリングする限られた能力を示します。 パケットの数が減少するなら、1パケットあたりのオーディオの量は、よりすばらしいです、そして、受信機の誤り補正は、より困難になります。 通常、40〜100msである音素の長さよりどんな誤り長い間も音素とスピーカーに頼るのは復しません。 理想的に、アプリケーションは潜水艦30msパケットを必要とします、そして、これはほとんどの音声コーデックが提供するものです。 さらに、声のメディアの流れは下側のデータ信号速度における、より大きい損失感度を示します。 下側のデータ信号速度コーデックは、終わりから端への、より多くの状態を維持して、その結果一般に損失により敏感です。
We note that very-low-bit-rate codecs have proved useful, although with some performance degradation, in very low bandwidth, high noise environments (e.g., 2.4 kbps HF radio). For example, 2.4 kbps codecs "produce speech which although intelligible is far from natural sounding" [W98]. Figure 5 of [W98] shows how the speech quality with several forms of codecs varies with the bit rate of the codec.
私たちは、その非常に低いビット伝送速度コーデックが有用であることが分かったことに注意します、いくらかの性能退行で、非常に低い帯域幅で、高い雑音環境(例えば、2.4キロビット毎秒HFラジオ)。 例えば、2.4のキロビット毎秒コーデックが「明瞭ですが、全く自然でない測深であるスピーチを製作する」[W98]。 [W98]の図5はコーデックのビット伝送速度に従っていくつかの形式のコーデックがあるスピーチ品質がどう異なるかを示しています。
7. Conclusions and Recommendations
7. 結論と推薦
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規格では、パケット低下率を指定しなければなりません、ベストエフォート型流れが発信を一時終えるか、または中断させるように、定常状態パケット低下率が指定された低下率をかなり超えていると。
Floyd & Kempf Informational [Page 20] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[20ページ]のRFC3714IAB心配は2004年3月に制御されます。
(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) 最小の送付レートの指定された低下率は本書では例証されるようにTables1と2の使用と一致しているべきです。
We note that this is a recommendation to the IETF community, as a specific follow-up to RFC 2914 on Congestion Control Principles.
私たちは、これがIETF共同体への推薦であることに注意します、Congestion ControlプリンシプルズのRFC2914への特定のフォローアップとして。
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はそうすることができたリアルタイムの交通が、それらを落とすことの代わりにパケットをマークすることによって、電子証券取引ネットワークの使用からエンドノードへの重要な利益を引き出します。そこで、ルータは混雑を示すかもしれません。 しかしながら、電子証券取引ネットワークは、混雑のしるしとして適切に著しいパケットに反応するトランスポート・プロトコルと共に使用されるために標準化されるだけです。 推薦に続いて起こるVoIP交通は本書では電子証券取引ネットワークを使用するための輻輳制御要件を満たすかもしれません、レートを落として、マークするパケットが高過ぎたときに終わりか中断のためのメカニズムのないVoIP交通はそうしないでしょうが。 しかしながら、私たちは、このドキュメントが完全なプロトコル仕様でないことを繰り返します。 特定の、そして、追加しているメカニズムでは、電子証券取引ネットワークを使用するのがUDPをひくアプリケーションにおいて安全になる前に必要でしょう。 例えば、電子証券取引ネットワークを使用する前に、送付アプリケーションは、下層UDPスタックから電子証券取引ネットワーク関連の情報を受け取って、受信アプリケーションが混雑指示としてこの電子証券取引ネットワーク情報を解釈できたのを保証しなければならないでしょう。
8. Acknowledgements
8. 承認
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アトキンソン、フレッド・ベイカー、ジョン・クロウクロフト、クリストフDiot、アランDuric、ジェレミー・ジョージ、マーク・ハンドレー、Orionホドソン、ジェフ・ヒューストン、エディ・コーラー、サイモンLeinen、デヴィッド・マイヤー、ジーンフランソアMule、コリン・パーキンス、ジョン・ピーターソン、マイク・ピアス、サイラスShaoul、およびヘニングSchulzrinneに感謝します。 (もちろん、これらの人々は必ずドキュメントのすべてに同意するというわけではありません。) ドキュメントの原本に寄付していた状態でアトキンソンとジェフ・ヒューストンを車で送りました。
The analysis in Section 6.0 resulted from a session at the whiteboard with Mark Handley. We also thank Alberto Medina for the FreeBSD experiments showing TCP's sending rate as a function of the packet drop rate.
セクション6.0での分析はマーク・ハンドレーと共にホワイトボードにセッションから生じました。 また、私たちは、TCPを見せていると送られる実験がパケット低下率の関数をみなすのを無料OSの一つのためのアルベルト・メディナに感謝します。
Floyd & Kempf Informational [Page 21] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[21ページ]のRFC3714IAB心配は2004年3月に制御されます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、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] シェーベリ、J.、Westerlund、M.、Lakaniemi、A.、およびQ.シェ、「リアルタイムのトランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置は適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)にオーディオコーデックをフォーマットします」、RFC3267、2002年6月。
9.2. Informative References
9.2. 有益な参照
[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]は2002年11月にアトキンソン、An ISP Reality Check、Presentationをieprep、第55IETF Meetingへ走らせました。 「 http://www.ietf.cnri.reston.va.us/proceedings/ 02nov/219.htm#スライド」というURL。
[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.
SIGCOMM2001、[BBFS01]Deepak Bansal、ハーリBalakrishnanはゆっくり敏感な輻輳制御アルゴリズムのフロイド、およびスコットShenker、動的挙動を出撃させます。
[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.
[巡査] ダラム、D.(エド)、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[DCCP03] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra
Padhye, Datagram Congestion Control Protocol (DCCP),
internet-draft Work in Progress, March 2003. URL
"http://www.icir.org/kohler/dcp/".
[DCCP03]エディ・コーラーとマーク・ハンドレー、サリー・フロイドとJitendra Padhye、データグラムCongestion Controlプロトコル(DCCP)、Progress(2003年3月)のインターネット草稿Work。 URL" http://www.icir.org/kohler/dcp/ "。
[DIFFSERV] Differentiated Services (diffserv), Concluded Working
Group, URL
"http://www.ietf.cnri.reston.va.us/html.charters/
OLD/diffserv-charter.html".
作業部会、URL「 http://www.ietf.cnri.reston.va.us/html.charters/ の古い/diffserv-charter.html」は、[DIFFSERV]がサービス(diffserv)を微分したと結論づけました。
[E2E] The end2end-interest mailing list, URL
"http://www.postel.org/mailman/listinfo/end2end-
interest".
[2EのE] end2end-関心メーリングリスト、URL「 http://www.postel.org/mailman/listinfo/end2end- 関心。」
Floyd & Kempf Informational [Page 22] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[22ページ]のRFC3714IAB心配は2004年3月に制御されます。
[FHPW00] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-
Based Congestion Control for Unicast Applications", ACM
SIGCOMM 2000.
[FHPW00] S.フロイド、M.ハンドレー、J.Padhye、J.ウィトマー、「ユニキャストアプリケーションのための方程式のベースの輻輳制御」、ACM SIGCOMM2000。
[FM03] S. Floyd and R. Mahajan, Router Primitives for
Protection Against High-Bandwidth Flows and Aggregates,
internet draft (not yet submitted).
[FM03] S.フロイドとR.MahajanとProtection Against High-帯域幅FlowsのためのRouter PrimitivesとAggregates、インターネット草稿(まだ、提出していません)。
[FWD] Free World Dialup, URL "www.pulver.com/fwd/".
[FWD]は世界ダイアルアップ、URL"www.pulver.com/fwd/"を解放します。
[IEPREP02] Internet Emergency Preparedness (ieprep), Minutes, 55th
IETF Meeting, November 2002. URL
"http://www.ietf.cnri.reston.va.us/proceedings/
02nov/219.htm#cmr".
[IEPREP02]インターネット非常時の気構え(ieprep)、数分、第55IETFミーティング、2002年11月。 URL「 http://www.ietf.cnri.reston.va.us/proceedings/ 02nov/219.htm#cmr。」
[ILBRC] S.V. Andersen, et. al., Internet Low Bit Rate Codec,
Work in Progress, March 2003.
et[ILBRC]S.V.アンダーセン、アル、インターネットLow Bit Rate Codec、Progress、3月2003日のWork
[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がそうするかもしれません。 URL「 http://www.itu.int/itudoc/itu- t/aap/sg12aap/recaap/g.114/。」
[IVOX] The Interactive VOice eXchange, URL
"http://manimac.itd.nrl.navy.mil/IVOX/".
[IVOX] 対話的な声の交換、URL" http://manimac.itd.nrl.navy.mil/IVOX/ "。
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM
SIGCOMM '88, August 1988.
[Jacobson88] V.ジェーコブソンと輻輳回避とコントロール、ACM SIGCOMM88年、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.
VoIP交通の最大の可能な低下速度の[AUT]はコーデックによります。これらの数はさまざまなコーデックのための範囲です。 音声の品質は10%の低下率の周りの多くのコーデックのために悪化し始めます。 作者から、注意します。
[JS00] Wenyu Jiang and Henning Schulzrinne, Modeling of Packet
Loss and Delay and Their Effect on Real-Time Multimedia
Service Quality, NOSSDAV, 2000. URL
"http://citeseer.nj.nec.com/jiang00modeling.html".
[JS00] Wenyu江とヘニングSchulzrinneとパケット損失と遅れのモデルとリアルタイムのマルチメディアサービス品質、NOSSDAV、2000へのそれらの効果。 URL" http://citeseer.nj.nec.com/jiang00modeling.html "。
[JS02] Wenyu Jiang and Henning Schulzrinne, Comparison and
Optimization of Packet Loss Repair Methods on VoIP
Perceived Quality under Bursty Loss, NOSSDAV, 2002.
URL "http://www1.cs.columbia.edu/~wenyu/".
VoIPにおけるパケット損失修理方法の[JS02]のWenyu江、ヘニングSchulzrinne、比較、および最適化はBurstyの損失、NOSSDAV、2002の下で品質を知覚しました。 URL" http://www1.cs.columbia.edu/~wenyu/ "。
[JS03] Wenyu Jiang, Kazummi Koguchi, and Henning Schulzrinne,
QoS Evaluation of VoIP End-points, ICC 2003. URL
"http://www1.cs.columbia.edu/~wenyu/".
[JS03] Wenyu江、Kazummi Koguchi、およびヘニングSchulzrinne、VoIPエンドポイントのQoS評価、ICC2003。 URL" http://www1.cs.columbia.edu/~wenyu/ "。
Floyd & Kempf Informational [Page 23] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[23ページ]のRFC3714IAB心配は2004年3月に制御されます。
[KFK79] G.S. Kang, L.J. Fransen, and E.L. Kline, "Multirate
Processor (MRP) for Digital Voice Communications", NRL
Report 8295, Naval Research Laboratory, Washington DC,
March 1979.
[KFK79]G.S.カン、L.J.Fransen、およびE.L.クライン、「デジタル声のコミュニケーションのための多速度プロセッサ(MRP)」、NRLは8295を報告します、海軍研究試験所、ワシントンD.C.、1979年3月。
[KF82] G.S. Kang and L.J. Fransen, "Second Report of the
Multirate Processor (MRP) for Digital Voice
Communications", NRL Report 8614, Naval Research
Laboratory, Washington DC, September 1982.
[KF82]G.S.カンとL.J.Fransen、「デジタル声のコミュニケーションのための多速度プロセッサ(MRP)の第2レポート」、NRLは8614を報告します、海軍研究試験所、ワシントンD.C.、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 "の[測定]ウェブページ。 「特定のサイトのネットワーク測定値」のセクションはインターネットの様々なリンクにおけるパケットサイズの分配に関する測定データを含んでいます。
[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.カラム、「インターネット背骨の上で声のコミュニケーションの品質を評価します」、ネットワーク、V.11N.5(2003年10月)におけるIEEE/ACM取引。
[NSIS] Next Steps in Signaling (nsis), IETF Working Group, URL
"http://www.ietf.cnri.reston.va.us/html.charters/nsis-
charter.html".
[NSIS] Signaling(nsis)、IETF作業部会、URL「 http://www.ietf.cnri.reston.va.us/html.charters/nsis- charter.html」の次のSteps。
[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]のヨルク・ウィトマー、マーチンMauve、およびジャン・ピーター・ダム。 非融通のきく流れのための確率的な輻輳制御。 技術報告書3/2001と数学の部とコンピュータサイエンス、マンハイム大学。 URL「 http://www.informatik.uni- mannheim.de/informatik/pi4/プロジェクト/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対Firoiu、D.Towsley、TCPスループットをモデル化するJ.黒瀬: Simple ModelとEmpirical Validation、Tech Report TF98-008、U.ミサ、1998年2月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896,
January 1984.
[RFC896] ネーグル、J.、「IP/TCPの輻輳制御」、RFC896、1984年1月。
[RFC1890] Schulzrinne, H., "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 1890, January
1996.
[RFC1890]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
Floyd & Kempf Informational [Page 24] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[24ページ]のRFC3714IAB心配は2004年3月に制御されます。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2474]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group, RFC 2597, June 1999.
[RFC2597]Heinanen(J.、ベイカー、F.、ウィス、W.、およびJ.Wroclawski)は「PHBグループ、RFC2597に1999年6月を送りながら、保証しました」。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC2990] ヒューストン、G.、「IP QoS構造のための次のステップ」、RFC2990、2000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S., Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[RFC3042]オールマン、M.、Balakrishnan、H.、およびS.、フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、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.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3246] デイビーとB.とシャルニーとA.とアメリカダイコンソウとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とコートニーとW.とDavariとS.とFiroiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[RFC3448] Handley, M., Floyd, S., Pahdye, J. and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Pahdye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、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)、結論づけられた作業部会、「 http://www.ietf.cnri.reston.va.us/html.charters/ の古い/rsvp-charter.html」というURL。
[RTTWeb] Web Page on Round-Trip Times in the Internet, URL
"http://www.icir.org/floyd/rtt-questions.html"
[RTTWeb] インターネットの往復の回のウェブページ、URL" http://www.icir.org/floyd/rtt-questions.html "
[S03] H. Schulzrinne, private communication, 2003.
[S03] H.Schulzrinne、私信、2003。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", RFC 3551,
July 2003.
[RFC3551]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
Floyd & Kempf Informational [Page 25] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[25ページ]のRFC3714IAB心配は2004年3月に制御されます。
[Vonage] Vonage, URL "www.vonage.com".
[Vonage]Vonage、URL"www.vonage.com"。
[W98] J. Woodward, Speech Coding, Communications Research
Group, University of Southampton, 1998. URL
"http://www-mobile.ecs.soton.ac.uk/speech_codecs/",
[W98] J.ウッドワード、音声符号化、コミュニケーション研究グループ、サウサンプトン大学、1998。 URL" http://www-mobile.ecs.soton.ac.uk/speech_codecs/ "
Floyd & Kempf Informational [Page 26] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[26ページ]のRFC3714IAB心配は2004年3月に制御されます。
10. Appendix - Sending Rates with Packet Drops
10. 付録--パケット滴でレートを送ること。
The standard way to estimate TCP's average sending rate S in packets per round-trip as a function of the packet drop rate would be to use the TCP response function estimated in [PFTK98]:
パケット低下率の関数としての往復あたりのパケットでTCPの平均した送付がレートSであると見積もる標準の方法は[PFTK98]で見積もられていたTCPレスポンス関数を使用するだろうことです:
S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2)) (1)
S=1/(sqrt(2p/3)+K分(1、3sqrt(3p/8))p(1+32p^2))(1)
for acks sent for every data packet, and the RTO set to K*RTT.
あらゆるデータ・パケット、およびRTOのために送られたacksに関しては、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.
Tables1と2における第2コラムでEquation(1)からの結果を以下に与えます。 しかしながら、Equation(1)は政権で重いパケット低下率(例えば、30%以上の)でTCPの送付レートを過大評価します。 Equation(1)の後ろの分析は、単一のパケットがいったん首尾よく伝えられると、TCPの再送信タイマがもう戻されないと仮定します。 電子証券取引ネットワークがある環境、またはきめ細かに粒状のタイムスタンプを使用しているTCP接続に適切であるかもしれませんが、これは必ずタイムスタンプのないできる非電子証券取引ネットワークのTCP接続のためのそうであるというわけではありません。 TCPが首尾よく、新しいパケット(再送されたパケットと対照的に)を伝えるときだけ、[RFC2988]で指定されるように、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のスループットは主に再送信タイマの最大のbackoffによって測定されます。 例えば、再送信タイマの最大のbackoffがNSシミュレータでは64回である、不-値を戻しました。 RFC2988は、「最大値は少なくとも60秒であるならRTOに置かれるかもしれません。」と指定します。 [TCP実現は異なりますが、多くのTCP実現には、低下しているSYNパケットの後に、支持されてオフなRTOのための最大45秒があります。]
Another limitation of Equation (1) is that it models Reno TCP, and therefore underestimates the sending rate of a modern TCP connection that used SACK and Limited Transmit.
Equation(1)の別の限界はリノTCPをモデル化して、したがって、SACKと株式会社Transmitを使用した現代のTCP接続の送付速度を過小評価するということです。
The table below shows estimates of the average sending rate S in packets per RTT, for TCP connections with the RTO set to 2 RTT for Equation (1).
平均した発信の見積りがRTOとのTCP接続のために1RTTあたりのパケットでSであると評定するショーの下におけるテーブルはEquation(1)のために2RTTにセットしました。
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
これらの見積りは3番目、4番目、および反逆者で電子証券取引ネットワーク、きめ細かに粒状のタイムスタンプがあるTCPのためのパケット滴、およびTCPのためのパケット滴でタイムスタンプなしでシミュレーションにそれぞれたとえられます。 (シミュレーションスクリプトは http://www.icir.org/floyd/VoIP/sims から利用可能です。) 各シミュレーションは計算されます。
Floyd & Kempf Informational [Page 27] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[27ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
平均が2番目のシミュレーションの後半、およびそれぞれのパケット低下率のレートを送って、50以上のシミュレーションを平均に与えます。 非常に高いパケット低下率があるシミュレーションのために、時々SYNパケットが繰り返して落とされるのが、事実であり、TCP送付者は首尾よくパケットを決して伝えません。 また、この場合、TCP送付者は往復の現代の測定を決して得ません。
Floyd & Kempf Informational [Page 28] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[28ページ]のRFC3714IAB心配は2004年3月に制御されます。
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.
Table1に関する第6コラムは、実験のために1RTTあたりのパケットに4.8-RELEASE無料OSの一つマシンを使用することで平均した送付レートSを示しています。 0.1と0.2の低パケット低下率において、実験ではシミュレーションにおける送付レートは送付レートより高いです。 これはたぶんシミュレーションにおけるTCP実現が株式会社Transmit[RFC3042]を使用するからです。 パケットが落とされて、混雑ウィンドウが小さいときに、株式会社Transmit、送付者が時々避けることができるTCPと共に、aはタイムアウトを再送します。 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.
私たちは、レートをマークする電子証券取引ネットワークが局所的に構成された敷居を超えているならルータがマークから低下に切り替わるように教えられることに注意します。 その結果、私たちは、高い定常状態がインターネットでレートをマークしているのを見ると予想しません、電子証券取引ネットワークが事実上配備されても。
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
Rate p Eq(1)シムズを落としてください: 電子証券取引ネットワークシムズ: TimeStampシムズ: 低下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: 1RTTあたりのパケットで2RTT、およびSに用意ができているRTOのためにPacket Drop Rate pのFunctionとしてRate Sを送ります。
Floyd & Kempf Informational [Page 29] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[29ページ]のRFC3714IAB心配は2004年3月に制御されます。
The table below shows the average sending rate S, for TCP connections with the RTO set to 10 RTT.
RTOとのTCP接続の平均した送付速度Sのショーの下におけるテーブルは10RTTにセットしました。
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
Rate p Eq(1)シムズ: 電子証券取引ネットワークのシムズ: TimeStampシムズ: 低下を落としてください。------ ----- -------- -------------- ---------- 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: 1RTTあたりのパケットで10RTT、およびSに用意ができているRTOのためにPacket Drop RateのFunctionとしてRateを送ります。
11. Security Considerations
11. セキュリティ問題
This document does not itself create any new security issues for the Internet community.
それ自体ではなく、ドキュメントがするこれがインターネットコミュニティのためにどんな新しい安全保障問題も作成します。
12. IANA Considerations
12. IANA問題
There are no IANA considerations regarding this document.
このドキュメントに関するIANA問題が全くありません。
Floyd & Kempf Informational [Page 30] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[30ページ]のRFC3714IAB心配は2004年3月に制御されます。
13. Authors' Addresses
13. 作者のアドレス
Internet Architecture Board EMail: iab@iab.org
インターネット・アーキテクチャ委員会メール: iab@iab.org
Internet Architecture Board Members at the time this document was published were:
このドキュメントが発表されたとき、インターネット・アーキテクチャ委員会のメンバーは以下の通りでした。
Bernard Aboba Harald Alvestrand (IETF chair) Rob Austein Leslie Daigle (IAB chair) Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston (IAB Executive Director) Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
バーナードAbobaハラルドAlvestrand(IETFいす)ロブ・Austeinレスリー・Daigle(IABいす)パトリクFaltstromサリーフロイド6月-ichiro Itojun Haginoマーク・ハンドレー・ジェフ・ヒューストン(IAB事務局長)チャーリー・カウフマンジェームスケンフエリックレスコラマイク通りジョーンズ
This document was created in January 2004.
このドキュメントは2004年1月に作成されました。
Floyd & Kempf Informational [Page 31] RFC 3714 IAB Concerns Regarding Congestion Control March 2004
混雑に関するフロイドとケンフの情報[31ページ]のRFC3714IAB心配は2004年3月に制御されます。
14. Full Copyright Statement
14. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Floyd & Kempf Informational [Page 32]
フロイドとケンフInformationalです。[32ページ]
一覧
スポンサーリンク
