[要約] 要約：RFC 7295は、IAB/IRTFワークショップでの議論をまとめたものであり、インタラクティブなリアルタイム通信のための輻輳制御に関する報告書です。目的：このRFCの目的は、インタラクティブなリアルタイム通信における輻輳制御の重要性を強調し、関連する問題や解決策についての洞察を提供することです。
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7295 L. Eggert
Category: Informational Z. Sarker
ISSN: 2070-1721 July 2014
Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
インタラクティブなリアルタイム通信のための輻輳制御に関するIAB / IRTFワークショップからのレポート
Abstract
概要
This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.
このドキュメントは、2012年7月28日にカナダのバンクーバーで開催された「インタラクティブリアルタイムコミュニケーションのための輻輳制御」に関するIAB / IRTFワークショップの概要を提供します。ワークショップの主な目的は、輻輳に関する議論を促進することでした。インタラクティブなリアルタイム通信の制御メカニズム。このレポートでは、インターネットエンジニアリングタスクフォース（IETF）コミュニティへの議論と推奨事項をまとめています。
The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).
このレポートの見解と見解はワークショップ参加者の見解と見解であり、著者、インターネットアーキテクチャボード（IAB）、またはインターネット調査タスクフォース（IRTF）の見解と見解を必ずしも反映していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7295.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7295で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
2.1. History and Current Challenges . . . . . . . . . . . . . 5
2.2. Simulations and Measurements . . . . . . . . . . . . . . 8
2.3. Design Aspects of Problems and Solutions . . . . . . . . 9
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Changes to Network Infrastructure . . . . . . . . . . . . 14
3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 22
Appendix B. Workshop Material . . . . . . . . . . . . . . . . . 22
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 22
Appendix D. Workshop Participants . . . . . . . . . . . . . . . 24
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。 IABのこの長期計画機能は、インターネットエンジニアリングステアリンググループ（IESG）と地域のディレクターのリーダーシップの下で、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループによって実行されているエンジニアリングの取り組みを補完します。
Any application that sends significant amounts of data over the Internet is expected to implement reasonable congestion control behavior. The goals for congestion control are well understood and documented in RFC 2914 [2] and RFC 5405 [1]:
インターネット経由で大量のデータを送信するアプリケーションは、合理的な輻輳制御動作を実装することが期待されています。輻輳制御の目標は、RFC 2914 [2]およびRFC 5405 [1]で十分に理解および文書化されています。
1. Preventing congestion collapse.
1. 混雑崩壊の防止。
2. Allowing multiple flows to share the network fairly.
2. 複数のフローがネットワークを公平に共有できるようにします。
The Internet has been used for interactive real-time communication for decades, most of which is being transmitted using the Real-Time Transport Protocol (RTP) over UDP, often over provisioned capacity and/or using only rudimentary congestion control mechanisms. In 2004, the IAB raised concerns regarding possibilities of a congestion collapse due to a rapid growth in real-time voice traffic that does not practice end-to-end congestion control [17]. That congestion collapse did not happen, but concerns raised about both congestion collapse and fairness are still valid and have gained more relevance when applied to more bandwidth-hungry video applications. The development and upcoming widespread deployment of web-based real-time media communication -- where RTP is used to and from web browsers to transmit audio, video, and data -- will likely result in substantial new Internet traffic. Due to the projected volume of this traffic, as well as the fact that it is more likely to use unprovisioned capacity, it is essential that it is transmitted with robust and effective congestion control mechanisms.
インターネットは何十年にもわたってインタラクティブなリアルタイム通信に使用されてきました。そのほとんどは、UDPを介したリアルタイム転送プロトコル（RTP）を使用して、多くの場合はプロビジョニングされた容量を介して、および/または基本的な輻輳制御メカニズムのみを使用して送信されます。 2004年、IABは、エンドツーエンドの輻輳制御を行わないリアルタイム音声トラフィックの急増による、輻輳の崩壊の可能性に関する懸念を提起しました[17]。その輻輳の崩壊は起こりませんでしたが、輻輳の崩壊と公平性の両方について提起された懸念は依然として有効であり、より多くの帯域幅を必要とするビデオアプリケーションに適用されると、より適切になります。 Webベースのリアルタイムメディア通信（RTPがWebブラウザーとの間でオーディオ、ビデオ、およびデータを送信するために使用される）の開発と今後の普及は、実質的に新しいインターネットトラフィックをもたらす可能性があります。このトラフィックの予測される量、およびプロビジョニングされていない容量を使用する可能性が高いという事実により、堅牢で効果的な輻輳制御メカニズムで送信されることが重要です。
Designing congestion control mechanisms that perform well under a wide variety of traffic mixes and over network paths with widely varying characteristics is not easy. Prevention of congestion collapse can be achieved through a "circuit breaker" mechanism (see, for example, [3]), but for media flows that are supposed to coexist with a user's other ongoing communication sessions, a congestion control mechanism that shares capacity fairly in the presence of a mix of TCP, UDP, and other protocol flows is needed.
多種多様なトラフィックミックスや、さまざまな特性を持つネットワークパス上で適切に機能する輻輳制御メカニズムを設計することは容易ではありません。輻輳崩壊の防止は、「サーキットブレーカー」メカニズム（たとえば、[3]を参照）によって実現できますが、ユーザーの他の進行中の通信セッションと共存するはずのメディアフローの場合、容量を公平に共有する輻輳制御メカニズムTCP、UDP、およびその他のプロトコルフローが混在している場合に必要です。
Many additional complications arise. Here are some examples:
多くの追加の合併症が発生します。ここではいくつかの例を示します。
1. Real-time interactive media sessions require low latencies, whereas streaming media can use large play-out buffers.
1. リアルタイムのインタラクティブメディアセッションでは低レイテンシが必要ですが、ストリーミングメディアでは大きな再生バッファーを使用できます。
2. In an RTP session, feedback exchanged via the RTP Control Protocol (RTCP) typically arrives much less frequently than, for example, TCP ACKs for a given TCP connection. Theoretically, the RTP/RTCP control loop can lead to a longer reaction time.
2. RTPセッションでは、RTP制御プロトコル（RTCP）を介して交換されるフィードバックは、通常、たとえば特定のTCP接続のTCP ACKよりもはるかに少ない頻度で到着します。理論的には、RTP / RTCP制御ループは、より長い反応時間につながる可能性があります。
3. Media codecs can usually only adjust their output rates in a much more coarse-grained fashion than, for example, TCP, and user experience suffers if encoding rates are switched too frequently. Codecs typically have a minimum sending rate as well.
3. メディアコーデックは通常、たとえばTCPよりもはるかに粗い方法でのみ出力レートを調整でき、エンコーディングレートの切り替えが頻繁すぎると、ユーザーエクスペリエンスが低下します。コーデックには通常、最低送信速度もあります。
4. Some bits of an encoded media stream are more important than others. For example, losing or dropping an I-frame of a video stream is more problematic than dropping a P-frame [40].
4. エンコードされたメディアストリームの一部のビットは、他のビットよりも重要です。たとえば、ビデオストリームのIフレームを紛失または削除することは、Pフレームを削除することよりも問題があります[40]。
5. Ramping up the transmission rate can be problematic. Simply increasing the output rate of the codec without knowing whether the network path can sustain transmission at the increased rate runs the danger of incurring a significant amount of packet loss that can cause playback artifacts.
5. 伝送速度を上げると問題が発生する可能性があります。ネットワークパスが増加した速度での伝送を維持できるかどうかを知らずにコーデックの出力レートを単に増加させると、再生アーティファクトを引き起こす可能性のある大量のパケット損失が発生する危険があります。
6. A congestion control scheme for interactive media needs to handle bundles of interrelated flows (audio, video, and data) in a way that accommodates the preferences of the application in the event of congestion.
6. インタラクティブメディアの輻輳制御方式では、相互に関連するフロー（オーディオ、ビデオ、およびデータ）のバンドルを、輻輳が発生した場合のアプリケーションの設定に対応する方法で処理する必要があります。
7. The desire to provide a congestion control mechanism that can be efficiently implemented inside an application imposes additional restrictions. For example, a web browser is not able to take the protocol interactions of a software download happening in another application into account.
7. アプリケーション内に効率的に実装できる輻輳制御メカニズムを提供したいという要望は、追加の制限を課します。たとえば、Webブラウザーは、別のアプリケーションで発生するソフトウェアダウンロードのプロトコルの相互作用を考慮することができません。
8. There are explicit congestion signals (such as Explicit Congestion Notification (ECN) [19]), and there are implicit indications of congestion (e.g., packet delay and loss). Care must be taken to account for each of these signals, particularly if various applications react on the same set of signals.
8. 明示的な輻輳信号（明示的な輻輳通知（ECN）[19]など）があり、輻輳の暗黙的な表示（パケットの遅延や損失など）があります。特にさまざまなアプリケーションが同じ信号のセットに反応する場合は、これらの信号のそれぞれに注意する必要があります。
9. Large buffers are often used in network elements and end device operating systems to better support TCP-based applications. These buffers introduce additional communication delay, which harms the small delay budget available for interactive real-time applications.
9. TCPベースのアプリケーションをより適切にサポートするために、ネットワーク要素とエンドデバイスのオペレーティングシステムで大きなバッファがよく使用されます。これらのバッファは、追加の通信遅延を導入し、インタラクティブなリアルタイムアプリケーションで利用可能な小さな遅延バジェットに悪影響を及ぼします。
The IETF has a long history of work on congestion control mechanisms. With ongoing standardization work on real-time interactive media communication on the web, new challenges have emerged that have refocused engineering attention on congestion control issues. To take a deeper look at congestion control in light of the growth of real-time traffic, workshop participants were invited to submit position papers that were then used to organize the workshop agenda into three principal components: a keynote talk given by Mark Handley describing the history of the work on congestion control for real-time media followed and his views of current problems; a presentation of simulations and data demonstrating current problems and solutions; and a discussion of desirable solution properties and challenges in deploying solutions.
IETFには、輻輳制御メカニズムに関する長い歴史があります。 Web上でのリアルタイムのインタラクティブメディアコミュニケーションに関する標準化作業が継続しているため、輻輳制御の問題にエンジニアリングの注意を集中させる新しい課題が浮上しています。リアルタイムトラフィックの増加に照らして輻輳制御をさらに詳しく検討するために、ワークショップの参加者は、ワークシートの議題を3つの主要なコンポーネントに整理するために使用されるポジションペーパーを提出するよう招待されました。追跡されたリアルタイムメディアの輻輳制御に関する作業の履歴と現在の問題に対する彼の見解。現在の問題と解決策を示すシミュレーションとデータのプレゼンテーション。また、ソリューションの望ましい特性とソリューションの展開における課題についても説明します。
Mark Handley argued that since 1988, the Internet has remained functional despite exponential growth, routers that are sometimes buggy or misconfigured, rapidly changing applications and usage patterns, and flash crowds. This is largely because most applications use TCP, and TCP implements end-to-end congestion control.
Mark Handley氏は、1988年以降、インターネットは指数関数的に成長し、ルーターは時々バグがあり、設定が間違っているため、アプリケーションと使用パターンが急速に変化し、群衆が急増しているにもかかわらず機能し続けていると主張しました。これは主に、ほとんどのアプリケーションがTCPを使用しており、TCPがエンドツーエンドの輻輳制御を実装しているためです。
TCP's congestion control adapts the window to fit the capacity available in the network and accomplishes approximate fairness between two competing flows over a period of time. Mark indicated that the provided level of fairness is not necessarily what we want: The 1/round-trip-time relationship in TCP is not ideal since it means that network operators can decide to lower packet loss by adding bigger buffers (which unfortunately leads to bufferbloat problems; see [31] and [39]). The 1/sqrt(packet drop rate) relationship is also not necessarily desirable since TCP initially did not work particularly well for high-speed flows (which had been the subject of much TCP research).
TCPの輻輳制御は、ウィンドウをネットワークで利用可能な容量に合わせて調整し、一定の期間にわたって2つの競合するフロー間のおおよその公平性を実現します。マークは、提供された公平性のレベルが必ずしも私たちが望むものではないことを示しました：TCPの1 /往復時間の関係は理想的ではありませんbufferbloatの問題; [31]と[39]を参照）。 1 / sqrt（パケットドロップレート）の関係も、最初は高速フロー（特に多くのTCP研究の主題であった）に対してTCPが特にうまく機能しなかったため、必ずしも望ましいわけではありません。
TCP controls the congestion window in bytes. For bulk transfer, usually this results in controlling the number of 1500-byte packets sent per second. Real-time media is different since it has its own time constraints. For audio, one wants to send one packet per 20 ms and for video, the ideal value would be 25 to 30 frames per second. One, therefore, wants to avoid additional sending delay.
TCPは、輻輳ウィンドウをバイト単位で制御します。バルク転送の場合、通常これにより、1秒あたりに送信される1500バイトのパケット数が制御されます。リアルタイムメディアには独自の時間制限があるため、メディアは異なります。オーディオの場合、20ミリ秒ごとに1つのパケットを送信する必要があり、ビデオの場合、理想的な値は25〜30フレーム/秒です。したがって、追加の送信遅延を回避したいと考えています。
As an example, in case of video, to relieve congestion one has to reduce the number of packets-per-second transmission rate rather than transmit smaller packets, since at higher bitrates on WiFi the time it takes to send a packet is almost negligible compared to the time that is spent with Media Access Control (MAC) layer operations. Reducing the packet size makes little difference to the available capacity. For a serial line, it does not matter how big the packets are.
例として、ビデオの場合、輻輳を緩和するには、小さいパケットを送信するのではなく、1秒あたりのパケット数を減らす必要があります。WiFiのビットレートが高いと、パケットの送信にかかる時間はほとんど無視できるためです。メディアアクセス制御（MAC）レイヤーの操作に費やされる時間。パケットサイズを小さくしても、使用可能な容量にはほとんど違いがありません。シリアル回線の場合、パケットの大きさは関係ありません。
From a network point of view, the goals of congestion control therefore are:
したがって、ネットワークの観点から、輻輳制御の目標は次のとおりです。
1. Avoid congestion collapse
1. 混雑の崩壊を回避する
2. Avoid starvation of TCP flows
2. TCPフローの枯渇を回避する
3. Avoid starvation of real-time flows, specifically in the case where TCP and real-time flows share the same FIFO queue.
3. 特にTCPフローとリアルタイムフローが同じFIFOキューを共有する場合は、リアルタイムフローの枯渇を避けてください。
From an application point of view, the goals of congestion control are different, namely:
アプリケーションの観点から見ると、輻輳制御の目的は異なります。
1. Robust behavior. One wants to have a good throughput when the network is working well and passable performance when the network is working poorly.
1. 堅牢な動作。ネットワークがうまく機能しているときは良好なスループットを、ネットワークがうまく機能していないときはまずまずのパフォーマンスを望んでいます。
2. Predictable behavior. This matters from a usability point of view since variable media creates a bad user experience.
2. 予測可能な動作。可変メディアはユーザーエクスペリエンスを低下させるため、これはユーザビリティの観点から重要です。
3. Low latency. With large buffers along the end-to-end path, latency will increase when interactive real-time flows compete with TCP flows. This results in TCP filling up the buffers; increased buffering will lead to additional delays for the delivery of the interactive real-time media.
3. 低レイテンシ。エンドツーエンドパスに沿って大きなバッファーが存在する場合、インタラクティブなリアルタイムフローがTCPフローと競合すると、レイテンシが増加します。これにより、TCPがバッファをいっぱいにします。バッファリングを増やすと、インタラクティブなリアルタイムメディアの配信に追加の遅延が発生します。
Attempts to provide congestion control for interactive real-time media have previously been made in the IETF, for example, with the work on TCP Friendly Rate Control (TFRC) [12]. TFRC illustrates the challenges quite well. TFRC tries to accomplish the same throughput as TCP, but with a smoother transmission rate. It measures the loss and the round-trip time but follows a similar model as TCP to determine the sending rate.
インタラクティブなリアルタイムメディアに輻輳制御を提供する試みは、IETFで以前に行われています。たとえば、TCPフレンドリーレートコントロール（TFRC）[12]に関する作業が行われています。 TFRCは課題を非常によく示しています。 TFRCは、TCPと同じスループットを実現しようとしますが、伝送速度はより滑らかです。損失と往復時間を測定しますが、TCPと同様のモデルに従って送信レートを決定します。
In a link with low statistical multiplexing, TCP can lead to bad oscillations. The sending rate hits the maximum rate of a bottleneck link, a lot of loss occurs, and then the sending rate peaks again. For very small buffers the result is acceptable, but bigger buffers lead to oscillations. The result is bad for networks and for applications. To deal with large buffers on these links, a short-term rate adaptation based on round-trip time (RTT) information is utilized in TRFC, but this requires good short-term RTT measurements.
統計的多重度が低いリンクでは、TCPが原因で振動が悪化する可能性があります。送信速度がボトルネックリンクの最大速度に達し、大量の損失が発生した後、送信速度が再びピークに達します。非常に小さいバッファーの場合、結果は許容可能ですが、大きいバッファーは振動を引き起こします。結果はネットワークにとってもアプリケーションにとっても悪いものです。これらのリンクで大きなバッファーを処理するために、往復時間（RTT）情報に基づく短期レート適応がTRFCで使用されますが、これには適切な短期RTT測定が必要です。
TRFC works pretty well in theory. TFRC assumes the network is in charge of the codec and that the codec can produce data at the demanded rate. Modern video codecs inherently produce variable-bitrate video streams based on the content being encoded, and it is hard to produce data at exactly the desired bitrate without excessive buffering or ugly quality changes.
TRFCは理論的には非常にうまく機能します。 TFRCは、ネットワークがコーデックを担当し、コーデックが要求されたレートでデータを生成できると想定しています。最新のビデオコーデックは本質的に、エンコードされるコンテンツに基づいて可変ビットレートのビデオストリームを生成します。過度のバッファリングや醜い品質変更を行わずに、希望するビットレートで正確にデータを生成することは困難です。
What if the codec is put in charge instead of the network? The network tells the codec the mean rate, but it does not worry about what happens in short time scales, and the codec matches the mean rate and does not worry whether it is over or under the rate for a relatively short time scale. This again leads to the low statistical multiplexing problem and leads to oscillations.
ネットワークの代わりにコーデックが担当された場合はどうなりますか？ネットワークはコーデックに平均レートを伝えますが、短い時間スケールで何が起こるかについては心配していません。また、コーデックは平均レートと一致しており、比較的短い時間スケールのレートを上回っているか下回っているかを心配していません。これにより、統計的多重化の問題が低くなり、発振が発生します。
Known congestion control mechanisms work well if they can respond quickly enough to changes and if they do not bump into the low statistical multiplexing problem.
既知の輻輳制御メカニズムは、変化に十分迅速に対応でき、統計的多重度の低い問題にぶつからない場合にうまく機能します。
To avoid the low statistical multiplexing problem, techniques for inferring link speed are needed. The work from Van Jacobson's pathchar [37] (and successors) serve as valuable input. The idea is to send short packet trains, to measure timing accurately, and to infer the link speed from the relative delay. If we know the link speed, we can avoid exceeding it. Congestion control can give us an approximate rate, but we must not exceed link speed. This is a hybrid between codec being in charge (most of the time) and the network being in charge. These work well for some links, but not for others. Wireless links where speed can change in less than a single RTT because of fading, bitrate adaption, etc., cause problems. We would like to have the codec and the network be in charge. However, they both cannot be in charge at the same time.
低統計的多重化の問題を回避するには、リンク速度を推測する技術が必要です。ヴァンジェイコブソンのパスチャー[37]（および後継者）の作品は、貴重な情報源となります。アイデアは、短いパケット列を送信し、タイミングを正確に測定し、相対遅延からリンク速度を推測することです。リンク速度がわかっていれば、それを超えないようにすることができます。輻輳制御によっておおよその速度が得られますが、リンク速度を超えることはできません。これは、担当しているコーデック（ほとんどの場合）と担当しているネットワークのハイブリッドです。これらは、一部のリンクでは機能しますが、他のリンクでは機能しません。フェージング、ビットレートの適応などが原因で速度が1つのRTT未満で変化する可能性があるワイヤレスリンクは、問題を引き起こします。コーデックとネットワークを担当してもらいたい。ただし、両方を同時に担当することはできません。
Mark indicated that he is not entirely sure whether RTCP is suitable for congestion control. RTCP gives feedback, but it cannot send it often enough to avoid bumping into link speed. Circuit breakers [3], on the other hand, do not help to give good performance on an uncongested path. With circuit breakers, the sender measures the loss rate and RTT, and runs with a loose "cap."
Markは、RTCPが輻輳制御に適しているかどうかは完全にはわからないことを示しました。 RTCPはフィードバックを提供しますが、リンク速度への衝突を回避するのに十分な頻度でフィードバックを送信することはできません。一方、サーキットブレーカー[3]は、輻輳していないパスで良好なパフォーマンスを得るのに役立ちません。回路ブレーカーを使用すると、送信者は損失率とRTTを測定し、緩やかな「上限」で実行します。
In conclusion, Mark Handley claimed that we know how to do good congestion control, but only if congestion control is in charge, and that's not acceptable for real-time applications. We only know how to do good congestion control if we change the packet/sec rate and not the packet size.
結論として、Mark Handleyは、適切な輻輳制御を行う方法を知っていると主張しましたが、これは、輻輳制御が担当している場合に限られ、リアルタイムアプリケーションでは受け入れられません。パケットサイズではなくパケット/秒のレートを変更した場合にのみ、適切な輻輳制御を行う方法がわかります。
This second part of the workshop was focused on the presentation and the discussion of data gathered from simulations and real-world measurements.
ワークショップのこの第2部では、シミュレーションと実際の測定から収集されたデータのプレゼンテーションとディスカッションに焦点が当てられました。
Keith Winstein started the discussion with his presentation of measurements performed in cellular operator networks in the US [22]. The measurements indicate that the analyzed cellular networks showed varying RTT with transient latency spikes to hundreds of milliseconds, link speed that varies by a factor of 10 in a short time scale, and buffers that do not drop packets until they contain 5-10 seconds of data at bottleneck link speed.
キース・ウィンスタインは、米国の携帯電話事業者ネットワークで実行された測定のプレゼンテーションから議論を始めました[22]。測定結果は、分析されたセルラーネットワークが、数百ミリ秒までの一時的なレイテンシスパイクを伴うさまざまなRTT、短い時間スケールで10倍異なるリンク速度、および5〜10秒のパケットを含むまでパケットをドロップしないバッファーを示したことを示しています。ボトルネックリンク速度でのデータ。
Zaheduzzaman Sarker [21] presented results from real-time video communication in a Long Term Evolution (LTE) simulator utilizing ECN-based packet marking and adaptation using implicit methods like packet loss and delay. ECN marking provides ways for the network to explicitly signal congestion and hence distributes the cost of congestion well and helps achieve lower latency. However, although RFC 3168 [19] was finalized in 2001, the deployment of ECN is still lacking as investigated by Bauer, et al. [25]. A few participants noted that they believe that the deployment of LTE networks will also increase the deployment of ECN with the recent work on ECN for RTP over UDP [11].
Zaheduzzaman Sarker [21]は、ECNベースのパケットマーキングとパケット損失や遅延などの暗黙的な方法を使用した適応を利用したLong Term Evolution（LTE）シミュレーターでのリアルタイムビデオ通信の結果を発表しました。 ECNマーキングは、ネットワークが輻輳を明示的に通知する方法を提供するため、輻輳のコストを適切に分散し、レイテンシを短縮するのに役立ちます。ただし、RFC 3168 [19]は2001年に確定しましたが、バウアー他が調査したように、ECNの展開はまだ不十分です。 [25]。数人の参加者は、LTEネットワークの導入により、RTP over UDP [11]のECNに関する最近の取り組みにより、ECNの導入も増えると考えていると指摘しました。
Mo Zahaty [20] discussed TFRC [12] and TFRC with weighted fairness (MulTFRC) [4], which tunes TFRC to consider multiple flows, and showed the impact of RTT and loss rates on the type of video quality that can be achieved under those conditions. TFRC requires frequent feedback, which RTCP does not provide even when considering the extended RTP profile for RTCP-based feedback (RFC 4585 [5]). Mo argued that application-specified weighted fairness is important but while MulTFRC provides better performance than TFRC, it is not clear whether the added complexity over an n-times-TFRC approach is indeed worth the effort.
Mo Zahaty [20]は、TFRC [12]とTFRCを重み付き公平性（MulTFRC）[4]で議論し、TFRCを調整して複数のフローを考慮するようにし、RTTと損失率がビデオ品質のタイプに与える影響を示しました。それらの条件。 TFRCは頻繁なフィードバックを必要としますが、RTCPは、RTCPベースのフィードバック用の拡張RTPプロファイルを検討する場合でも提供しません（RFC 4585 [5]）。 Moは、アプリケーション指定の加重公平性が重要であると主張しましたが、MulTFRCはTFRCよりも優れたパフォーマンスを提供しますが、n倍のTFRCアプローチに追加された複雑さが本当に努力に値するかどうかは明らかではありません。
Markku Kojo shared analysis results of how real-time audio is affected by competing TCP flows. In the experiments shown in Figure 2 of [27], a real-time interactive audio stream had to compete against one TCP flow and, as a comparison, against six TCP flows. With one concurrent TCP flow, voice is impacted on startup and six TCP flows destroy the quality of the call. Two types of losses were analyzed, namely losses that result from a packet being dropped in the network (e.g., due to congestion or link errors) and losses that result from the delayed arrival of the packet (due to buffering) when the audio packet misses the deadline for the codec to decode and play the transmitted content. Consequently, even a moderate number of TCP flows typically used by browsers to retrieve content on web pages in parallel causes irreparable harm for audio transfers. The size of the initial window (IW) also impacts interactive real-time communication since a larger TCP IW size (e.g., IW10 with ten segments, as proposed in [18], instead of three) leads to a bigger burst of packets because of the initial window transmission. Note that the study in [24] does not necessarily lead to the same conclusion. It claims that the increased initial window size leads to no impact or only modest impact for buffering in the majority of cases.
Markku Kojoは、リアルタイムオーディオが競合するTCPフローによってどのように影響を受けるかについての分析結果を共有しました。 [27]の図2に示す実験では、リアルタイムのインタラクティブオーディオストリームは、1つのTCPフローと比較し、比較として6つのTCPフローと比較しなければなりませんでした。 1つの同時TCPフローでは、起動時に音声が影響を受け、6つのTCPフローが通話の品質を破壊します。 2つのタイプの損失が分析されました。1つは、ネットワークでドロップされたパケット（輻輳またはリンクエラーなど）による損失と、オーディオパケットが欠落したときの（バッファリングによる）パケットの遅延到着による損失です。コーデックが送信されたコンテンツをデコードして再生する期限。その結果、ブラウザがWebページのコンテンツを並行して取得するために通常使用する適度な数のTCPフローでさえ、オーディオ転送に回復不能な害を及ぼします。初期ウィンドウ（IW）のサイズもインタラクティブなリアルタイム通信に影響します。これは、TCP IWサイズが大きい場合（たとえば、[18]で提案されているように、3つのセグメントではなく、10セグメントのIW10）、パケットのバーストが大きくなるためです。初期ウィンドウ送信。 [24]の研究は必ずしも同じ結論につながるわけではないことに注意してください。それは、初期ウィンドウサイズの増加が、ほとんどの場合、バッファリングに影響を与えないか、わずかな影響しか与えないと主張しています。
Cullen Jennings [28] presented measurement results showing interactions between RTP and TCP flows for several widely deployed video communication products: Apple FaceTime, Google Hangout, Cisco Movi, and Microsoft Skype. While all tested products implemented some form of congestion control, none of the applications did additive increase and multiplicative decrease (AIMD). In general, it was observable that video adapts more slowly than AIMD to changes in available bandwidth because most codecs cannot make small increases in sending rates when available bandwidth increases, and do not make large decreases in sending rates when available bandwidth decreases, in order to improve the user's experience.
カレン・ジェニングス[28]は、広く普及しているいくつかのビデオ通信製品（Apple FaceTime、Google Hangout、Cisco Movi、Microsoft Skype）のRTPとTCPフロー間の相互作用を示す測定結果を発表しました。テストされたすべての製品は何らかの形の輻輳制御を実装しましたが、どのアプリケーションも相加的増加と乗法的減少（AIMD）を行いませんでした。一般に、使用可能な帯域幅が増加してもほとんどのコーデックは送信レートを少し上げることができず、利用可能な帯域幅が減少しても送信レートを大幅に低下させないため、ビデオはAIMDよりもゆっくりと適応して利用可能な帯域幅の変化に適応します。ユーザーのエクスペリエンスを向上させます。
Stefan Holmer [43] investigated the difference between loss-based and delay-based congestion control algorithms. The suitability of loss-based congestion control schemes for interactive real-time communication systems heavily depends on buffer sizes and the deployment of active queue management mechanisms. If most routers are using tail-drop queuing, then loss-based congestion control cannot fulfill the requirements of interactive real-time applications since those flows will effectively increase the bitrate until a loss event is identified, which only happens when the bottleneck queue is full.
Stefan Holmer [43]は、損失ベースと遅延ベースの輻輳制御アルゴリズムの違いを調査しました。対話型リアルタイムコミュニケーションシステムの損失ベースの輻輳制御方式の適合性は、バッファサイズとアクティブなキュー管理メカニズムの展開に大きく依存します。ほとんどのルーターがテールドロップキューイングを使用している場合、損失ベースの輻輳制御はインタラクティブリアルタイムアプリケーションの要件を満たすことができません。これらのフローは、ボトルネックキューがいっぱいの場合にのみ発生する損失イベントが識別されるまで、実質的にビットレートを増加させるためです。 。
During the remaining part of the workshop, the participants discussed design aspects of both the problem and solution spaces. The discussions started with a presentation by Jim Gettys about problems related to bufferbloat [31][36]. Bufferbloat is "a phenomenon in packet-switched networks, in which excess buffering of packets causes high latency and packet delay variation (also known as jitter), as well as reducing the overall network throughput" [39]. A certain amount of buffering is helpful to improve the efficiency. Not dropping packets in the event of congestion leads to increasing delays for interactive real-time communication.
ワークショップの残りの部分で、参加者は問題とソリューションスペースの両方の設計面について話し合いました。議論は、バッファブロート[31] [36]に関連する問題についてのジムゲティスによるプレゼンテーションから始まりました。 Bufferbloatは、「パケット交換ネットワークにおける現象であり、パケットの過剰なバッファリングにより、レイテンシとパケット遅延の変動（ジッターとしても知られる）が発生し、ネットワーク全体のスループットが低下します」[39]。効率を向上させるには、ある程度のバッファリングが役立ちます。輻輳時にパケットをドロップしないと、インタラクティブなリアルタイム通信の遅延が増加します。
Packets may get buffered at various places along the end-to-end path including in the operating system/device drivers, customer premise equipment (such as cable modem and DSL routers), base stations, and routers. While the understanding of too large buffers has improved over the last few years, workshop participants were still concerned that many equipment manufacturers and network operators do not yet acknowledge the existence of the problem. This lack of understanding is caused by the strong focus on throughput network performance measurements that do not take latency into account. For example, only recently the Federal Communications Commission (FCC) has added latency tests to their test suites [41].
パケットは、オペレーティングシステム/デバイスドライバー、顧客宅内機器（ケーブルモデムやDSLルーターなど）、基地局、ルーターなど、エンドツーエンドパスに沿ったさまざまな場所でバッファーに入れられることがあります。バッファが大きすぎることについての理解は過去数年で改善されましたが、ワークショップの参加者は、多くの機器メーカーやネットワークオペレーターがまだ問題の存在を認識していないことに懸念を抱いていました。この理解の欠如は、遅延を考慮しないスループットネットワークパフォーマンス測定に重点を置いていることが原因です。たとえば、つい最近になって、連邦通信委員会（FCC）がテストスイートにレイテンシテストを追加しました[41]。
Active queue management (AQM) aims to prevent queues from growing too large. This is accomplished by monitoring queue length and informing the sender by dropping or marking packets to lower their transmission rate. Random Early Detection (RED) [9] is one such AQM algorithm, but it has not been widely deployed in routers largely because of challenges to configure it correctly [32]. According to [23], RED does not work with the default settings as it is "too "gentle" to handle fast changes due to TCP slow start, when the aggregate traffic is limited." There may also be a lack of incentives to deploy AQM algorithms. Participants speculated about the time it takes to update network equipment (to support AQM algorithms), considering the different replacement cycles of these devices.
アクティブキュー管理（AQM）は、キューが大きくなりすぎるのを防ぐことを目的としています。これは、キューの長さを監視し、送信レートを下げるためにパケットをドロップまたはマーキングすることによって送信者に通知することによって達成されます。ランダム早期検出（RED）[9]は、そのようなAQMアルゴリズムの1つですが、正しく構成することが難しいため、ルーターに広く展開されていません[32]。 [23]によると、REDは「総トラフィックが制限されている場合、TCPのスロースタートによる高速な変更を処理するには「穏やかすぎる」」ため、デフォルト設定では機能しません。また、AQMアルゴリズムを展開するインセンティブがない場合もあります。参加者は、これらのデバイスのさまざまな交換サイクルを考慮して、（AQMアルゴリズムをサポートするために）ネットワーク機器を更新するのにかかる時間について推測しました。
One outcome of that discussion on AQM at the workshop was a Birds of a Feather ("BoF") meeting on "Active Queue Management and Packet Scheduling" at IETF 87 (July 28 - August 5, 2013, Berlin, Germany). The AQM WG [35] was chartered a few weeks later and is now designing AQM and network infrastructure improvements to deal with bufferbloat and related issues.
ワークショップでのAQMに関するその議論の結果の1つは、IETF 87（2013年7月28日から8月5日、ドイツのベルリン）での「アクティブキュー管理とパケットスケジューリング」に関するBirds of a Feather（ "BoF"）ミーティングでした。 AQM WG [35]は数週間後にチャーターされ、現在、バッファブロートと関連する問題に対処するためにAQMとネットワークインフラストラクチャの改善を設計しています。
Measurement tools that allow an end user to determine the performance of his or her network, including latency, is seen as a promising approach to motivate network operators to upgrade their equipment and to make use of AQM algorithms. Measurement tools would allow users to determine how bad their networks perform and to complain to their ISP, thereby creating a market force. As to what the right performance measurement metrics are, it was noted that the intent of the IETF IP Performance Metrics (IPPM) working group [33] was to develop such metrics to qualify networks. That work may have begun before its time, but there have been recent attempts to revisit the measurement work and an effort by the FCC has gotten a lot of attention recently (see [7] and [42]).
エンドユーザーがネットワークのパフォーマンス（遅延を含む）を判断できるようにする測定ツールは、ネットワークオペレーターが機器をアップグレードし、AQMアルゴリズムを利用する意欲を高める有望なアプローチと見なされています。ユーザーは、測定ツールを使用して、ネットワークのパフォーマンスを判断し、ISPに不満を言うことができます。適切なパフォーマンス測定メトリックについては、IETF IPパフォーマンスメトリック（IPPM）ワーキンググループ[33]の意図は、ネットワークを認定するためのそのようなメトリックを開発することであることが指摘されました。その作業はそれ以前に始まった可能性がありますが、最近測定作業を再検討する試みがあり、FCCによる取り組みが最近多くの注目を集めています（[7]および[42]を参照）。
Matt Mathis and others argued that the traffic of throughput-maximizing and delay-minimizing applications need to be in separate queues (segregated queuing). Requiring segregated queues assumes you are sharing the network with other greedy traffic. Quality-of-Service (QoS) signaling is a way to deploy segregated queuing, but there are several simpler alternatives, such as Stochastic Fair Queuing [38]. The Controlled Delay (CoDel) AQM algorithm [6] can also be used in combination with stochastic fair queuing. Note that queue segregation is not necessary for every router to implement; using it at the edge of a network where bottleneck links are located is already sufficient.
Matt Mathisらは、スループットを最大化し、遅延を最小化するアプリケーションのトラフィックは、別々のキュー（分離キューイング）に入れる必要があると主張しました。分離されたキューが必要なのは、ネットワークを他の貪欲なトラフィックと共有していることを前提としています。サービス品質（QoS）シグナリングは、隔離されたキューイングを展開する方法ですが、確率的フェアキューイングなど、より簡単な代替策がいくつかあります[38]。 Controlled Delay（CoDel）AQMアルゴリズム[6]は、確率的公平キューイングと組み合わせて使用することもできます。キューの分離は、すべてのルーターが実装する必要はないことに注意してください。ボトルネックリンクが配置されているネットワークのエッジでそれを使用することで、すでに十分です。
It was noted that current interactive voice usage over the Internet works most of the time satisfactorily. In typical networks, the reason voice works is because networks are underloaded. As long as there is idle capacity and the queue is empty when packets arrive, traffic does not need to be separated into distinct queues. Further explanations were offered as to why many networks work surprisingly well: Low Extra Delay Background Transport (LEDBAT) [8] is used for the download of software updates, voice traffic contributes only a small percentage of the overall Internet traffic, and users employ "human protocols" (e.g., parents asking their kids to get off the network during the time of a conference call).
現在のインターネットを介したインタラクティブな音声の使用はほとんどの場合問題なく機能することが指摘されています。一般的なネットワークで音声が機能するのは、ネットワークの負荷が低いためです。アイドル容量があり、パケットが到着したときにキューが空である限り、トラフィックを個別のキューに分離する必要はありません。多くのネットワークが驚くほどうまく機能する理由について、さらに説明がありました。ソフトウェア更新のダウンロードには、低遅延バックグラウンドトランスポート（LEDBAT）[8]が使用され、インターネットトラフィック全体のうち音声トラフィックが占める割合はわずかであり、ユーザーは「ヒューマンプロトコル」（例：電話会議中に両親が子供にネットワークから降りるように求める）。
Cullen Jennings raised a concern that although interactive voice may be functional without a congestion control mechanism, the potentially large uptake of interactive video spurred on by Real-Time Communications on the Web (RTCWEB) could create substantially more significant problems. In the class of space where voice is currently working, video may fail. Ted Hardie countered by saying that RTCWEB is trying to replace existing proprietary technologies. It may ramp up the amount of use we are expecting, but it is not doing much that was not being done by Adobe Flash or Skype. RTCWEB is not a totally novel context of Internet usage. Magnus Westerlund added that RTCWEB might be the driver for the moment, but web browsers are not the only consumers of such congestion control algorithm.
Cullen Jenningsは、輻輳制御メカニズムがなくてもインタラクティブな音声は機能するかもしれないが、Web上のリアルタイムコミュニケーション（RTCWEB）によって刺激されるインタラクティブビデオの潜在的な大量の取り込みにより、さらに重大な問題が発生する可能性があるという懸念を提起しました。現在音声が機能しているクラスのスペースでは、ビデオが失敗する場合があります。 Ted Hardieさんは、RTCWEBは既存の独自技術を置き換えようとしていると述べて反論しました。予想される使用量が増加する可能性がありますが、Adobe FlashやSkypeで行われていないことはそれほど多くありません。 RTCWEBは、インターネット使用のまったく新しいコンテキストではありません。 Magnus Westerlundは、RTCWEBが今のところドライバーかもしれないと付け加えました、しかしウェブブラウザはそのような輻輳制御アルゴリズムの唯一の消費者ではありません。
Furthermore, Ted Hardie noted that applications will not produce media streams that grow to 10 Mbps because their sending rate is auto rate limited by the production of the video. He suggested to ask ourselves if we are trying to get TCP to be friendly to media streams that are already rate limited or if we are asking media streams that are already rate limited to be TCP friendly. To quote Andrew McGregor: "It's really not good to be TCP friendly because it's not going to return the favor." If the desired properties we want are no starvation, fairness, and effective goodput for the offered loads, are we only willing to consider changes in RTP control, or are we willing to consider changes in TCP congestion control? This led to a discussion about whether the development of a congestion control algorithm for interactive real-time applications provides any value if network equipment suffers from bufferbloat. Is there something that can be done today to help interactive real-time media or do we have to wait to get the network updated first? Replacing home routers and updating routers with modern AQM algorithms was seen as a longer-term effort. Also, the time scale for changing TCP's congestion control is on the same time scale as deploying ECN [19]. Colin Perkins noted that we cannot change TCP quickly; the way TCP is being used is changing quickly, and we can impact the way TCP is used. When TCP is used for file transfer, it will send data as fast as it can, but when TCP is used for WebSockets, the dynamics are different. WebSockets and SPDY are clearly changing the behavior of TCP. Also, Netflix-style video-streaming applications are huge users of TCP and those applications can change rather quickly. Matt Mathis added that real-time videoconferencing almost always produces video streams at a lower bitrate than downloading equivalent-sized stored video using best-effort file-sharing.
さらに、テッドハーディ氏は、送信レートはビデオの制作によって自動レート制限されるため、アプリケーションは10 Mbpsに成長するメディアストリームを生成しないと指摘しました。彼は、TCPがすでにレート制限されているメディアストリームにフレンドリーになるようにしようとしているのか、それともすでにレート制限されているメディアストリームにTCPフレンドリーになるように求めているのか、自問することを提案しました。 Andrew McGregorを引用すると、「TCPに友好的であるのは、好意を返さないので、実際には良くありません。」必要なプロパティが、提供された負荷に対する飢餓、公平性、効果的なグッドプットでない場合、RTP制御の変更のみを考慮してもよいですか、それともTCP輻輳制御の変更を考慮してもよいですか？これにより、インタラクティブなリアルタイムアプリケーション用の輻輳制御アルゴリズムの開発が、ネットワーク機器がバッファブローに苦しんでいる場合に何らかの価値をもたらすかどうかについての議論につながりました。インタラクティブなリアルタイムメディアを支援するために今日できることはありますか、それともネットワークが最初に更新されるのを待つ必要がありますか？ホームルーターの置き換えと最新のAQMアルゴリズムによるルーターの更新は、長期的な取り組みと見なされていました。また、TCPの輻輳制御を変更するためのタイムスケールは、ECNの展開と同じタイムスケールです[19]。 Colin Perkinsは、TCPをすばやく変更することはできないと述べました。 TCPの使用方法は急速に変化しており、TCPの使用方法に影響を与える可能性があります。 TCPがファイル転送に使用される場合、データをできるだけ速く送信しますが、TCPがWebSocketsに使用される場合、ダイナミクスは異なります。 WebSocketsとSPDYは、TCPの動作を明らかに変えています。また、NetflixスタイルのビデオストリーミングアプリケーションはTCPの大規模なユーザーであり、これらのアプリケーションはすぐに変更される可能性があります。 Matt Mathis氏は、リアルタイムビデオ会議は、ほとんどの場合、ベストエフォートのファイル共有を使用して同等サイズの保存されたビデオをダウンロードするよりも低いビットレートでビデオストリームを生成することを付け加えました。
Bill Ver Steeg suggested to consider three different deployment environments, namely:
Bill Ver Steegは、次の3つの異なる展開環境を検討することを提案しました。
1. Flows competing with flows from the host ("self-inflicted queuing delay")
1. ホストからのフローと競合するフロー（「自発的なキューイング遅延」）
2. Flows competing with flows in the same subnetwork (e.g., home network)
2. 同じサブネットワーク（例：ホームネットワーク）内のフローと競合するフロー
3. Flows competing with flows from other networks (e.g., traffic from different households that utilize the same DSL provider)
3. 他のネットワークからのフローと競合するフロー（たとえば、同じDSLプロバイダーを利用する異なる世帯からのトラフィック）
The narrowest problem domain that makes sense is to avoid self-inflicted queuing delay. Michael Welzl indicated that this requires an information exchange (called flow-state exchange) inside a browser (at the level of the same host or even beyond, as described in [29]) to synchronize congestion control of different audio, video, and data flows. Although it would provide great benefits if one could share information about a bottleneck with all the flows sharing that bottleneck, this is considered challenging even within a single host. John Leslie [30] also noted: "We're acting as if we believe congestion will magically be solved by a new transport algorithm. It won't." Instead, an interaction between the network layer, transport layer, and the application layer is needed whereby the application layer is the only practical place to balance what piece(s) to constrain to lower bandwidths. All flows relating to a user session should have a common congestion controller. For many applications, audio is much more critical than video. In those cases, the video may back off, but the audio transmission remains unchanged.
意味のある最も狭い問題領域は、自己によるキューイング遅延を回避することです。 Michael Welzlは、異なるオーディオ、ビデオ、およびデータの輻輳制御を同期するには、ブラウザー内（[29]で説明されているように、同じホストのレベルまたはそれ以上）で情報交換（フロー状態交換と呼ばれる）が必要であることを示しました流れ。ボトルネックに関する情報をそのボトルネックを共有するすべてのフローと共有できれば、大きなメリットがありますが、これは単一のホスト内でも困難であると考えられています。ジョンレスリー[30]はまた、次のように述べています。「私たちは、輻輳が新しいトランスポートアルゴリズムによって魔法のように解決されると信じているかのように行動しています。解決されません。」代わりに、ネットワーク層、トランスポート層、およびアプリケーション層の間の相互作用が必要です。これにより、アプリケーション層は、帯域幅を低く抑えるために制約する部分のバランスを取る唯一の実用的な場所になります。ユーザーセッションに関連するすべてのフローには、共通の輻輳コントローラーが必要です。多くのアプリケーションでは、オーディオはビデオよりもはるかに重要です。これらの場合、ビデオはバックオフする可能性がありますが、オーディオ伝送は変更されません。
Mo Zanaty pointed to the importance of the media start-up behavior, which is an area where the exchange of real-time interactive media is different from a TCP-based file transfer. The instantaneous experience in the first part of a video call is highly determinative of people's perception of the call quality. Vendors are using vague heuristics, for example, data from the last call to figure out what to do on the next call. Lars Eggert highlighted that the start-up behavior of an application affects ongoing performance of other flows if, for example, an application blasts at line rate at the beginning of a video stream. You need to start slow enough to not cause congestion to others. Randell Jesup argued that for an interactive real-time video application, you really need to have most of your bandwidth right away. Colin Perkins agreed and added that on startup you need good quality video quickly, but perhaps not as quickly as voice. The requirements are likely going to be different from audio to video and maybe even vary between different applications. Various protocol exchanges take place before media is exchanged between endpoints (such as Session Traversal Utilities for NAT (STUN) packets [13] as part of the Interactive Connectivity Establishment (ICE) [15] or a Datagram Transport Layer Security (DTLS) handshake [14]) and may be used to obtain simple start-up measurements.
Mo Zanatyは、メディアの起動動作の重要性を指摘しました。これは、リアルタイムのインタラクティブメディアの交換がTCPベースのファイル転送とは異なる領域です。ビデオ通話の最初の部分での瞬間的な体験は、通話品質に対する人々の認識を非常に左右します。ベンダーは、曖昧なヒューリスティックを使用しています。たとえば、最後の呼び出しからのデータを使用して、次の呼び出しで何をすべきかを理解しています。 Lars Eggert氏は、たとえば、アプリケーションがビデオストリームの開始時にラインレートでブラストした場合、アプリケーションの起動時の動作が他のフローの継続的なパフォーマンスに影響を与えることを強調しました。あなたは他の人に混雑を引き起こさないように十分にゆっくり始める必要があります。 Randell Jesupは、インタラクティブなリアルタイムビデオアプリケーションの場合、帯域幅のほとんどをすぐに確保する必要があると主張しました。 Colin Perkinsは同意し、起動時にはすぐに高品質のビデオが必要ですが、おそらく音声ほど速くないことを付け加えました。要件は、オーディオとビデオでは異なる可能性が高く、アプリケーションによって異なる場合もあります。エンドポイント間でメディアが交換される前に、さまざまなプロトコル交換が行われます（対話型接続確立（ICE）[15]またはデータグラムトランスポート層セキュリティ（DTLS）ハンドシェイクの一部として、NAT（STUN）パケットのセッショントラバーサルユーティリティ[13] 14]）、簡単な起動時の測定値を取得するために使用できます。
The group agreed that it is feasible to design a congestion control algorithm that works on mostly idle networks. In the view of the participants, upgrades of the network infrastructure can happen in parallel. This view was later confirmed at the RTP Media Congestion Avoidance Techniques (RMCAT) BoF meeting at IETF 84 (July 29 - August 3, 2012, Vancouver, BC, Canada) that led to the formation of the RMCAT working group [34].
グループは、ほとんどアイドル状態のネットワークで機能する輻輳制御アルゴリズムを設計することが可能であることに同意しました。参加者の視点では、ネットワークインフラストラクチャのアップグレードは並行して行われる可能性があります。この見解は、後にIETF 84でのRTPメディア輻輳回避技術（RMCAT）BoF会議（2012年7月29日-8月3日、カナダ、バンクーバー）で確認され、RMCATワーキンググループの結成につながった[34]。
The participants suggested to explore two primary solution tracks: changes to network infrastructure and the development of algorithms to avoid self-inflicted queuing. These are discussed below. A third approach recommended by some participants was to change the way TCP is used in browsers and other HTTP-based applications. For example, by not opening too many concurrent TCP connections, and by improving the interaction with other non-real-time applications (such as video streaming and file sharing), additional improvements can be made. The work on HTTP 2.0 with SPDY [16] is already a step in the right direction since SPDY makes use of a more aggressive form of multiplexing instead of opening a larger number of TCP connections.
参加者は、2つの主要なソリューショントラックを検討することを提案しました。ネットワークインフラストラクチャへの変更と、自己に起因するキューイングを回避するためのアルゴリズムの開発です。これらについては以下で説明します。一部の参加者が推奨した3番目のアプローチは、ブラウザーやその他のHTTPベースのアプリケーションでのTCPの使用方法を変更することでした。たとえば、同時に開くTCP接続が多すぎないようにし、他の非リアルタイムアプリケーション（ビデオストリーミングやファイル共有など）との相互作用を改善することで、さらに改善することができます。 SPDY [16]を使用したHTTP 2.0での作業は、正しい方向への一歩です。SPDYは、多数のTCP接続を開くのではなく、より積極的な形式の多重化を利用するためです。
As for all other traffic on the network, better data plane infrastructure improves the perceived quality of the best-effort service that the Internet provides for RTCWEB flows. The IETF has already developed several technologies that would be of immediate usefulness if they were to be deployed. The workshop participants expressed the hope that due to the volume and importance of RTCWEB traffic, some of these technologies might finally see widespread use.
ネットワーク上の他のすべてのトラフィックについては、データプレーンインフラストラクチャが優れているほど、インターネットがRTCWEBフローに提供するベストエフォートサービスの知覚品質が向上します。 IETFはすでに展開されている場合にすぐに役立つであろういくつかのテクノロジを開発しています。ワークショップの参加者は、RTCWEBトラフィックの量と重要性により、これらのテクノロジーの一部が最終的に広く使用される可能性があることへの期待を表明しました。
The first and by far most important improvement is traffic segregation: the ability to use different queues for different traffic types. Specifically, jitter- and delay-sensitive protocols would benefit from being in different queues from throughput-maximizing protocols. It is not possible for a single queue/AQM to be optimal for both.
最初の、そして最も重要な改善は、トラフィックの分離です。これは、異なるトラフィックタイプに対して異なるキューを使用する機能です。具体的には、ジッターと遅延の影響を受けやすいプロトコルは、スループットを最大化するプロトコルとは別のキューに入れることでメリットを得られます。単一のキュー/ AQMを両方に最適にすることはできません。
Furthermore, ECN allows routers along the end-to-end path to signal the onset of congestion and allows applications to respond early, avoiding losses and keeping queue sizes short and, therefore, end-to-end delay low. ECN is implemented on some end system stacks and routers, but is frequently not enabled. The participants expressed the importance of increasing the deployment of ECN, even if used initially only in closed environments, such as data centers (as with Data Center TCP (DCTCP) [26]).
さらに、ECNを使用すると、エンドツーエンドパスに沿ったルーターが輻輳の開始を通知し、アプリケーションが早期に応答して損失を回避し、キューサイズを短くして、エンドツーエンドの遅延を低く抑えることができます。 ECNは一部のエンドシステムスタックとルーターに実装されていますが、有効になっていないことがよくあります。参加者は、最初はデータセンターなどの閉じた環境でのみ使用されていても（データセンターTCP（DCTCP）[26]のように）、ECNの展開を増やすことの重要性を表明しました。
Different mechanisms have been developed to facilitate traffic segregation. Differentiated Services [10] is one possibility in this space. If applications start to mark outgoing traffic appropriately and routers segregate traffic accordingly, browsers could more directly control the relative importance of their various flows and avoid self-competition. Compared to ECN, however, DiffServ is far more difficult to deploy meaningfully end to end, especially given that Differentiated Services Code Points (DSCPs) have no defined end-to-end meaning and packets can be re-marked.
トラフィックの分離を容易にするために、さまざまなメカニズムが開発されています。差別化サービス[10]は、この分野での1つの可能性です。アプリケーションが発信トラフィックを適切にマークし始め、それに応じてルーターがトラフィックを分離すると、ブラウザはさまざまなフローの相対的な重要性をより直接的に制御し、自己競争を回避できます。ただし、ECNと比較して、DiffServを意味のあるエンドツーエンドで展開することははるかに困難です。特に、Differentiated Services Code Point（DSCP）にエンドツーエンドの意味が定義されておらず、パケットに再度マークを付けることができます。
QoS signaling together with resource reservation facilities would enable a fine-grained and flexible way to indicate resource needs to network elements, but it is also by far the most heavyweight proposal, and unlikely to be viable in the global Internet. However, as mentioned in Section 2.3, QoS signaling is not the only way to accomplish traffic segregation. Further investigations regarding stochastic fair queuing and new AQM algorithms are seen as desirable.
QoSシグナリングとリソース予約機能を併用すると、リソースのニーズをネットワーク要素に示すきめ細かで柔軟な方法が可能になりますが、これははるかにヘビーウェイトの提案であり、グローバルインターネットでは実現できない可能性があります。ただし、セクション2.3で説明したように、QoSシグナリングはトラフィックの分離を実現する唯一の方法ではありません。確率的公正キューイングと新しいAQMアルゴリズムに関するさらなる調査が望ましいと見られています。
In any case, network infrastructure updates will take time, particularly if the interest of the involved stakeholders is not aligned (as is often the case for network operators when dealing with over-the-top real-time traffic). It is, therefore, imperative that RTCWEB congestion control provides adequate improvement in the absence of any of the aforementioned schemes.
いずれの場合でも、特に関係する利害関係者の関心が一致しない場合は、ネットワークインフラストラクチャの更新に時間がかかります（ネットワークオペレーターがオーバーザトップのリアルタイムトラフィックを処理する場合によくあることです）。したがって、RTCWEBの輻輳制御が、前述のスキームがない場合に適切な改善を提供することが不可欠です。
This approach tries to ensure that the network does not suffer from congestion collapse and that one data flow from a single host does not harm another data flow from the same host. A single congestion manager within the end host or the browser could help to coordinate various congestion control activities and to ensure a more coordinated approach between different applications and different flows.
このアプローチは、ネットワークが輻輳の崩壊の影響を受けないようにし、単一のホストからの1つのデータフローが同じホストからの別のデータフローに悪影響を及ぼさないようにします。エンドホストまたはブラウザ内の単一の輻輳マネージャは、さまざまな輻輳制御アクティビティを調整し、さまざまなアプリケーションとさまざまなフロー間のより協調的なアプローチを保証するのに役立ちます。
The following design and testing aspects were considered relevant to this approach:
次の設計とテストの側面は、このアプローチに関連すると見なされました。
Reacting to All Congestion Signals:
すべての混雑信号に反応する：
To initiate the congestion control process, it is important to detect congestion in the communication path. Congestion can be detected using either an explicit mechanism or an implicit mechanism. An explicit mechanism involves direct congestion signaling usually from the congested network node, such as ECN. In case of an implicit mechanism, packet-loss events or observed delay increases are used as an indication for congestion. These measurements can also be made available in a variety of different protocols, such as RTCP reports or transport protocols. It is recommended for applications to take all available congestion signals into account and to couple the congestion control algorithm, the codec, and the application so that better information exchange between these components is possible since there are constraints on how quickly a codec can adapt to a specific sending rate.
輻輳制御プロセスを開始するには、通信パスの輻輳を検出することが重要です。輻輳は、明示的メカニズムまたは暗黙的メカニズムのいずれかを使用して検出できます。明示的なメカニズムには、通常、ECNなどの輻輳したネットワークノードからの直接的な輻輳シグナリングが含まれます。暗黙的なメカニズムの場合、パケット損失イベントまたは観測された遅延の増加は、輻輳の指標として使用されます。これらの測定値は、RTCPレポートやトランスポートプロトコルなど、さまざまなプロトコルで利用可能にすることもできます。アプリケーションは、利用可能なすべての輻輳信号を考慮し、輻輳制御アルゴリズム、コーデック、およびアプリケーションを結合して、これらのコンポーネント間のより良い情報交換が可能になるようにすることをお勧めします。特定の送信レート。
Delay- and Loss-Based Algorithms:
遅延および損失ベースのアルゴリズム：
The main goal of designing a congestion control algorithm for real-time conversational media is to achieve low latency. Explicit congestion signals provide the most reliable way for applications to react, but due to the lack of ECN deployment, delay-based algorithms are needed. Since there is large delay variation in wireless networks (even in a non-congested network), the workshop participants recommended that more research should be done to better understand non-congestion-related delay variation in the network. General consensus among the workshop participants was that latency-based congestion control algorithms are needed due to the lack of loss indications caused by large buffers, even though loss-based techniques dominate latency-based techniques when the two are competing for bandwidth.
リアルタイムの会話型メディア用の輻輳制御アルゴリズムを設計する主な目的は、低遅延を実現することです。明示的な輻輳信号は、アプリケーションが反応するための最も信頼できる方法を提供しますが、ECNの展開がないため、遅延ベースのアルゴリズムが必要です。ワイヤレスネットワークでは（輻輳していないネットワークでも）遅延の変動が大きいため、ワークショップの参加者は、ネットワークの輻輳に関連しない遅延の変動をより深く理解するために、さらに調査を行うことを推奨しました。ワークショップ参加者間の一般的なコンセンサスは、損失ベースの手法がレイテンシベースの手法を支配しているにもかかわらず、2つが帯域幅を競合している場合でも、大きなバッファによって引き起こされる損失指標がないため、レイテンシベースの輻輳制御アルゴリズムが必要であるということでした。
Algorithm Evaluation:
アルゴリズムの評価：
The Internet consists of heterogeneous networks, which include misconfigured and unmanaged network nodes. Bandwidth and latency vary a lot. Different services deployed using RTP/UDP have different requirements in terms of media quality. A congestion control algorithm needs to perform well not only in simulators but also in the deployed Internet. To achieve this, it is recommended to test the algorithms with real-world loss and delay figures to ensure that the desired audio/video rates are attainable using the proposed algorithms for the desired services.
インターネットは、構成が不適切な管理されていないネットワークノードを含む異種ネットワークで構成されています。帯域幅と待ち時間は大きく異なります。 RTP / UDPを使用して展開されるさまざまなサービスには、メディア品質の点でさまざまな要件があります。輻輳制御アルゴリズムは、シミュレータだけでなく、展開されたインターネットでもうまく機能する必要があります。これを実現するには、実際の損失と遅延の数値を使用してアルゴリズムをテストし、目的のサービスに対して提案されたアルゴリズムを使用して、目的のオーディオ/ビデオレートが達成できることを確認することをお勧めします。
Media Characteristics:
メディアの特徴：
Interactive real-time voice and video data are inherently variable. Usually the content of the media and service requirements dictate the media coding. The codec may be bursty and not all frames are equally important (e.g., I-frames are more important than P-frames). Thus, codecs have limited room for adaptation. Congestion control for audio and video codecs is, therefore, different from congestion control applied to bulk file transfers where buffering is not a problem and the transmission rate can be changed to any rate suitable for the congestion control algorithm. In the workshop, these limitations were brought up and the workshop participants recommended that a congestion controller needs to be aware of these constraints. However, further investigation is needed to decide what information needs to be exchanged between a codec and the congestion manager.
インタラクティブなリアルタイムの音声およびビデオデータは、本質的に変化します。通常、メディアの内容とサービスの要件によって、メディアのコーディングが決まります。コーデックはバースト的で、すべてのフレームが等しく重要であるとは限りません（たとえば、IフレームはPフレームよりも重要です）。したがって、コーデックには適応の余地が限られています。したがって、オーディオおよびビデオコーデックの輻輳制御は、バッファリングが問題ではなく、伝送速度を輻輳制御アルゴリズムに適した任意の速度に変更できるバルクファイル転送に適用される輻輳制御とは異なります。ワークショップでは、これらの制限が提示され、ワークショップの参加者は、輻輳コントローラがこれらの制約を認識する必要があることを推奨しました。ただし、コーデックと輻輳マネージャの間で交換する必要がある情報を決定するには、さらに調査が必要です。
Start-up Behavior:
起動時の動作：
The start-up media quality is very important for real-time interactive applications and for user-perceived application performance. The start-up behavior of these is also different from other traffic. By nature, real-time interactive communication applications want to provide a smooth user experience and maintain the best media quality possible to ease the interaction. While it may be desirable from a user-experience point of view to immediately start streaming video with high-definition quality and audio of a wideband codec, this will have impacts on the bandwidth of the already ongoing flows. As such, it would be ideal to start slow enough to avoid causing excessive congestion to other flows but fast enough to offer a good user experience. The sweet spot, however, yet has to be found.
起動時のメディアの品質は、リアルタイムの対話型アプリケーションとユーザーが感じるアプリケーションのパフォーマンスにとって非常に重要です。これらの起動時の動作も他のトラフィックとは異なります。本質的に、リアルタイムの対話型通信アプリケーションは、スムーズなユーザーエクスペリエンスを提供し、対話を容易にするために可能な限り最高のメディア品質を維持したいと考えています。ユーザーエクスペリエンスの観点からは、高解像度品質のビデオとワイドバンドコーデックのオーディオのストリーミングをすぐに開始することが望ましい場合がありますが、これは既に進行中のフローの帯域幅に影響を与えます。そのため、他のフローに過度の輻輳が発生するのを回避するのに十分な速度で開始するのが理想的ですが、優れたユーザーエクスペリエンスを提供するには十分な速度で開始します。ただし、スイートスポットはまだ見つかりません。
Two position papers focused on security, but these papers were not discussed during the workshop. As such, nothing beyond the material contained in those position papers can be reported.
2つのポジションペーパーはセキュリティに焦点を当てましたが、これらのペーパーはワークショップ中には議論されませんでした。そのため、これらのポジションペーパーに含まれている資料以外には何も報告できません。
We would like to thank the participants and the paper authors of the position papers for their input.
参加者と、ポジションペーパーの執筆者の意見に感謝します。
Additionally, we would like to thank the following persons for their review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt Mathis, Mary Barnes, Spencer Dawkins, Dave Thaler, and Alissa Cooper.
さらに、レビューコメントを提供してくれたMichael Welzl、John Leslie、Mirja Kuehlewind、Matt Mathis、Mary Barnes、Spencer Dawkins、Dave Thaler、およびAlissa Cooperに感謝します。
[1] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[1] Eggert、L。およびG. Fairhurst、「Unicast UDP Usage Guidelines for Application Designers」、BCP 145、RFC 5405、2008年11月。
[2] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[2] Floyd、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[3] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Work in Progress, February 2014.
[3] パーキンス、C。およびV.シン、「マルチメディア輻輳制御：ユニキャストRTPセッションのためのサーキットブレーカー」、進行中の作業、2014年2月。
[4] Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with weighted fairness", Work in Progress, July 2010.
[4] Welzl、M.、Damjanovic、D。、およびS. Gjessing、「MulTFRC：加重公平性を備えたTFRC」、Work in Progress、2010年7月。
[5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[5] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）」、RFC 4585、2006年7月。
[6] Nichols, K. and V. Jacobson, "Controlled Delay Active Queue Management", Work in Progress, March 2014.
[6] Nichols、K.およびV. Jacobson、「Controlled Delay Active Queue Management」、Work in Progress、2014年3月。
[7] Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale Measurement of Broadband Performance: Use Cases, Architecture and Protocol Requirements", Work in Progress, September 2012.
[7] Schulzrinne、H.、Johnston、W.、およびJ. Miller、「ブロードバンドパフォーマンスの大規模測定：ユースケース、アーキテクチャ、およびプロトコル要件」、作業中、2012年9月。
[8] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, December 2012.
[8] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、2012年12月。
[9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[9] ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、C。、 Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、1998年4月。
[10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[10] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、December 1998。
[11] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012.
[11] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、2012年8月。
[12] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[12] Floyd、S.、Handley、M.、Padhye、J.、and J. Widmer、 "TCP Friendly Rate Control（TFRC）：Protocol Specification"、RFC 5348、September 2008。
[13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[13] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[14] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[14] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[15] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[16] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", Work in Progress, June 2014.
[16] Belshe、M.、Peon、R。、およびM. Thomson、「Hypertext Transfer Protocol version 2」、Work in Progress、2014年6月。
[17] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[17] フロイドS.およびJ.ケンプ、「インターネットにおける音声トラフィックの輻輳制御に関するIABの懸念」、RFC 3714、2004年3月。
[18] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013.
[18] Chu、J.、Dukkipati、N.、Cheng、Y。、およびM. Mathis、「Increeasing TCP's Initial Window」、RFC 6928、2013年4月。
[19] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[19] ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[20] Zanaty, M., "Fairness Considerations for Congestion Control for Interactive Real-Time Communication (IRTC)", IAB/ RTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[20] Zanaty、M。、「対話型リアルタイム通信（IRTC）の輻輳制御に関する公平性の考慮」、対話型リアルタイム通信の輻輳制御に関するIAB / RTFワークショップ、2012年7月。
[21] Sarker, Z. and I. Johansson, "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[21] Sarker、Z。およびI. Johansson、「ネットワーク提供の輻輳通知によるインタラクティブリアルタイムビデオ通信の改善」、インタラクティブリアルタイム通信の輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
[22] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Congestion Control for Interactive Real-Time Flows on Today's Internet", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[22] Winstein、K.、Sivaraman、A。、およびH. Balakrishnan、「今日のインターネット上のインタラクティブリアルタイムフローの輻輳制御」、インタラクティブリアルタイム通信の輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
[23] Jarvinen, I., Ding, A., Nyrhinen, A., and M. Kojo, "Harsh RED: Improving RED for Limited Aggregate Traffic", In Proceedings of the 26th IEEE International Conference on Advanced Information Networking and Applications (AINA 2012), March 2012.
[23] Jarvinen、I.、Ding、A.、Nyrhinen、A.、M. Kojo、 "Harsh RED：Improving RED for Limited Aggregate Traffic"、Proceedings in the 26th IEEE International Conference on Advanced Information Networking and Applications（AINA 2012） 、2012年3月。
[24] Allman, M., "Comments on Bufferbloat", In ACM SIGCOMM Computer Communication Review, Volume 43, Issue 1, pp. 30-37, January 2013, <http://dl.acm.org/citation.cfm?doid=2427036.2427041>.
[24] Allman、M。、「Comments on Bufferbloat」、ACM SIGCOMM Computer Communication Review、Volume 43、Issue 1、30-37ページ、2013年1月、<http://dl.acm.org/citation.cfm?doid= 2427036.2427041>。
[25] Bauer, S., Beverly, R., and A. Berger, "Measuring the state of ECN readiness in servers, clients,and routers", In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11), New York, NY, USA, pp. 171-180, February 2011, <http://dl.acm.org/citation.cfm?doid=2068816.2068833>.
[25] Bauer、S.、Beverly、R。、およびA. Berger、「サーバー、クライアント、およびルーターでのECNの準備状況の測定」、インターネット測定会議に関する2011 ACM SIGCOMM会議の議事録（IMC '11）、新規ニューヨーク、ニューヨーク、米国、pp。171-180、2011年2月、<http://dl.acm.org/citation.cfm?doid=2068816.2068833>。
[26] Bauer, S., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data center TCP (DCTCP)", In Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM '10), New York, NY, USA, pp. 63-74, August 2010, <http://dl.acm.org/citation.cfm?doid=1851182.1851192>.
[26] Bauer、S.、Greenberg、A.、Maltz、D.、Padhye、J.、Patel、P.、Prabhakar、B.、Sengupta、S.、and M. Sridharan、 "Data center TCP（DCTCP）"、In ACM SIGCOMM 2010会議（SIGCOMM '10）の議事録、ニューヨーク、米国、pp。63-74、2010年8月、<http://dl.acm.org/citation.cfm?doid=1851182.1851192>。
[27] Jarvinen, I., Chemmagate, B., Daniel, L., Ding, A., Kojo, M., and M. Isomaki, "Impact of TCP on Interactive Real- Time Communication", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[27] Jarvinen、I.、Chemmagate、B.、Daniel、L.、Ding、A.、Kojo、M.、and M. Isomaki、 "Impact of TCP on Interactive Real-Time Communication"、IAB / IRTF Workshop on Congestion Control forインタラクティブなリアルタイム通信、2012年7月。
[28] Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered Harmfull", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[28] Jennings、C.、Nandakumar、S。、およびH. Phan、「ベンダーは害のないものだ」、インタラクティブリアルタイム通信の輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
[29] Welzl, M., "One control to rule them all", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[29] Welzl、M。、「すべてを統括する1つのコントロール」、インタラクティブリアルタイム通信の輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
[30] Leslie, J., "There is No Magic Transport Wand", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[30] レスリーJ.、「魔法の輸送の杖はありません」、インタラクティブリアルタイム通信のための輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
[31] Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the Internet", IEEE Internet Computing, Volume 15, Issue 3, pp. 95-96, May/June 2011.
[31] Gettys、J。およびJ. Gettys、「Bufferbloat：Dark Buffers in the Internet」、IEEE Internet Computing、Volume 15、Issue 3、95〜96ページ、2011年5月/ 6月。
[32] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active queue management algorithms", In IEEE/ACM Transactions on Networking, Volume 10, Issue 4, pp. 513-528, August 2002.
[32] Feng、W.、Shin、K.、Kandlur、D.、and D. Saha、 "The BLUE active queue management algorithm"、In IEEE / ACM Transactions on Networking、Volume 10、Issue 4、pp。513-528、August 2002年
[33] IETF, "IP Performance Metrics (ippm) Working Group", January 2012, <http://datatracker.ietf.org/wg/ippm/charter/>.
[33] IETF、「IP Performance Metrics（ippm）Working Group」、2012年1月、<http://datatracker.ietf.org/wg/ippm/charter/>。
[34] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) Working Group", January 2012, <http://datatracker.ietf.org/wg/rmcat/charter/>.
[34] IETF、「RTPメディア輻輳回避技術（rmcat）ワーキンググループ」、2012年1月、<http://datatracker.ietf.org/wg/rmcat/charter/>。
[35] IETF, "Active Queue Management and Packet Scheduling (aqm) Working Group", September 2013, <http://datatracker.ietf.org/wg/aqm/charter/>.
[35] IETF、「Active Queue Management and Packet Scheduling（aqm）Working Group」、2013年9月、<http://datatracker.ietf.org/wg/aqm/charter/>。
[36] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", Communications of the ACM, Vol. 55, No. 1, pp. 57-65, January 2012, <http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/>.
[36] Gettys、J. and K. Nichols、 "Bufferbloat：Dark Buffers in the Internet"、Communications of the ACM、Vol。 55、No。1、57-65ページ、2012年1月、<http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/>。
[37] Jacobson, V., "pathchar - a tool to infer characteristics of Internet paths", Presented at the Mathematical Sciences Research Institute, April 1997, <ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf>.
[37] Jacobson、V。、「pathchar-インターネットパスの特性を推測するツール」、1997年4月、数理科学研究所、<ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf>で発表。
[38] McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90 Proceedings, Volume 2, pp. 733-740, June 1990.
[38] McKenney、P。、「Stochastic Fairness Queuing」、IEEE INFOCOM'90 Proceedings、Volume 2、pp。733-740、1990年6月。
[39] Wikipedia, "Bufferbloat", May 2014, <http://en.wikipedia.org/w/ index.php?title=Bufferbloat&oldid=608805474>.
[39] Wikipedia、「Bufferbloat」、2014年5月、<http://en.wikipedia.org/w/ index.php？title = Bufferbloat＆oldid = 608805474>。
[40] Wikipedia, "Video compression picture types", March 2014, <http://en.wikipedia.org/w/index.php? title=Video_compression_picture_types&oldid=602183340>.
[40] ウィキペディア、「ビデオ圧縮画像タイプ」、2014年3月、<http://en.wikipedia.org/w/index.php？ title = Video_compression_picture_types＆oldid = 602183340>。
[41] FCC, "Methodology - Measuring Broadband America July Report 2012", July 2012, <http://www.fcc.gov/ measuring-broadband-america/2012/methodology-july-report-2012>.
[41] FCC、「Methodology-Measurement Broadband America July Report 2012」、2012年7月、<http://www.fcc.gov/ Measurement-broadband-america / 2012 / methodology-july-report-2012>。
[42] IETF, "lmap -- Large Scale Measurement of Access network Performance Mailing List", 2012, <https://www.ietf.org/mailman/listinfo/lmap>.
[42] IETF、「lmap-Access network Performance Mailing Listの大規模測定」、2012、<https://www.ietf.org/mailman/listinfo/lmap>。
[43] Holmer, S., "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[43] Holmer、S.、「リアルタイムの輻輳制御へのさまざまなアプローチの公平性、遅延、およびシグナリングについて」、インタラクティブリアルタイム通信の輻輳制御に関するIAB / IRTFワークショップ、2012年7月。
This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, and Hannes Tschofenig.
このワークショップは、Harald Alvestrand、Bernard Aboba、Mary Barnes、Gonzalo Camarillo、Spencer Dawkins、Lars Eggert、Matthew Ford、Randell Jesup、Cullen Jennings、Jon Peterson、Robert Sparks、およびHannes Tschofenigによって主催されました。
o Main Workshop Page: http://www.iab.org/activities/workshops/cc-workshop/
o メインワークショップページ：http://www.iab.org/activities/workshops/cc-workshop/
o Position Papers: http://www.iab.org/activities/workshops/cc-workshop/papers/
o ポジションペーパー：http://www.iab.org/activities/workshops/cc-workshop/papers/
o Slides: http://www.iab.org/activities/workshops/cc-workshop/slides/
o スライド：http://www.iab.org/activities/workshops/cc-workshop/slides/
1. "One control to rule them all" by Michael Welzl
1. 「すべてを統括する1つのコントロール」Michael Welzl
2. "Congestion Avoidance Through Deterministic" by Pier Luca Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele Casagrande, Mirko Loghi, and Stefan Wieser
2. 「決定論による輻輳回避」（Pier Luca Montessoro、Riccardo Bernardini、Franco Blanchini、Daniele Casagrande、Mirko Loghi、Stefan Wieser著）
3. "Congestion Control in Real Time Media - Context" by Harald Alvestrand
3. 「リアルタイムメディアの輻輳制御-コンテキスト」Harald Alvestrand著
4. "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification" by ANM Zaheduzzaman Sarker and Ingemar Johansson
4. ANM Zaheduzzaman SarkerとIngemar Johanssonによる「ネットワークが提供する輻輳通知によるインタラクティブリアルタイムビデオ通信の改善」
5. "Multiparty Requirements in Congestion Control for Real-Time Interactive Media" by Magnus Westerlund
5. Magnus Westerlundによる「リアルタイムインタラクティブメディアの輻輳制御におけるマルチパーティ要件」
6. "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control" by Stefan Holmer
6. ステファンホルマー著「リアルタイムの輻輳制御へのさまざまなアプローチの公平性、遅延、シグナリングについて」
7. "RTP Congestion Control and RTCWEB Application Feedback" by Ted Hardie
7. Ted Hardieによる「RTP輻輳制御とRTCWEBアプリケーションフィードバック」
8. "Issues with Using Packet Delays and Inter-arrival Times for Inference of Internet Congestion" by Wesley M. Eddy
8. Wesley M. Eddyによる「インターネット輻輳の推論のためのパケット遅延と到着間時間の使用に関する問題」
9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku Kojo, and Markus Isomaki
9. Ilpo Jarvinen、Binoy Chemmagate、Laila Daniel、Aaron Yi Ding、Markku Kojo、Markus Isomakiによる「インタラクティブなリアルタイム通信に対するTCPの影響」
10. "Security Concerns For RTCWEB Congestion Control" by Dan York
10. ダンヨークによる「RTCWEB輻輳制御のセキュリティ上の懸念」
11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas Nandakumar, and Hein Phan
11. カレン・ジェニングス、スハス・ナンダクマール、およびハイン・ファンによる「害のあるベンダー」
12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong Pan
12. Xiaoqing ZhuとRong Panによる「ネットワーク支援動的適応」
13. "Congestion Control for Interactive Real-Time Applications" by Sanjeev Mehrotra and Jin Li
13. Sanjeev MehrotraおよびJin Liによる「インタラクティブリアルタイムアプリケーションの輻輳制御」
14. "There is No Magic Transport Wand" by John Leslie
14. ジョン・レスリーによる「魔法の輸送杖はありません」
15. "Towards Adaptive Congestion Management for Interactive Real-Time Communications" by Dirk Kutscher and Miriam Kuehlewind
15. Dirk KutscherおよびMiriam Kuehlewindによる「インタラクティブなリアルタイム通信のための適応型輻輳管理に向けて」
16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou and Emile Stephan
16. 「輻輳前のスペクトルの使用を拡大しますか？」ザビエル・マルジュ、エミール・ステファン
17. "Congestion control for users who don't have first-class internet access" by Maire Reavy
17. 「一流のインターネットアクセスを持たないユーザーのための輻輳制御」Maire Reavy著
18. "Realtime Congestion Challenges" by Randell Jesup
18. ランデルジェサップによる「リアルタイムの輻輳の課題」
19. "Congestion Control for Interactive Media: Control Loops & APIs" by Varun Singh, Joerg Ott, and Colin Perkins
19. 「インタラクティブメディアの輻輳制御：制御ループとAPI」、Varun Singh、Joerg Ott、Colin Perkins
20. "Some Notes on Threat Modelling Congestion Management" by Eric Rescorla
20. Eric Rescorlaによる「脅威モデリングの輻輳管理に関する注意事項」
21. "Timely Detection of Lost Packets" by Ali C. Begen
21. Ali C. Begenによる「失われたパケットのタイムリーな検出」
22. "Congestion Control Considerations for Data Channels" by Michael Tuexen
22. 「データチャネルの輻輳制御に関する考慮事項」Michael Tuexen著
23. "Position paper on CC for Interactive RT" by Matt Mathis
23. Matt Mathisによる「インタラクティブRTのCCに関するポジションペーパー」
24. "Overall Considerations for Congestion Control" by Mo Zanaty, Bill VerSteeg, Bent Christensen, David Benham, and Allyn Romanow
24. Mo Zanaty、Bill VerSteeg、Bent Christensen、David Benham、Allyn Romanowによる「輻輳制御に関する全体的な考慮事項」
25. "Fairness Considerations for Congestion Control" by Mo Zanaty
25. Mo Zanatyによる「輻輳制御の公平性に関する考慮事項」
26. "Media is not Data: The Meaning of Fairness for Competing Multimedia Flows" by Timothy B. Terriberry
26. 「メディアはデータではない：競合するマルチメディアフローの公平性の意味」ティモシーB.テリベリー
27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan 28. "Congestion Control for Interactive Real-Time Flows on Today's Internet" by Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan
27. Murari Sridharanによる「リアルタイムの輻輳制御に関する考察」28. Keith Winstein、Anirudh Sivaraman、Hari Balakrishnanによる「今日のインターネット上のインタラクティブなリアルタイムフローのための輻輳制御」
29. "Congestion Control Principles for CoAP" by Carsten Bormann and Klaus Hartke
29. Carsten BormannとKlaus Hartkeによる「CoAPの輻輳制御原則」
30. "Erasure Coding and Congestion Control for Interactive Real-Time Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel Lochin, Jerome Lacan, and Vincent Roca
30. 「インタラクティブリアルタイムコミュニケーションのための消失符号化と輻輳制御」（Pierre-Ugo Tournoux、Tuan Tran Thai、Emmanuel Lochin、Jerome Lacan、Vincent Roca著）
31. "Video Conferencing Specific Considerations for RTP Congestion Control" by Stephen Botzko and Mary Barnes
31. 「RTP輻輳制御に関するビデオ会議固有の考慮事項」Stephen BotzkoおよびMary Barnes著
32. "The Internet is Broken, and How to Fix It" by Jim Gettys
32. 「インターネットが壊れており、それを修正する方法」Jim Gettys著
33. "Deployment Considerations for Congestion Control in Real-Time Interactive Media Systems" by Jari Arkko
33. Jari Arkkoによる「リアルタイムインタラクティブメディアシステムにおける輻輳制御の展開に関する考慮事項」
We would like to thank the following workshop participants for attending the workshop:
ワークショップにご参加いただいた以下のワークショップ参加者に感謝いたします。
o Mat Ford
o Bernard Aboba
o Alissa Cooper
o Mary Barnes
o Lars Eggert
o Harald Alvestrand
o Gonzalo Camarillo
o Robert Sparks
o Cullen Jennings
o Dirk Kutscher
o Carsten Bormann
o Michael Welzl
o Magnus Westerlund
o Colin Perkins
o Murari Sridharan
o Klaus Hartke
o Pier Luca Montessoro
o Xavier Marjou
o Vincent Roca
o Wes Eddy
o Ali C. Begen
o Mo Zanaty
o Jin Li
o Dave Thaler
o Bob Briscoe
o Barry Leiba
o Jari Arkko
o Stewart Bryant
o Martin Stiemerling
o Russ Housley
o Marc Blanchet
o Zaheduzzaman Sarker
o Xiaoqing Zhu
o Randell Jesup
o Eric Rescorla
o Suhas Nandakumar
o Hannes Tschofenig
o Bill VerSteeg
o Sean Turner
o Keith Winstein
o Jon Peterson
o Maire Reavy
o Michael Tuexen
o Stefan Holmer
o Joerg Ott
o Timothy Terriberry
o Benoit Claise
o Ted Hardie
o Stephen Botzko
o Matt Mathis
o David Benham
o Jim Gettys
o Spencer Dawkins
o Sanjeev Mehrotra
o Adrian Farrel
o Greg White
o Markku Kojo
We also had remote participants, namely:
また、リモートの参加者もいました。
o Emmanuel Lochin o Mark Handley o Anirudh Sivaraman o John Leslie o Varun Singh
o エマニュエル・ロチン、マーク・ハンドラリー、アニルーズ・シバーマン、ジョン・レスリー、ヴァルン・シン
Authors' Addresses
著者のアドレス
Hannes Tschofenig Hall, Tirol 6060 Austria
Hannes Tschofenig Hall、チロル6060オーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Lars Eggert Sonnenallee 1 Kirchheim 85551 Germany
Lars Eggert Sonnenallee 1キルヒハイムドイツ
Phone: +49 151 12055791
EMail: lars@netapp.com
URI: http://eggert.org/
Zaheduzzaman Sarker Lulea SE-971 28 Sweden
Zaheduzzaman Sarker Lulea SE-971 28スウェーデン
Phone: +46 10 717 37 43
EMail: zaheduzzaman.sarker@ericsson.com