[要約] RFC 3738は、Wave and Equation Based Rate Control (WEBRC) Building Blockに関する要約と目的を提供します。WEBRCは、ネットワークのトラフィック制御において、波と方程式を利用する新しいアプローチです。
Network Working Group M. Luby
Request for Comments: 3738 Digital Fountain
Category: Experimental V. Goyal
M.I.T.
April 2004
Wave and Equation Based Rate Control (WEBRC) Building Block
波と方程式ベースのレート制御（WEBRC）ビルディングブロック
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.
このドキュメントは、波と方程式ベースのレート制御（WEBRC）を指定します。これは、データ提供にレートと輻輳制御を提供します。WeBRCは、IPマルチキャストを使用してプロトコルをサポートするように特別に設計されています。これは、レシーバーへの複数回の渋滞制御された配達を提供します。つまり、同じセッションに結合された異なるレシーバーは、送信者への個々の接続の帯域幅とこれらの接続に沿った競合するトラフィックに応じて、異なるレートでパケットを受信している場合があります。WEBRCは、受信者から送信者へのフィードバックを必要としません。つまり、それは完全に受信機駆動型の混雑制御プロトコルです。したがって、単一の送信者からのセッションに接続された潜在的に大量のレシーバーにスケーリングするように設計されています。さらに、個々のレシーバーは、送信者とその受信機の間の利用可能な帯域幅に適応するため、単一の送信者を使用して、非常に不均一なネットワークアーキテクチャであっても、そのレシーバーの可能な限り速いレートで各レシーバーにデータを配信する可能性があります。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Sender Operation . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Sender inputs and initialization. . . . . . . . . 9
3.1.2. Sending packets to the session. . . . . . . . . . 10
3.2. Receiver Operation . . . . . . . . . . . . . . . . . . . 12
3.2.1. Receiver inputs and initialization. . . . . . . . 12
3.2.2. Receiver measurements and calculations. . . . . . 13
3.2.2.1. Average loss probability . . . . . . . . 13
3.2.2.2. Average round-trip time. . . . . . . . . 16
3.2.2.3. Rate Equation. . . . . . . . . . . . . . 16
3.2.2.4. Epochs . . . . . . . . . . . . . . . . . 17
3.2.2.5. Average reception rate . . . . . . . . . 17
3.2.2.6. Slow start . . . . . . . . . . . . . . . 19
3.2.2.7. Target rate. . . . . . . . . . . . . . . 20
3.2.3. Receiver events . . . . . . . . . . . . . . . . . 20
3.2.3.1. Packet reception . . . . . . . . . . . . 20
3.2.3.2. First packet after join. . . . . . . . . 20
3.2.3.3. Time slot change . . . . . . . . . . . . 20
3.2.3.4. Loss event . . . . . . . . . . . . . . . 21
3.2.3.5. Epoch change . . . . . . . . . . . . . . 21
3.2.3.6. Join the next higher layer . . . . . . . 21
3.2.3.7. Join timeout . . . . . . . . . . . . . . 23
3.2.3.8. Exceptional timeouts . . . . . . . . . . 23
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 23
4.1. Environmental Requirements and Considerations. . . . . . 23
5. Packet Header Fields. . . . . . . . . . . . . . . . . . . . . 25
5.1. Short Format Congestion Control Information. . . . . . . 26
5.2. Long Format Congestion Control Information . . . . . . . 27
6. Requirements From Other Building Blocks . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 31
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
This document specifies Wave and Equation Based Rate Control (WEBRC). WEBRC is a congestion control building block that is designed to be massively scalable when used with the IP multicast network service. WEBRC is also suitable as the basis for unicast congestion control, but this is outside the scope of this document. WEBRC is designed to compete fairly with TCP and similar congestion-controlled sessions. WEBRC can be used as a congestion control protocol for any type of data delivery, including reliable content delivery and streaming delivery.
このドキュメントは、波と方程式ベースのレート制御（WEBRC）を指定します。WeBRCは、IPマルチキャストネットワークサービスで使用すると非常にスケーラブルになるように設計された輻輳制御ビルディングブロックです。WeBRCは、ユニキャスト輻輳制御の基礎としても適していますが、これはこのドキュメントの範囲外です。WeBRCは、TCPおよび同様の混雑制御セッションと公正に競争するように設計されています。WEBRCは、信頼できるコンテンツ配信やストリーミング配信など、あらゆる種類のデータ配信の輻輳制御プロトコルとして使用できます。
WEBRC is a receiver-driven congestion control protocol in the spirit of [5] and [18]. This means that all measurements and decisions to raise or lower the reception rate are made by each individual receiver, and these decisions are acted upon by sending join and leave messages for channels to the network. A receiver using WEBRC adjusts its reception rate without regard for other concerns such as reliability. This is different from TCP, where the congestion control protocol and the reliability protocol are intricately interwoven.
WeBRCは、[5]および[18]の精神における受信者駆動型混雑制御プロトコルです。これは、受信率を上げるまたは下げるためのすべての測定と決定が個々のレシーバーによって行われることを意味し、これらの決定は、ネットワークにチャネルのためにJoinおよびLeepメッセージを送信することによって行われます。WEBRCを使用するレシーバーは、信頼性などの他の懸念に関係なく受信率を調整します。これは、混雑制御プロトコルと信頼性プロトコルが複雑に織り込まれているTCPとは異なります。
WEBRC takes the same basic equation-based approach as TFRC [9]. In particular, each WEBRC receiver measures parameters that are plugged into a TCP-like equation to compute the receiver target reception rate and adjusts its reception rate up and down to closely approximate the target reception rate. The sender sends packets to multiple channels; one channel is called the base channel and the remaining channels are called wave channels. Each wave channel follows the same pattern of packet rate transmission spread out over equally-spaced intervals of time. The pattern of each wave is that it starts at a high rate and the rate decreases gradually and continually over a long period of time. (Picture an infinite sequence of waves.) The receiver increases its reception rate by joining the next wave channel earlier in the descent of the wave than it joined the previous wave channel, and the receiver decreases its reception rate by joining the next wave channel later in the descent of the wave than it joined the previous wave channel.
WEBRCは、TFRCと同じ基本方程式ベースのアプローチを採用しています[9]。特に、各WEBRCレシーバーは、TCPのような方程式に差し込まれたパラメーターを測定し、受信機のターゲット受信率を計算し、受信率を上下に調整して、ターゲット受信率に密接に近似します。送信者は、複数のチャネルにパケットを送信します。1つのチャネルはベースチャネルと呼ばれ、残りのチャネルはウェーブチャネルと呼ばれます。各ウェーブチャネルは、同じパターンのパケットレート伝送が等間隔の間隔で広がりました。各波のパターンは、それが高速で始まり、速度が長期間にわたって徐々に継続的に減少することです。（波の無限のシーケンスを描いてください。）レシーバーは、前の波チャネルよりも波の降下の早い段階で次の波チャネルに結合することで受信速度を上げ、レシーバーは後で次の波チャネルに結合することで受信率を低下させます波の降下では、以前の波チャネルに加わりました。
The wave channels are ordered at each point in time from a lowest layer to a highest layer. At each point in time, the lowest layer is the wave channel that among all active wave channels is nearest to the end of its active period; the highest layer is the wave channel that is furthest from the end of its active period. Because waves are dynamically becoming active and quiescent over time, the designation of which wave channel is at which layer changes dynamically over time. In addition to being joined to the base channel, at each point in time a receiver is joined to a consecutive set of layers starting at the lowest layer and proceeding towards the highest.
ウェーブチャネルは、最低層から最高層までの各時点で順序付けられます。各時点で、最も低い層は、すべてのアクティブ波チャネルの中でアクティブ期間の終わりに最も近い波チャネルです。最高層は、アクティブ期間の終わりから最も遠い波チャネルです。波は動的にアクティブになり、時間とともに静止しているため、どの波チャネルが時間の経過とともに動的に変化するかを指定します。ベースチャネルに結合されることに加えて、各時点で、レシーバーが最低層から始まり、最高に向かって進む連続したレイヤーに結合されます。
WEBRC introduces a natural notion of a multicast round-trip time (MRTT). An MRTT is measured individually by each receiver and averaged as a substitute for conventional unicast round-trip time (RTT). Because the throughput of a TCP session depends strongly on RTT, having some measure of RTT is essential in making the WEBRC equation-based rate control protocol "TCP-friendly". The use of the MRTT also helps to coordinate and equalize the reception rates of proximate receivers joined to a session behind a bottleneck link. This implies that packets for the session that flow through the bottleneck link are on average sent to almost all downstream receivers, and thus the efficiencies of multicast are realized. Furthermore, WEBRC is designed to be massively scalable in the sense that the sender is insensitive to the number of receivers joined to a multicast session.
Webrcは、マルチキャストの往復時間（MRTT）の自然な概念を紹介します。MRTTは、各受信機によって個別に測定され、従来のユニキャスト往復時間（RTT）の代替として平均化されます。TCPセッションのスループットはRTTに強く依存するため、WEBRC方程式ベースのレート制御プロトコルを「TCPフレンドリー」にするために、ある程度のRTTを持つことが不可欠です。MRTTの使用は、Bottleneckリンクの背後にあるセッションに結合された、近似レシーバーの受信率を調整および均等化するのにも役立ちます。これは、ボトルネックリンクを流れるセッションのパケットが平均してほぼすべてのダウンストリームレシーバーに送信され、したがってマルチキャストの効率が実現されることを意味します。さらに、WeBRCは、送信者がマルチキャストセッションに参加するレシーバーの数に鈍感であるという意味で、非常にスケーラブルになるように設計されています。
WEBRC is designed for applications that use a fixed packet size and vary their packet reception rates in response to congestion. WEBRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its reception rate is generally within a factor of two of the reception rate of a TCP flow under the same conditions. However WEBRC has a much lower variation of throughput over time compared to TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth rate is of importance. The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that WEBRC responds more slowly than TCP to changes in available bandwidth.
WeBRCは、固定パケットサイズを使用し、混雑に応じてパケット受信率を変更するアプリケーション向けに設計されています。WEBRCは、TCPフローと帯域幅を競うときに合理的に公正になるように設計されています。この流れは、同じ条件下でTCPフローの受信率の2倍になる場合、フローが「合理的に公平」です。ただし、WEBRCはTCPと比較して時間の経過とともにスループットの変動がはるかに低いため、比較的スムーズなレートが重要なテレフォニーやストリーミングメディアなどのアプリケーションにより適しています。帯域幅と公正に競合しながらTCPよりもスムーズなスループットを持つことのペナルティは、WEBRCが利用可能な帯域幅の変化に対してTCPよりもゆっくり反応することです。
The receiver measures and performs the calculation of congestion control parameters (e.g., the average loss probability, the average MRTT) and makes decisions on how to increase or decrease its rate based on these parameters. The receiver-based approach is well suited to an application where the sender is handling many concurrent connections and therefore WEBRC is suitable as a building block for multicast congestion control.
受信者は、輻輳制御パラメーター（たとえば、平均損失確率、平均MRTT）の計算を測定および実行し、これらのパラメーターに基づいてレートを増加または減少させる方法を決定します。受信機ベースのアプローチは、送信者が多くの同時接続を処理しているアプリケーションに適しているため、WEBRCはマルチキャスト輻輳制御の構成要素として適しています。
The paper [16] and technical report [15] provide much of the rationale and intuition for the WEBRC design and describe some preliminary simulations.
論文[16]および技術報告[15]は、WEBRC設計の理論的根拠と直感の多くを提供し、いくつかの予備シミュレーションを説明します。
This document describes a building block as defined in RFC 3048 [4]. This document describes a congestion control building block that conforms to RFC 2357 [3]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [2]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
このドキュメントでは、RFC 3048 [4]で定義されているビルディングブロックについて説明しています。このドキュメントでは、RFC 2357に準拠する輻輳制御ビルディングブロックについて説明しています[3]。このドキュメントは、IETF RMT WGの製品であり、RFC 3269 [2]で提供される一般的なガイドラインに従います。キーワード「必須」、「「必須」、「必須」、「しなければ」、「そうしない」、
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
このドキュメントでは、「はるか」、「ははは」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈されます。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme. This document specifies an experimental congestion control scheme. While waiting for initial deployment and experience to show this scheme to be effective and scalable, the IETF publishes this scheme in the "Experimental" category.
このメモには、RFC 2357に従って信頼性の高いマルチキャストトランスポートプロトコルを完全に指定するために必要な定義の一部が含まれています。RFC2357によると、インターネットでの信頼できるマルチキャストプロトコルの使用には、適切な混雑制御スキームが必要です。このドキュメントは、実験的な混雑制御スキームを指定します。IETFは、このスキームが効果的かつスケーラブルであることを示すための初期展開と経験を待っている間、このスキームを「実験的」カテゴリに公開します。
It is the intent of the Reliable Multicast Transport (RMT) Working Group to re-submit the specification as an IETF Proposed Standard as soon as the scheme is deemed adequate.
信頼できるマルチキャストトランスポート（RMT）ワーキンググループが、スキームが適切であると判断されるとすぐに、IETF提案標準として仕様を再提出することが意図されています。
WEBRC provides congestion control for massively scalable protocols using the IP multicast network service. The congestion control that WEBRC provides is common to a variety of applications, including reliable content delivery and streaming applications.
WEBRCは、IPマルチキャストネットワークサービスを使用して、大規模なスケーラブルなプロトコルに輻輳制御を提供します。WeBRCが提供する混雑制御は、信頼できるコンテンツ配信やストリーミングアプリケーションなど、さまざまなアプリケーションに共通しています。
WEBRC is designed to provide congestion control for all packets that are sent to a session. A session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. The rationale for providing congestion control that uses multiple channels within the same session is that this allows the data on the channels to be layered, which in turn allows each receiver to control its reception rate by joining and leaving channels during its participation in the session. There are advantages to layered data for streaming, where the most important data can be sent to the lower layers and incrementally valuable data to the higher layers. For reliable content delivery, as described in [13], an application can send in packets encoded data generated from an object in such a way that the arrival of enough packets by a receiver is sufficient to reliably reconstruct the original object. A primary advantage of WEBRC is that each receiver controls it reception rate independent of other receivers. Thus, for example, a receiver with a slow connection to the sender does not slow down the receivers with faster connections.
WeBRCは、セッションに送信されるすべてのパケットに渋滞制御を提供するように設計されています。セッションは、レシーバーにとって興味深い1つ以上のオブジェクトの送信に関連するパケットを運ぶために、しばらく使用される単一の送信者を発信する複数のチャネルで構成されています。単一の送信者からのセッションを定義する背後にあるロジックは、これが混雑制御を介してパケットトラフィックを調節するための適切な粒度であるということです。同じセッション内で複数のチャネルを使用する混雑制御を提供するための理論的根拠は、これによりチャネル上のデータを階層化できることです。これにより、各受信者はセッションへの参加中にチャネルに参加および離れることで受信率を制御できます。ストリーミングのための階層化されたデータには利点があり、最も重要なデータを下層層に送信し、高レイヤーに漸進的に価値のあるデータを送信できます。[13]で説明されているように、信頼できるコンテンツ配信の場合、アプリケーションは、レシーバーによる十分なパケットの到着が元のオブジェクトを確実に再構築するのに十分な方法でオブジェクトから生成されたエンコードされたデータを送信できます。WEBRCの主な利点は、各レシーバーが他のレシーバーとは無関係にIT受信率を制御することです。したがって、たとえば、送信者への接続が遅いレシーバーでは、接続が速いため、受信機が遅くなることはありません。
There are coding techniques that provide massively scalable reliability and asynchronous delivery which are compatible with WEBRC, e.g., as described in [11]. When combined the result is a massively scalable, reliable, asynchronous content delivery protocol that is network friendly. WEBRC also provides congestion control that is suitable for streaming applications.
[11]で説明されているように、WEBRCと互換性のある非常にスケーラブルな信頼性と非同期送達を提供するコーディング手法があります。結合すると、結果は、ネットワークに優しい非常にスケーラブルで信頼性の高い非同期コンテンツ配信プロトコルです。WeBRCは、アプリケーションのストリーミングに適した混雑制御も提供します。
WEBRC avoids using techniques that are not massively scalable. For example, WEBRC does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use WEBRC and that send information from receivers to senders.
Webrcは、非常にスケーラブルではない手法の使用を回避します。たとえば、WeBRCは受信者から送信者に情報を送信するためのメカニズムを提供しませんが、これはWEBRCを使用し、レシーバーから送信者に情報を送信するプロトコルを除外していません。
WEBRC provides congestion control that can be tuned for different applications that may have differing application requirements. For example, a content delivery protocol may aggressively strive to use all available bandwidth between receivers and the sender, and thus to maintain fairness it must drastically reduce its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and thus it may not reduce its rate as fast when there is competing traffic.
WEBRCは、アプリケーション要件が異なる可能性のあるさまざまなアプリケーションに合わせて調整できる混雑制御を提供します。たとえば、コンテンツ配信プロトコルは、受信機と送信者の間で利用可能なすべての帯域幅を使用するよう積極的に努力する可能性があり、したがって、公平性を維持するには、競合するトラフィックがある場合、劇的に速くする必要があります。一方、ストリーミング配信プロトコルは、利用可能なすべての帯域幅を使用しようとするのではなく、一定の速度を維持するよう努めている可能性があるため、競合するトラフィックがある場合、その速度を速く低下させることはありません。
WEBRC does not provide any support beyond congestion control, and thus WEBRC is to be combined with other building blocks to provide a complete protocol instantiation. For example, WEBRC does not provide any means that can be used to identify which session each received packet belongs to. As another example, WEBRC does not provide support for identifying which object each packet is carrying information about.
WeBRCは混雑制御を超えたサポートを提供していないため、WeBRCは他のビルディングブロックと組み合わせて、完全なプロトコルインスタンス化を提供します。たとえば、WeBRCは、それぞれ受信したパケットが属するセッションを特定するために使用できる手段を提供しません。別の例として、WeBRCは、各パケットが情報を伝達しているオブジェクトを識別するためのサポートを提供しません。
A WEBRC session comprises a logically related set of channels originating from a single sender that are used for some period of time to carry data packets with a header carrying WEBRC Congestion Control Information. When packets are received, they are first checked to see that they belong to the appropriate session before WEBRC is applied. A session label defined by a protocol instantiation may be carried in each packet to identify to which session the packet belongs. For example, if LCT [12] is being used with the session, then the sender IP address together with the Transport Session Identifier supported by LCT would be used to determine which session a received packet belongs to. The particular details of how this filtering is performed is outside the scope of this document. In the remainder of this document, references to channels are always within the scope of a single session.
WEBRCセッションでは、WEBRCの混雑制御情報を運ぶヘッダーを備えたデータパケットを運ぶために、ある期間使用される単一の送信者に由来する、論理的に関連するチャネルセットで構成されています。パケットが受信されると、WEBRCが適用される前に適切なセッションに属していることを最初に確認します。プロトコルインスタンス化によって定義されたセッションラベルは、各パケットに携帯して、パケットがどのセッションに属しているかを識別できます。たとえば、LCT [12]がセッションで使用されている場合、LCTがサポートするトランスポートセッション識別子と一緒に送信者IPアドレスを使用して、受信したパケットが属するセッションを決定します。このフィルタリングの実行方法の特定の詳細は、このドキュメントの範囲外です。このドキュメントの残りの部分では、チャネルへの参照は常に単一のセッションの範囲内にあります。
A channel can be uniquely identified at the network layer by a (sender IP address, multicast group address) pair, and this is the address to which the receiver sends messages to join and leave the channel. The channels used by a WEBRC session are mapped uniquely to consecutive channel numbers. In each packet sent to a channel, the channel number that corresponds to the channel is carried in the WEBRC Congestion Control Information. A WEBRC receiver uses the channel number to determine which channel within a session a packet is received from.
チャネルは、（送信者IPアドレス、マルチキャストグループアドレス）ペアでネットワークレイヤーで一意に識別できます。これは、受信者がメッセージを送信してチャンネルを離れるアドレスです。WEBRCセッションで使用されるチャネルは、連続したチャネル番号と一意にマッピングされます。チャネルに送信された各パケットで、チャネルに対応するチャネル番号は、WeBRC輻輳制御情報に掲載されます。WEBRCレシーバーは、チャネル番号を使用して、パケットが受信されるセッション内のチャネルを決定します。
At the sender, time is partitioned into time slots, each of duration TSD seconds. There is a fixed number T of time slot indices associated with a session. As time progresses, the current time slot index increases by one modulo T each TSD seconds. The current time slot index CTSI is carried in the WEBRC Congestion Control Information. This allows receivers to perform very coarse-grained synchronization within a session.
送信者では、時間が時間スロットに分割され、各期間のTSD秒が分割されます。セッションに関連付けられたタイムスロットインデックスの固定数はあります。時間が進むにつれて、現在の時間スロットインデックスは、各TSD秒を1測定します。現在の時刻スロットインデックスCTSIは、WEBRCの輻輳制御情報に含まれています。これにより、受信機はセッション内で非常に粗粒の同期を実行できます。
WEBRC congestion control is achieved by having the sender send packets associated with a given session to several different channels. Individual receivers dynamically join and leave these channels according to the network congestion they experience. These congestion control adjustments are performed at each receiver independently of all other receivers, without any impact on the sender. A packet sequence number is carried in the WEBRC Congestion Control Information. The packet sequence numbers are consecutively numbered per channel and are used by receivers to measure packet loss.
WEBRCの混雑制御は、特定のセッションに関連付けられたいくつかの異なるチャネルに送信者にパケットを送信させることで実現されます。個々のレシーバーは、彼らが経験するネットワークの輻輳に従って、これらのチャネルを動的に結合して残します。これらの混雑制御調整は、送信者に影響を与えることなく、他のすべての受信機とは独立して各レシーバーで実行されます。WEBRCの輻輳制御情報には、パケットシーケンス番号が掲載されています。パケットシーケンス番号は、チャネルごとに連続して番号が付けられており、受信機がパケットの損失を測定するために使用されます。
The channels associated with a session consist of one base channel and T wave channels. The packet rate for each channel varies over time. For the base channel, packets are sent to the channel at a low rate BCR_P at the beginning of a time slot and this rate gradually decreases to P*BCR_P at the end of the time slot, where P < 1 is a constant defined later. This pattern for the base channel repeats over each time slot. For each wave channel i, packets are sent to channel i at a rate that first increases very quickly to a high rate and then decreases over time by a fixed fraction P per time slot until a rate of BCR_P is reached at the end of time slot i. Then, for a period of time called the quiescent period, no packets are sent to wave channel i, and thereafter the whole cycle repeats itself, where the duration of the cycle is T*TSD seconds. Thus, the wave channels are going through the same cyclic pattern of packet rate transmission spaced out evenly by TSD seconds.
セッションに関連付けられているチャネルは、1つのベースチャネルとT Waveチャネルで構成されています。各チャネルのパケットレートは時間とともに異なります。ベースチャネルの場合、パケットはタイムスロットの開始時に低レートBCR_Pでチャネルに送信され、このレートはタイムスロットの終わりにP*BCR_Pに徐々に減少します。P<1は後で定義されます。ベースチャネルのこのパターンは、各時間スロットで繰り返されます。各ウェーブチャネルIについて、パケットはチャネルIに送信され、最初に高速まで非常に急速に増加し、その後、時間スロットの速度に到達するまで、時間スロットあたり固定分数Pによって時間とともに減少します。私。その後、静止期間と呼ばれる期間、パケットはウェーブチャネルIに送信され、その後、サイクル全体が繰り返され、サイクルの期間はt*tsd秒です。したがって、ウェーブチャネルは、TSD秒単位で均等に間隔を置いた同じ周期的なパケットレート伝送の循環パターンを通過しています。
Before joining a session, the receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters needed by a receiver to participate in the session and perform WEBRC congestion control. The session description is determined by the sender and is typically communicated to the receivers out of band. How receivers obtain the session description is outside the scope of this document.
セッションに参加する前に、受信機はセッションを開始するために十分なセッションの説明を取得する必要があります。これには、セッションに参加してWEBRC輻輳制御を実行するためにレシーバーが必要とする関連セッションパラメーターを含める必要があります。セッションの説明は送信者によって決定され、通常、バンドの外のレシーバーに伝えられます。受信者がセッションの説明を取得する方法は、このドキュメントの範囲外です。
When a receiver initiates a session, it first joins the base channel. The packets in the base channel help the receiver orient itself in terms of what the current time slot index is, which in turn allows the receiver to know the relative rates on the wave channels. The receiver remains joined to the base channel for the duration of its participation in the session.
受信者がセッションを開始すると、最初にベースチャネルに参加します。ベースチャネルのパケットは、現在の時間スロットインデックスの観点からレシーバーの方向付けを支援します。これにより、レシーバーはウェーブチャネルの相対レートを知ることができます。受信者は、セッションへの参加期間中、ベースチャネルに結合されたままです。
At each point in time the active (non-quiescent) wave channels are ordered into layers, where the lowest layer is the active wave channel whose wave is nearest to completion and the highest layer is the active wave channel whose wave is furthest from completion. (This is almost the same as saying that the lowest layer has the lowest rate and the highest layer has the highest rate. The possible deviation from this is due to the optional non-exponential beginnings of the waves as described in [8].) Each time a wave channel becomes active, it is the highest layer. At the end of each time slot the lowest-layer wave channel becomes quiescent, and thus all active wave channels move down a layer at this point in time. At each point in time a receiver is joined to the base channel and a consecutive set of layers starting with the lowest. Each time a receiver joins a wave channel it joins the lowest layer not yet joined. A receiver always leaves the lowest layer when it becomes quiescent.
それぞれの時点で、アクティブな（非穏やかな）波チャネルがレイヤーに順序付けられます。ここで、最下層は波が完了に最も近いアクティブ波チャネルであり、最高層は波が完了から最も遠いアクティブ波チャネルです。（これは、最低層の速度が最も低く、最高層の速度が最も高いと言っているのとほぼ同じです。これからの偏差の可能性は、[8]に記載されている波のオプションの非指数の始まりによるものです。）波チャネルがアクティブになるたびに、それは最高の層です。各タイムスロットの終わりに、最低層波チャネルが静止し、この時点ですべてのアクティブ波チャネルがレイヤーを下に移動します。各時点で、レシーバーがベースチャネルと連続したレイヤーのセットに最低のレイヤーに結合されます。レシーバーがウェーブチャネルに参加するたびに、まだ結合していない最下層に結合します。レシーバーは、静止状態になると常に最低層を残します。
After joining a session the receiver adjusts its rate upwards by joining wave channels in sequence, starting with the lowest layer and moving towards the highest. The rates on the active wave channels are decreasing with time, so the receiver adjusts its rate downwards simply by refraining from joining additional wave channels. Since the layer ordering among the channels changes dynamically over time depending on the current time slot index, it is important that the receiver continually monitor the current time slot index contained in received packets. The reception rate at the receiver is determined by how early each wave channel is joined by the receiver: the earlier the receiver joins a channel with respect to when its wave started, the higher the reception rate.
セッションに参加した後、受信機は、最低層から始まり、最高に向かって移動することにより、波チャネルを順番に結合することにより、レートを上方に調整します。アクティブウェーブチャネルのレートは時間とともに減少しているため、レシーバーは、追加の波チャネルの参加を控えることで、レートを下方に調整します。チャネル間のレイヤーの順序は、現在の時間スロットインデックスに応じて時間の経過とともに動的に変化するため、受信パケットに含まれる現在の時間スロットインデックスを受信者が継続的に監視することが重要です。受信者の受信率は、各波チャネルが受信機によってどのように結合されるかによって決定されます。レシーバーは、その波が始まったときにチャネルに結合するほど、受信率が高くなります。
Once the receiver is joined to a wave channel, the receiver remains joined to the wave channel until the channel goes quiescent, at which point the receiver MUST leave the channel.
レシーバーがウェーブチャネルに結合されると、レシーバーはチャネルが静止するまでウェーブチャネルに結合されたままになり、その時点でレシーバーはチャネルを離れる必要があります。
The way the receiver adjusts its reception rate is inspired by TFRC [9]. The receiver at all points in time maintains a target reception rate, and the receiver is allowed to join the next wave channel if after joining its anticipated reception rate from all the layers it is joined to would be at most its target reception rate. The target rate is continually updated based on a set of measured parameters. The primary parameters are an estimate LOSSP of the average loss probability and an estimate ARTT of the average multicast round-trip time.
受信者が受信率を調整する方法は、TFRCに触発されています[9]。すべての時点で受信機はターゲット受信率を維持し、レシーバーは、結合されたすべてのレイヤーから予想される受信率を結合した後、せいぜいターゲット受信率になる場合、次のウェーブチャネルに参加できます。目標レートは、測定されたパラメーターのセットに基づいて継続的に更新されます。主なパラメーターは、平均損失確率の推定損失と、平均マルチキャスト往復時間の推定ARTTです。
In the remainder of this document, log(X) denotes the natural logarithm of X, i.e., the logarithm base 2.71828459... of X.
このドキュメントの残りの部分では、log（x）はxの自然対数、つまりxの対数ベース2.71828459 ...を示します。
The sender operation is by design much simpler than the receiver operation.
送信者操作は、レシーバー操作よりもはるかにシンプルです。
The primary input to the sender for the session is SR_b. SR_b is an upper bound to the sender transmission rate in bits per second at any point in time (with some reasonable granularity) in aggregate to all channels. Naturally, this is then also the maximum rate in bits per second that any receiver could receive data from the session at any point in time. It is RECOMMENDED that the sender transmission rate in aggregate to all channels be made constant as described in [8]. It is also RECOMMENDED that the session description indicate whether the aggregate transmission rate is constant, unless there is no ambiguity.
セッションの送信者への主要な入力はSR_Bです。SR_Bは、すべてのチャネルに集約されている任意の時点で（何らかの合理的な粒度を備えた）、1秒あたりのビットの送信者伝送レートの上限です。当然のことながら、これはまた、レシーバーがいつでもセッションからデータを受け取ることができる1秒あたりのビットの最大レートです。[8]に記載されているように、すべてのチャネルへの凝集体の送信者伝送速度を一定にすることをお勧めします。また、セッションの説明では、あいまいさがない限り、凝集透過率が一定かどうかを示すこともお勧めします。
The secondary inputs to the sender are listed below. These inputs are secondary because their values will generally be fixed to default values that will not change, because they will be derived from SR_b, or because they are chosen based on non-WEBRC considerations.
送信者への二次入力を以下に示します。これらの入力は、一般に、SR_Bから派生するため、または非幅の考慮事項に基づいて選択されるため、変更されないデフォルト値に値に固定されるため、二次的です。
o LENP_B is the length of packets in bytes sent to the session. The value of LENP_B depends on the complete protocol, but in general this SHOULD be set to as high a value as possible without exceeding the MTU size for the network that would cause fragmentation.
o LENP_Bは、セッションに送信されたバイトのパケットの長さです。LENP_Bの値は完全なプロトコルに依存しますが、一般に、これは断片化を引き起こすネットワークのMTUサイズを超えることなく、できるだけ高い値に設定する必要があります。
o BCR_P is the transmission rate on the base channel at the beginning of a time slot in packets per second. The default value for BCR_P is 1.
o BCR_Pは、1秒あたりのパケットのタイムスロットの開始時のベースチャネルの伝送速度です。BCR_Pのデフォルト値は1です。
o TSD is the time slot duration measured in seconds. The RECOMMENDED value for TSD is 10.
o TSDは、数秒で測定された時間スロット期間です。TSDの推奨値は10です。
o QD is the minimum quiescent period duration measured in seconds. The RECOMMENDED value for QD is 300.
o QDは、秒単位で測定された最小静止期間です。QDの推奨値は300です。
o P is the multiplicative drop in every channel rate over each time slot. The default value for P is 0.75.
o Pは、各時間スロットのすべてのチャネルレートの乗法低下です。pのデフォルト値は0.75です。
o N is the duration in time slots for each wave. N is also the number of wave channels active at any time. (A wave channel is called active when it is not quiescent.) A sender may choose any value that allows it to produce waves that substantially follow the required exponential shape described in Section 3.1.2. A RECOMMENDED mechanism for relating N to SR_b, BCR_P and P is described in [8].
o nは、各波の時間スロットの持続時間です。nは、いつでもアクティブな波チャネルの数でもあります。（波路チャネルは静止していない場合にアクティブと呼ばれます。）送信者は、セクション3.1.2で説明されている必要な指数形状を実質的に追跡する波を生成できる値を選択できます。nをsr_b、bcr_p、およびpに関連付けるための推奨されるメカニズムは、[8]で説明されています。
From these inputs the following fixed sender parameters can be derived as follows.
これらの入力から、次の固定送信者パラメーターを次のように導き出すことができます。
o SR_P = SR_b/(8*LENP_B) is the sender transmission rate in packets per second.
o sr_p = sr_b/（8*lenp_b）は、1秒あたりのパケットの送信者伝送レートです。
o BCR_b = 8*LENP_B*BCR_P is the rate of the base channel at the beginning of a time slot in bits per second.
o bcr_b = 8*lenp_b*bcr_pは、1秒あたりのビットのタイムスロットの開始時のベースチャネルのレートです。
o L = ceil(BCR_P*TSD*(P-1)/log(P)) is the number of base channel packets sent in each time slot.
o l = ceil（bcr_p*tsd*（p-1）/log（p））は、各時刻スロットで送信されるベースチャネルパケットの数です。
o Q = ceil(QD/TSD) is the number of quiescent time slots per cycle for a wave channel.
o Q = CEIL（QD/TSD）は、ウェーブチャネルのサイクルあたりの静止時間スロットの数です。
o T = N + Q is the total number of time slots in a cycle. T is also the total number of wave channels.
o T = n Qは、サイクル内の時間スロットの総数です。Tは、波チャネルの総数でもあります。
o For the base channel CN = T and for the wave channels CN = 0,1,...,T-1. The sender has the description of the channels assigned to the session and the mapping between the channels and the CNs.
o ベースチャネルcn = tおよび波チャネルの場合cn = 0,1、...、t-1。送信者には、セッションに割り当てられたチャネルの説明と、チャネルとCNSの間のマッピングがあります。
o C = TSD*T is the total duration of a cycle in seconds.
o c = tsd*tは、サイクルの合計秒の期間です。
The sender keeps track of the current time slot index CTSI. The value of CTSI is incremented by 1 modulo T each TSD seconds. The value of CTSI is placed into each packet in the format described in Section 5. For each packet sent to the session, the sender also places the channel number CN of the channel into the packets in the format described in Section 5. Recall that CN = T for the base channel and CN = 0,1,...,T-1 for the wave channels.
送信者は、現在の時間スロットインデックスCTSIを追跡します。CTSIの値は、各TSD秒の1測定値によって増加します。CTSIの値は、セクション5で説明されている形式の各パケットに配置されます。セッションに送信された各パケットについて、送信者はセクション5で説明されている形式でチャネルのチャネル番号CNをパケットに配置します。=ベースチャネルの場合は、cn = 0,1、...、波チャネルのt-1。
For each packet sent to the session, the sender calculates a packet sequence number PSN and places it into the packet. The value of PSN is scoped by CN, and the value of PSN is consecutively increasing within each channel. Furthermore, for each wave channel, the last packet sent before the channel becomes quiescent must have the maximum possible PSN value. When the short format for Congestion Control Information is used (see Section 5.1), this implies that for any wave channel the last PSN value sent to the channel just before the channel becomes quiescent is 2^16-1 = 65,535. Similarly, when the long format for Congestion Control Information is used (see Section 5.2), the PSN for the final packet of any wave is 2^32-1 = 4,294,967,295. The PSN of the initial packet of a wave thus depends on TSD, P, BCR_P and SR_P. For the base channel, the first packet of each time slot has a PSN congruent to zero modulo L. Hence, instead of 2^16 - 1 or 2^32 - 1 being the highest PSN used (depending on the choice of short format or long format Congestion Control Information), the highest PSN is one less than the largest multiple of L that does not exceed 2^16 (short format) or 2^32 (long format). The format for the PSN within packets is described in Section 5.
セッションに送信された各パケットについて、送信者はパケットシーケンス番号PSNを計算し、パケットに配置します。PSNの値はCNによってスコープされ、PSNの値は各チャネル内で連続的に増加しています。さらに、各ウェーブチャネルについて、チャネルが静止する前に送信される最後のパケットには、可能な限り最大のPSN値が必要です。輻輳制御情報の短い形式が使用される場合（セクション5.1を参照）、これは、チャネルが静止する直前にチャネルに送信された最後のPSN値が2^16-1 = 65,535であることを意味します。同様に、輻輳制御情報の長い形式を使用する場合（セクション5.2を参照）、任意の波の最終パケットのPSNは2^32-1 = 4,294,967,295です。したがって、波の初期パケットのPSNは、TSD、P、BCR_P、およびSR_Pに依存します。ベースチャネルの場合、各タイムスロットの最初のパケットはゼロModulo Lと一致するPSNを持っています。したがって、2^16-1または2^32-1が使用される最高のPSNではなく（短い形式またはショートフォーマットの選択に応じて長い形式の混雑制御情報）、最高のPSNは、2^16（短い形式）または2^32（長い形式）を超えないLの最大倍数よりも1つ少ない。パケット内のPSNの形式については、セクション5で説明します。
The rate at which packets are sent to the base channel starts at BCR_P packets per second at the beginning of each time slot and decreases exponentially to P*BCR_P at the end of that time slot.
パケットがベースチャネルに送信されるレートは、各タイムスロットの開始時に毎秒BCR_Pパケットから始まり、その時間スロットの終わりにP*bcr_pに指数関数的に減少します。
The packet rate for the wave channels is more complicated. Each wave channel carries a sequence of waves separated by quiescent periods. On each wave channel each wave is active during N time slots followed by a quiescent period of Q time slots. The waves on wave channel i end at the ends of time slots with CTSI i. Therefore wave channel i is active during time slots i-N+1 modulo T, i-N+2 modulo T, ..., i and is quiescent for time slots i+1 modulo T, i+2 modulo T, ..., i+Q modulo T. Wave channel i first becomes active within time slot i-N+1 modulo T at a point in time that may depend on the value of SR_b.
ウェーブチャネルのパケットレートはより複雑です。各ウェーブチャネルには、静止期間で区切られた一連の波が搭載されています。各波チャネルでは、n時間スロット中に各波がアクティブになり、その後にq時間スロットの静止期間が続きます。Waves on WaveチャネルIは、CTSI iを使用して時間スロットの終わりで終了します。したがって、ウェーブチャネルIは時間スロットI-N 1モジュロT、I-N 2モジュロT、...、Iおよび時間スロットI 1モジュロT、I 2モジュロT、...、I Q Modulo T. Waveの場合は静止しています。チャネルIは、SR_Bの値に依存する可能性のある時点で、最初に時間スロットI-N 1モジュロTでアクティブになります。
Except for at most the first two time slots after a wave becomes active, the packet rate of the wave MUST decrease exponentially by a factor of P per TSD seconds, down to a rate of BCR_P at the end of the last active time slot. At the beginning of each wave, i.e., for at most the first two time slots when the wave becomes active, the rate MAY deviate from this exponential form so that the total sending rate in aggregate to all of the channels is constant. A RECOMMENDED design for the beginnings of waves to achieve this goal is described in [8].
波がアクティブになった後の最初の2回のスロットを除いて、波のパケットレートは、最後のアクティブタイムスロットの終わりにBCR_Pのレートまで、TSD秒あたりのPの係数で指数関数的に減少する必要があります。各波の先頭、つまり、波がアクティブになる最初の2回のスロットでは、この指数形式から逸脱する可能性があるため、すべてのチャネルへの総送信速度が一定になります。この目標を達成するための波の始まりに推奨される設計は、[8]で説明されています。
The bulk of the complexity in WEBRC is in the receiver operation. For ease of explanation, suppose for the moment that during the reception there is no packet loss and packets are arriving at exactly the rate at which they were sent. The sender transmission rate to the channels is designed so that the receiver reception rate behaves as follows.
WEBRCの複雑さの大部分は、受信機の操作にあります。説明を簡単にするために、レセプション中にパケットの損失がなく、パケットが送信された速度に正確に到着していると仮定します。チャネルへの送信者伝送レートは、受信者の受信率が次のように動作するように設計されています。
Upon entering a session, the receiver immediately joins the base channel. When the receiver wants to increase its rate, it joins consecutive layers starting with the lowest and moving towards the highest. (Recall that the designations of lowest to highest change as waves become active and quiescent.) When the receiver wants to maintain its current reception rate and it is already joined to the lowest NWC layers, if the receiver joins channel i-1+NWC modulo T sometime during time slot i then the receiver joins channel i+NWC modulo T TSD seconds later in time slot i+1. When the lowest layer becomes quiescent the receiver leaves the channel.
セッションに入ると、レシーバーはすぐにベースチャネルに参加します。レシーバーがレートを上げたい場合、最低から始まり、最高のレイヤーに向かって移動します。（波がアクティブで静止するにつれて、最低から最高の変化の指定は、レシーバーが現在の受信率を維持したい場合、レシーバーがチャンネルI-1 NWC Modulo Tに結合する場合、すでに最低NWCレイヤーに結合されている場合を思い出してください。時期スロットの間に、レシーバーはチャンネルI NWCモジュロT TSDに合わせて時間秒後にslot I 1.最低層が静止状態になると、レシーバーはチャネルを離れます。
Suppose the receiver wants to decrease its rate till it is joined to just the base channel. Assume that a receiver is joined to the lowest NWC < N-2 layers at the beginning of time slot i, i.e., wave channels i, i+1 modulo T,..., i+NWC-1 modulo T. Then, the aggregate packet reception rate of the receiver over the next NWC time slots will behave as follows if the receiver does not join any wave channels during this time. At the beginning of time slot i the receiver reception rate is BCR_P*(1 + (1/P) + (1/P)^2 + ... + (1/P)^NWC). Then the receiver reception rate decreases by a factor of P over the duration of each time slot, and at the end of each time slot the reception rate decreases by an additive amount of P*BCR_P. At the end of time slot i+NWC-1 mod T, the receiver reception rate is BCR_P*(1+P), and at the beginning of time slot i+NWC mod T the receiver is joined only to the base channel and its reception rate is BCR_P.
レシーバーがベースチャネルのみに結合されるまでレートを下げることを望んでいるとします。レシーバーがタイムスロットIの開始時に最低NWC <n-2層に結合されていると仮定します。次のNWCタイムスロットにおけるレシーバーの受信率は、この期間中にレシーバーが波路チャネルに参加しない場合、次のように動作します。タイムスロットIの初めに、受信者受信率はbcr_p*（1（1/p）（1/p）^2 ...（1/p）^nwc）です。次に、レシーバーの受信率は、各タイムスロットの期間中にpの係数を減らし、各タイムスロットの終わりに、受信率はp*bcr_pの添加物によって減少します。時間の終わりにスロットI nwc-1 mod tで、受信者受信率はbcr_p*（1 p）であり、時間の開始時には、レシーバーはベースチャネルにのみ結合され、その受信率はBCR_P。
Before joining a session the receiver MUST know the mapping between the CNs and the channels. Upon joining the session or shortly thereafter, it SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of these values may be computed or measured once the receiver has joined the session. For example, the receiver MAY obtain LENP_B and T from the first packet received from the base channel, and the receiver MAY measure BCR_P once it is joined to the base channel. The values of P, Q and TSD MAY be fixed to default values built into the receiver that do not change from session to session, and the value of N MAY be computed as T-Q. The receiver SHOULD know whether the sender is employing a technique to produce constant aggregate rate as described in [8].
セッションに参加する前に、受信者はCNSとチャネル間のマッピングを知っている必要があります。セッションに参加する、またはその後まもなく、LENP_B、BCR_P、TSD、P、N、L、Q、Tの値が必要です。これらの値の一部は、受信者がセッションに参加したら計算または測定できます。たとえば、レシーバーは、ベースチャネルから受信した最初のパケットからLENP_BとTを取得でき、レシーバーはBCR_Pをベースチャネルに結合すると測定できます。P、Q、TSDの値は、セッションからセッションに変更されないレシーバーに組み込まれたデフォルト値に固定され、nの値はt-qとして計算できます。受信者は、[8]で説明されているように、送信者が一定の凝集速度を生成する手法を採用しているかどうかを知る必要があります。
When a receiver first joins a session, it MUST first join just the base channel and start receiving packets to determine the current time slot index. If during the course of the session the receiver continually loses a high fraction of the packets from the base channel even when the receiver is only joined to the base channel, the receiver SHOULD leave the session.
受信機が最初にセッションに参加するとき、最初にベースチャネルのみに参加し、パケットを受信して現在の時間スロットインデックスを決定する必要があります。セッションの過程で、受信機がベースチャネルのみで結合されている場合でも、ベースチャネルからパケットの大部分を継続的に失う場合、受信機はセッションを離れる必要があります。
The receiver MAY also have other individually set parameters that may be used to determine its behavior. One such parameter is MRR_b:
受信機には、その動作を決定するために使用できる他の個別に設定されたパラメーターがある場合があります。そのようなパラメーターの1つはMRR_Bです：
o MRR_b is the maximum receiver reception rate in bits per second. This may be used to determine the maximum reception rate this receiver is willing to reach. Thus, the maximum reception rate that the receiver can possibly achieve in the session is the minimum of SR_b and MRR_b. A recommended value of MRR_b for a receiver is the bandwidth capacity of the last link to the receiver. MRR_P is the maximum receiver reception rate in packets per second, i.e., MRR_P = MRR_b/(8*LENP_B).
o MRR_Bは、1秒あたりのビットでの最大受信者受信率です。これは、このレシーバーが喜んで到達することをいとわない最大受信率を決定するために使用できます。したがって、受信者がセッションで達成できる最大受信率は、SR_BとMRR_Bの最小です。受信機のMRR_Bの推奨値は、レシーバーへの最後のリンクの帯域幅容量です。MRR_Pは、1秒あたりのパケットの最大レシーバー受信率、つまりMRR_P = MRR_B/（8*LENP_B）です。
As outlined in the introduction, the way a receiver adjusts its reception rate is inspired by TFRC [9]. The receiver at all points in time maintains a target reception rate, and the receiver is allowed to join the next wave channel if joining would increase its reception rate to at most its target reception rate. The target rate is continually updated based on a set of measured parameters.
はじめに概説されているように、受信者が受信率を調整する方法はTFRCに触発されています[9]。すべての時点でレシーバーはターゲット受信率を維持し、受信者が最大でターゲット受信率に合わせて受信率を上げると、レシーバーは次のウェーブチャネルに参加できます。目標レートは、測定されたパラメーターのセットに基づいて継続的に更新されます。
Two primary parameters are the estimate LOSSP of the average loss probability and the estimate ARTT of the average MRTT. Both LOSSP and ARTT are moving averages of measurements based on discrete events. For many of the other estimates calculated by WEBRC, using an exponentially weighted moving average (EWMA) with a fixed averaging fraction is sufficient. However, the calculations of LOSSP and ARTT require a more general and sophisticated filtering approach.
2つの主要なパラメーターは、平均損失確率の推定損失と平均MRTTの推定ARTTです。損失とARTTの両方は、離散イベントに基づいて測定の平均を動かしています。WEBRCによって計算された他の推定値の多くでは、固定平均分数で指数関数的に重み付けされた移動平均（EWMA）を使用して十分です。ただし、損失とARTTの計算には、より一般的で洗練されたフィルタリングアプローチが必要です。
The design of TFRC [9] reflects that, because the average packet loss probability can vary by orders of magnitude, any estimate of the average loss probability based on either a fixed number of packets or on a fixed period of time with a fixed averaging fraction will be poor. In TFRC the average is estimated from the numbers of packets between beginnings of loss events, and the number of loss events used is fixed.
TFRCの設計[9]は、平均パケット損失確率は桁違いに変化する可能性があるため、固定数のパケット数に基づく平均損失確率の推定値、または固定平均分数の固定期間の推定値を反映しています。貧しいでしょう。TFRCでは、損失イベントの開始と使用される損失イベントの数が固定されている間のパケットの数から平均が推定されます。
The estimate LOSSP of the average loss probability of the receiver is maintained in a manner somewhat similar to that described in TFRC [9]. The WEBRC receiver estimates the inverse of the average loss probability by applying two EWMA filters to the packet reception measurements, a time-based filter with smoothing constant 0 < Nu < 1 and a loss-based filter with smoothing constant 0 < Delta < 1. The recommended values for the smoothing constants are Nu = 0.3 and Delta = 0.3. The reason for the time-based filter is that the loss events in WEBRC are bursty; they typically occur just after a new wave has been joined. To smooth out this burstiness, the time-based filter is applied to the packet reception measurements at the end of each epoch to smooth out the bursty loss events over a few time slot durations. Intuitively, the time-based filter averages packet reception events such that the events are smoothed out over an interval of time proportional to TSD/Nu seconds. The loss-based filter, similar to what is suggested in TFRC, is applied to the output of the time-based filter to produce the estimate of the inverse of the average loss probability. Intuitively, the loss-based filter averages loss events such that each loss event is averaged in with weight Delta.
受信機の平均損失確率の推定損失は、TFRC [9]で説明されているものと多少類似した方法で維持されます。WEBRCレシーバーは、2つのEWMAフィルターをパケット受信測定に適用することにより、平均損失確率の逆を推定します。これは、スムージング定数0 <Nu <1とスムージング定数0 <Delta <1の損失ベースのフィルターを備えた時間ベースのフィルターです。平滑化定数の推奨値は、nu = 0.3およびdelta = 0.3です。時間ベースのフィルターの理由は、WEBRCの損失イベントが破裂しているためです。それらは通常、新しい波が結合された直後に発生します。この爆発を滑らかにするために、時間ベースのフィルターは、各エポックの最後のパケット受信測定に適用され、数回のスロット期間にわたってバースト損失イベントを滑らかにします。直感的に、時間ベースのフィルターは、TSD/NU秒に比例した時間間隔でイベントがスムーズになっているように、パケット受信イベントを平均します。TFRCで提案されているものと同様の損失ベースのフィルターは、時間ベースのフィルターの出力に適用され、平均損失確率の逆の推定値を生成します。直感的には、損失ベースのフィルターは、各損失イベントが重量デルタで平均化されるように、平均損失イベントを行います。
As described later, LOSSP is initialized at the end of slow start and occasionally reset due to other events. Let W and X be counts of packets, let Y be a count of loss events and let Z be the long-term estimate of the inverse of the average loss probability. Whenever the value of LOSSP is initialized or reset, the values of W, X, Y and Z are also initialized or reset.
後で説明したように、損失はスロースタートの終わりに初期化され、他のイベントのために時々リセットされます。wとxをパケットのカウントとし、yを損失イベントのカウントとし、zを平均損失確率の逆の長期推定とします。損失の値が初期化またはリセットされるたびに、w、x、y、zの値も初期化またはリセットされます。
Recall that TSD is the duration of a time slot. The epoch length EL is the duration of time between decisions to adjust the reception rate. Generally EL is much smaller than TSD, and the RECOMMENDED values are EL = 0.5 seconds and TSD = 10 seconds.
TSDはタイムスロットの期間であることを思い出してください。エポックの長さELは、受信率を調整する決定間の期間です。一般に、ELはTSDよりもはるかに小さく、推奨される値はEL = 0.5秒、TSD = 10秒です。
Define G = Nu*EL/TSD as the amount of time-based smoothing to perform at the end of each epoch. The update rules for W, X, Y, Z, and LOSSP are the following:
g = nu*el/tsdを、各エポックの終わりに実行する時間ベースのスムージング量として定義します。w、x、y、z、および損失の更新ルールは次のとおりです。
o At the end of each epoch, adjust X, Y and Z and compute LOSSP as follows:
o 各エポックの終わりに、次のようにx、y、zを調整し、損失を計算します。
Z = Z*(1-Delta)^(G*Y) + G*X/(G*Y+1)*(1-(1-Delta)^(G*Y+1))
X = X*(1-G)
x = x*（1-g）
Y = Y*(1-G)
y = y*（1-g）
Z1 = Z*(1-Delta)^Y + X/(Y+1)*(1-(1-Delta)^(Y+1))
Z2 = Z*(1-Delta)^(Y+1) + (X+W+1)/(Y+2)*(1-(1-Delta)^(Y+2))
LOSSP = 1/max{Z1,Z2,1}
o For each packet event (whether it is a received packet or a lost packet), W = W + 1
o 各パケットイベント（受信パケットであろうと紛失したパケットであろうと）、w = w 1
o At the beginning of each loss event, update W, X, and Y as follows:
o 各損失イベントの開始時に、次のようにw、x、yを更新します。
X = X + W
x = x w
W = 0
Y = Y + 1
y = y 1
The intuition behind these update rules is the following. If just loss-filtering were used to update Z, then Z would be decreased by a multiplicative amount 1 - Delta for each loss event and Z would be increased by an additive amount Delta for each packet. To smooth out loss events over more than one time slot, these adjustments are filtered into Z over time, at the rate of a fraction G at the end of each epoch. Thus, the variables X and Y are counts of the portions of the packets and loss events, respectively, that have not yet been filtered into the long-term memory Z. W is the count of packets since the last loss event started. This explains why W is increased by one for each packet and Y is increased by one for each loss event. At the end of each epoch a fraction G of both X and Y are filtered into Z according to the loss-filter rule described above, and then the same fraction G is removed from both X and Y to account for the fact that this portion has been filtered into Z. The LOSSP calculation combines the short-term history (X,Y) with the long-term history Z and also allows the arrivals since the last loss W to have some influence. The value of Z2 is what Z1 would become were the next packet to be lost.
これらの更新ルールの背後にある直感は次のとおりです。Zを更新するために損失フィルタリングを使用した場合、Zは各損失イベントの乗法量1-デルタ1によって減少し、各パケットの添加物のデルタによってZが増加します。一回以上のスロットで損失イベントをスムーズにするために、これらの調整は、各エポックの終わりに分数Gの速度で、時間の経過とともにZにフィルターされます。したがって、変数xとyは、それぞれ長期メモリZにフィルタリングされていないパケットの部分と損失イベントの部分のカウントです。Wは、最後の損失イベントが開始されてからパケットのカウントです。これは、パケットごとにWが1つずつ増加する理由を説明し、各損失イベントでYが1つ増加することを説明しています。各エポックの終わりに、xとyの両方の分数gは、上記の損失フィルタールールに従ってzにフィルタリングされ、次に、この部分がxとyの両方から削除され、この部分があるという事実を説明するためにxとyの両方から削除されます。Zにフィルタリングされました。損失の計算は、短期履歴（X、Y）と長期履歴Zを組み合わせており、最後の損失Wが何らかの影響を与えることもできます。Z2の値は、Z1になることが、次に失われるパケットでした。
To reset the loss calculation to a value LOSSP = a, the state variables are set as follows:
損失計算を値の損失p = aにリセットするには、状態変数が次のように設定されます。
W = 0
X = 0
Y = 0
Z = 1/a
The receiver maintains an average round-trip time, ARTT, as a measurement-based filter of MRTT measurements using a smoothing constant 0 < Alpha < 1. The RECOMMENDED value for Alpha is 0.25.
受信機は、平均往復時間、ARTTを維持し、Smoothing定数0 <Alpha <1を使用したMRTT測定の測定ベースのフィルターとして維持します。
Each time the receiver joins a channel (either the base channel upon entering a session or wave channels continually), it makes a measurement of the multicast round-trip time MRTT as follows. Let V be an auxiliary variable that is used that keep track of the average of the square of the MRTT measurements. When the receiver sends the join for the channel it records the current time JoinTime and sets a Boolean variable JOINING to true. When the first packet is received from the channel the receiver records the current time FirstTime and resets the value of JOINING to false. If it is the base channel that has been joined, ARTT is set to FirstTime-JoinTime and V is set to ARTT*ARTT. Otherwise, the value of MRTT is set to (FirstTime - JoinTime) - log(1/P)/2/(1-P)/BCR_P * P^NWC. (Note that this value can be negative.) Then, ARTT is updated as follows. Let Omega = Alpha*ARTT*ARTT/V, and at the Kth MRTT measurement let Rho = Omega/(1-(1-Omega)^(K+1)). (Note that as K grows Rho approaches Omega.) Then, V is updated to (1-Rho)*V+Rho*MRTT*MRTT and ARTT is updated to max{P*ARTT,(1-Rho)*ARTT+Rho*MRTT}.
レシーバーがチャネルに参加するたびに（セッションに入るときにベースチャネルまたは継続的にウェーブチャネルのいずれか）、次のようにマルチキャストの往復時間MRTTを測定します。Vを、MRTT測定の平均の平均を追跡する補助変数とします。レシーバーがチャンネルの結合を送信すると、現在の時刻のジョイントを記録し、ブール変数を設定します。最初のパケットがチャンネルから受信されると、レシーバーは現在の時刻を最初に記録し、接合の値をfalseにリセットします。結合されたベースチャネルの場合、Arttは初めてのJointimeに設定され、VはArtt*Arttに設定されます。それ以外の場合、MRTTの値は（初めて-Jointime） - log（1/p）/2/（1 -p）/bcr_p * p^nwcに設定されます。（この値は負になる可能性があることに注意してください。）次に、Arttは次のように更新されます。Omega = alpha*artt*artt/vとし、kth mrtt測定でrho = omega/（1-（1-omega）^（k 1））とします。（Kが成長するにつれてRhoがオメガに近づくにつれて、Vは（1-rho）*v rho*mrtt*mrttに更新され、arttはmax {p*artt、（1-rho）*artt rho*mrttに更新されます}。
Usually ARTT is updated to the second term in the max, and in this case ARTT is the EWMA of the previous value of ARTT and the new MRTT, with a weighting on the new MRTT that as K grows is proportional to the square of the previous ARTT divided by the previous average V of the square of the MRTT. Thus, if there is not much variance in the previous MRTTs relative to the square of their average then the new MRTT will be filtered into ARTT with a high weight, whereas if there is a lot of variance in the previous MRTTs relative to the square of their average then the new MRTT will be filtered into ARTT with a low weight. The intuitive rationale for this is that in general the number of measurements needed to compute a meaningful average for a random variable is proportional to its variance divided by the square of its average; see, e.g., [6]. By making the weight factor depend on previous measurements in this way, the appropriate weight to use to average the new MRTT into the ARTT self-adjusts automatically to the variability in the measurements.
通常、ARTTはMAXの2番目の用語に更新され、この場合、ARTTはARTTと新しいMRTTの以前の価値のEWMAです。ARTTは、MRTTの正方形の前の平均Vで割ったものです。したがって、以前のMRTTに平均の正方形と比較して多くの分散がない場合、新しいMRTTは高い重量でARTTにフィルタリングされますが、以前のMRTTには、の正方形と比較して多くの分散がある場合その後、新しいMRTTは、重量が少ないARTTにフィルタリングされます。これに対する直感的な根拠は、一般に、ランダム変数の意味のある平均を計算するために必要な測定数が、その分散を平均の平方で割ったものに比例するということです。たとえば、[6]を参照してください。この方法での以前の測定値に重み係数を依存することにより、新しいMRTTをARTTの自己調整に平均化するために使用する適切な重みが、測定の変動性に自動的に自動的に調整されます。
The receiver calculates the reception rate REQN based on the TCP equation as follows: REQN = 1/(ARTT*sqrt{LOSSP}(0.816 + 7.35*LOSSP*(1+32*LOSSP^2))). This equation comes from TFRC [9].
受信機は、次のようにTCP方程式に基づいて受信速度reqnを計算します：reqn = 1/（artt*sqrt {lossp}（0.816 7.35*lossp*（1 32*lossp^2）））。この方程式はTFRC [9]に由来します。
The receiver makes decisions on whether or not to join another wave channel at equally-spaced units of time called epochs. The duration of an epoch in seconds, EL, is set to be a small fraction of TSD, so that decisions to join a channel can be made at a much finer granularity than TSD. A standard setting is EL = TSD/20. Thus, with the recommended setting of TSD = 10, it is RECOMMENDED that EL = 0.5.
レシーバーは、エポックと呼ばれる同等の間隔の時間単位で別の波チャネルに参加するかどうかについて決定を下します。数秒でのエポックの期間、ELはTSDのわずかな割合になるように設定されているため、チャネルに参加する決定はTSDよりもはるかに細かい粒度で行うことができます。標準設定はEL = TSD/20です。したがって、TSD = 10の推奨設定では、EL = 0.5をお勧めします。
There are two averaged reception rates maintained by the receiver: TRR_P, the true reception rate, and ARR_P, the anticipated reception rate. These are used for different purposes and thus are calculated quite differently. Recommended values for the filtering weights Beta and Zeta are provided at the end of this subsection.
受信機が維持する平均受信率は、TRR_P、真の受信率、およびARR_P、予想される受信率です。これらはさまざまな目的に使用されるため、まったく異なる方法で計算されます。このサブセクションの最後に、フィルタリングウェイトベータとゼータの推奨値が提供されます。
In start-up mode, the true reception rate TRR_P is used to ensure that the receiver does not increase its reception rate too quickly above its current reception rate. In the transition from start-up mode to normal operation and in normal operation, TRR_P is used in setting the slow start rate. TRR_P is calculated based on the measurement of RR_P, where RR_P is the receiver reception rate in packets per second measured at the beginning of an epoch averaged over the epoch that just ended. TRR_P is initialized to BCR_P + k*log(P)/TSD when the first base channel packet of the session arrives, where k is the PSN of the packet reduced modulo L. TRR_P is updated to (1-Zeta)*TRR_P + Zeta*RR_P at the beginning of each epoch after RR_P is measured for the previous epoch.
起動モードでは、真の受信レートTRR_Pを使用して、受信率が現在の受信率を上回りすぎないようにします。起動モードから通常の動作への移行および通常の動作では、TRR_Pが遅い開始率の設定に使用されます。TRR_PはRR_Pの測定に基づいて計算されます。ここで、RR_Pは、終了したエポック上で平均化されたエポックの開始時に測定された秒あたりのパケットの受信者受信率です。TRR_PはBCR_P K*log（P）/TSDに初期化されます。セッションの最初のベースチャネルパケットが到着します。ここで、Kはパケット削減Modulo L. TRR_PのPSNです。RR_Pが前のエポックについて測定された後、各エポックの開始時に。
The anticipated reception rate ARR_P is the receiver's estimate of the total instantaneous rate of the currently joined channels. It is used to compare against the target rate to decide whether or not the receiver should increase its reception rate by joining the next higher unjoined layer. ARR_P is calculated based on a measurement IRR_P and on the number of joined wave channels NWC. The ideal reception rate IRR_P is the reception rate in packets per second including both received and lost packets; like RR_P, it is measured at the beginning of the epoch and averaged over the previous epoch. ARR_P, IRR_P and NWC are updated as follows:
予想される受信率ARR_Pは、現在結合されているチャネルの総瞬間レートの受信者の推定値です。これは、ターゲットレートと比較するために使用され、レシーバーが次のより高い未結合レイヤーに参加することにより、受信率を上げるべきかどうかを決定します。ARR_Pは、測定IRR_Pと結合されたWAVEチャネルNWCの数に基づいて計算されます。理想的な受信率IRR_Pは、受信パケットと紛失したパケットの両方を含む1秒あたりのパケットの受信率です。RR_Pと同様に、エポックの開始時に測定され、前のエポックで平均化されます。ARR_P、IRR_P、およびNWCは次のように更新されます。
o NWC is initialized to 0.
o NWCは0に初期化されます。
o When the first base channel packet arrives, ARR_P is set to BCR_P + k*log(P)/TSD, where k is the PSN of the packet reduced modulo L.
o ファーストベースチャネルパケットが到着すると、arr_pはbcr_p k*log（p）/tsdに設定されます。ここで、kはパケット削減modulo lのpsnです。
o At the beginning of each epoch, IRR_P is measured over the previous epoch and then ARR_P is updated to P^(EL/TSD)*(1-Beta)*ARR_P + Beta*IRR_P. Then if ARR_P exceeds ARR_P_max = ((1/P)^(NWC+1)-1)/((1/P)-1)*BCR_P, ARR_P is updated to ARR_P_max.
o 各エポックの開始時に、IRR_Pは前のエポックで測定され、ARR_Pはp^（el/tsd）*（1-beta）*arr_p beta*Irr_pに更新されます。次に、arr_pがarr_p_max =（（1/p）^（nwc 1）-1）/（（1/p）-1）*bcr_pを超える場合、arr_pはarr_p_maxに更新されます。
o When a join is made to the next higher unjoined layer, NWC is updated to NWC+1 and then ARR_P is multiplicatively increased by the factor ((1/P)^(NWC+1)-1)/((1/P)^NWC-1). (Joins happen at epoch boundaries; this adjustment is in addition to the adjustment above.)
o 結合が次の上位の非結合レイヤーに加わった場合、NWCはNWC 1に更新され、ARR_Pは係数（（1/P）^（NWC 1）-1）/（（1/P）^NWCによって増加します。-1）。（結合はエポックの境界で起こります。この調整は、上記の調整に追加されます。）
o Each time a next time slot index is detected, ARR_P is additively increased by (1-P)*BCR_P to account for the change in rate on the base channel. In addition, the bottom layer in the previous time slot has just gone quiescent and thus a message to leave this layer has been sent, ARR_P is additively decreased by BCR_P and NWC is decremented by 1. Thus, the combination of these effects on ARR_P is that it is additively decreased by P*BCR_P.
o 次回のスロットインデックスが検出されるたびに、ARR_Pは（1-P）*BCR_Pで追加増加して、ベースチャネルのレートの変化を説明します。さらに、前の時刻スロットの最下層は静止しているため、このレイヤーを残すメッセージが送信されました。ARR_PはBCR_Pによって追加され、NWCは1によって減少します。p*bcr_pによって追加されること。
Consider for the moment what happens if Beta = 0 and ARR_P is an accurate estimate of the total rate of the joined channels. The adjustments to ARR_P upon joining and leaving wave channels, with the passage of epochs, and with the detection of time slot changes will then cause ARR_P to remain an accurate estimate. In practice, Beta MUST be positive; allowing an influence of IRR_P prevents ARR_P from drifting away from being an accurate estimate of the total joined rate.
ベータ= 0とarr_pが結合チャネルの合計レートの正確な推定値である場合、今のところ何が起こるかを考えてください。エポックの通過と時間スロットの変更を行うと、波チャネルに参加および離れる際のARR_Pの調整により、ARR_Pが正確な推定値のままになります。実際には、ベータは肯定的でなければなりません。IRR_Pの影響を許すことで、ARR_Pが合計結合率の正確な推定値であることを防ぐことができなくなります。
The motivation for separate estimates TRR_P and ARR_P is as follows. ARR_P is needed for comparison with the TFRC-inspired target rate because there is no lag before it reflects the potential rate increase resulting from joining the next higher layer and because it measures the total possible impact on the network since it also includes lost packets. TRR_P is needed because it reflects the rate of data arriving at the receiver and this is used to ensure that there is not a large gap between the joined rate and the receiving rate.
個別の推定値TRR_PとARR_Pの動機は次のとおりです。ARR_Pは、TFRCにインスパイアされたターゲットレートとの比較に必要です。これは、次の高レイヤーを結合することから生じる潜在的なレートの増加を反映する前に遅れがないため、失われたパケットも含まれるためネットワークへの総影響を測定するためです。TRR_Pは、受信機に到着するデータのレートを反映しており、これは結合率と受信率の間に大きなギャップがないことを保証するために使用されるためです。
The recommended values for Beta and Zeta depend on whether the
receiver is in start-up mode (SSR_P = infinity). In start-up mode,
it is RECOMMENDED that Beta = (1 - P^(0.25))/2 and Zeta = sqrt(P)/(1
+ sqrt(P)). In normal operation, it is RECOMMENDED that Beta = 1 -
(P/(1+P))^(EL/TSD) and Zeta = 2*EL/(4+TSD).
WEBRC uses a slow start mechanism to quickly ramp up its rate at both the beginning of the session and in the middle of a session when the rate drops precipitously. To enact this, the receiver maintains the following parameters:
Webrcは、スロースタートメカニズムを使用して、セッションの開始時とレートが急激に低下したセッションの途中で、レートをすばやく上昇させます。これを制定するために、受信者は次のパラメーターを維持します。
o SSMINR_P is the minimum allowed slow start threshold rate in packets per second. The recommended value for SSMINR_P is BCR_P*(1+1/P+1/P^2).
o SSMINR_Pは、1秒あたりのパケットの最小許容スロースタートしきい値レートです。SSMINR_Pの推奨値はBCR_P*（1 1/p 1/p^2）です。
o SSR_P is the slow start threshold rate in packets per second. It is adjusted at the beginning of loss events as described in Section 3.2.3.4. SSR_P is initialized to infinity and is first set to a finite value when the receiver leaves the initial start-up period as described below.
o SSR_Pは、パケットのスロースタートしきい値レートです。セクション3.2.3.4で説明されているように、損失イベントの開始時に調整されます。SSR_PはInfinityに初期化され、レシーバーが以下に説明するように初期起動期間を離れるときに最初に有限値に設定されます。
At the beginning of a session, the receiver cannot compute a meaningful target rate from its measurements. Thus, it uses SSR_P = infinity until one of the following events causes an end to this start-up mode:
セッションの開始時に、受信者は測定から意味のあるターゲットレートを計算できません。したがって、次のイベントのいずれかがこの起動モードに終了するまで、SSR_P = Infinityを使用します。
o A packet loss is detected. In this case the value of SSR_P is updated to max{SSMINR_P, P*TRR_P} as with the beginning of any other loss event.
o パケット損失が検出されます。この場合、SSR_Pの値は、他の損失イベントの開始と同様に、max {ssminr_p、p*trr_p}に更新されます。
o A sharp increase in MRTT is detected. While SSR_P = infinity the receiver MUST compute, in the notation of Section 3.2.2.2, differences in successive measurements of (FirstTime-JoinTime) from successive waves and MUST set SSR_P to max{SSMINR_P, P*TRR_P} when a large increase in (FirstTime-JoinTime) is observed. It is RECOMMENDED that an increase in (FirstTime-JoinTime) be considered large if it exceeds (P^(NWC+1)-1)/(P*log(P)) / ARR_P.
o MRTTの急激な増加が検出されます。SSR_P = Infinityが受信機は、セクション3.2.2.2の表記において、連続した波からの（初めてのJointime）の連続した測定値の違いを計算する必要があり、SSR_PをMAX {SSMINR_P、P*TRR_P}に（大幅に増加したとき）に設定する必要があります。初めてのJointime）が観察されます。（初めてのジョイント）の増加は、（P^（nwc 1）-1） /（p*log（p）） / arr_pを超える場合、大きいと見なすことをお勧めします。
o The maximum reception rate is reached. When SSR_P = infinity, if (P^(-NWC-2)-1)/(P^(-NWC-1)-1)*ARR_P exceeds MRR_P or SR_P, the receiver MUST set SSR_P to max{SSMINR_P, TRR_P}.
o 最大受信率に達します。ssr_p = infinity、（p^（ - nwc-2）-1）/（p^（ - nwc-1）-1）*arr_pがmrr_pまたはsr_pを超える場合、受信者はssr_pをmax {ssminr_p、trr_p}に設定する必要があります。。
o TRR_P is not increasing consistent with the last join of a wave channel. While SSR_P = infinity, it is RECOMMENDED that the receiver wait at least one full epoch after the first packet of a wave is received before joining the next wave. If the TRR_P after that full epoch is greatly below ARR_P the receiver SHOULD NOT join and SHOULD then set SSR_P to max{SSMINR_P, TRR_P}. It is RECOMMENDED that TRR_P be considered greatly below ARR_P if TRR_P < c * ARR_P - 2/EL, where c = Zeta + (1-Zeta)*(P^(-EL/TSD))*(Zeta + (1-Zeta)*sqrt(P)*(P^(-EL/TSD)))/g with g = (P^(-NWC-1)-1)/(P^(- NWC)-1).
o TRR_Pは、Waveチャネルの最後の結合と一致して増加していません。SSR_P = Infinityは、次の波に結合する前に波の最初のパケットを受信した後、レシーバーが少なくとも1つのフルエポックを待つことをお勧めします。その後のTRR_Pが完全なエポックがARR_Pを大きく下回っている場合、受信機は結合してはならず、SSR_PをMAX {SSMINR_P、TRR_P}に設定する必要があります。trr_p <c*arr_p-2/elの場合、trr_pはarr_pを大きく下回ることをお勧めします。sqrt（p）*（p^（ - el/tsd））/g with g =（p^（ - nwc-1）-1）/（p^（ - nwc）-1）。
In any of these four cases, the variables associated with LOSSP are reset to make REQN, calculated as in Section 3.2.2.3 with the current value of ARTT, equal TRR_P.
これらの4つのケースのいずれかで、損失に関連付けられた変数は、reqnを作成するためにリセットされ、セクション3.2.2.3のようにARTTの現在の値、等しいtrr_pと計算されます。
In typical operation, SSR_P has a finite value and the target rate TRATE is computed as TRATE = min{max{SSR_P, REQN}, MRR_P}. When SSR_P = infinity, TRATE is computed as TRATE = min{4*TRR_P, MRR_P}.
典型的な操作では、SSR_Pの有限値があり、ターゲットレートトレートはtrate = min {max {ssr_p、reqn}、mrr_p}として計算されます。SSR_P = Infinityの場合、TRATEはTrate = min {4*TRR_P、MRR_P}として計算されます。
There are various receiver events, some of which are triggered by the passing of time on the receiver, and others by events such as packet reception, detection of packet loss, reception of a first packet from a channel, and exceptional time-outs.
さまざまなレシーバーイベントがありますが、その一部はレシーバーの時間の経過によって引き起こされ、その他はパケット受信、パケット損失の検出、チャネルからの最初のパケットの受信、例外的なタイムアウトなどのイベントによってトリガーされます。
Most packet reception events require the receiver to merely register the reception for later calculation of RR_P and IRR_P (see Section 3.2.2.5) and increment W for later calculation of LOSSP (see Section 3.2.2.1).
ほとんどのパケット受信イベントでは、レシーバーがRR_PとIRR_Pの後で計算するために受信を登録するだけで、損失を後で計算するためにはwを増分する必要があります（セクション3.2.2.1を参照）。
Additional actions, described in the following three subsections, are required if the packet is the first packet received in response to a join operation, the CTSI of the packet indicates a time slot change, or the CN and PSN of the packet indicate a packet loss.
次の3つのサブセクションで説明されている追加のアクションが必要ですが、パケットが参加操作に応じて受信した最初のパケットである場合、パケットのCTSIがタイムスロットの変更を示し、パケットのCNとPSNはパケット損失を示しています。。
When channel i is the most recently joined channel and the Boolean variable JOINING is true, the reception of a packet with PSN = i is a special event because it is the first packet received in response to the most recent join. MRTT is calculated and ARTT and V are updated as described in Section 3.2.2.2, and JOINING is set to false. The first received packet of the session furthermore necessitates initialization of ARR_P and TRR_P as described in Section 3.2.2.5.
チャネルIが最近参加したチャネルであり、ブール変数の結合が真実である場合、PSN = Iでのパケットの受信は、最新の結合に応じて受信した最初のパケットであるため、特別なイベントです。MRTTは計算され、ARTTとVはセクション3.2.2.2で説明されているように更新され、結合がfalseに設定されます。セクション3.2.2.5で説明されているように、最初に受信したセッションのパケットには、ARR_PとTRR_Pの初期化が必要です。
This is an event that is triggered by the reception of a packet with a CTSI value that is one larger modulo T than the previous CTSI value. When a packet with a new CTSI = i is received, a leave is sent for the lowest layer in the previous time slot, i.e., wave channel i-1 modulo T, NWC is updated to NWC-1, and ARR_P is updated to ARR_P - P*BCR_P as described in Section 3.2.2.5. If the channel for which the leave is sent is also the most recently joined wave channel and JOINING is true, then JOINING is set to false.
これは、以前のCTSI値よりも1つの大きなモジュロTであるCTSI値を持つパケットの受信によってトリガーされるイベントです。新しいCTSI = Iを含むパケットが受信されると、前のタイムスロットで最低層の休暇が送られます。-p*bcr_pセクション3.2.2.5で説明されています。休暇が送信されるチャネルが最近参加したWaveチャンネルであり、参加することが真実である場合、結合はFalseに設定されます。
It is possible due to packet reordering for some packets from the previous time slot to be received after packets from the current time slot. It is RECOMMENDED that measures be put into place to handle this situation appropriately, i.e., to not trigger a time slot change in this situation. One simple mechanism for this is as follows: Compute the difference i-j modulo T, where i is the CTSI of the received packet and j is the current CTSI of the receiver. A difference of zero is, of course, not a time slot change. In addition, a very large difference, for example a difference larger than T-Q/2, should also not trigger a time slot change.
現在のタイムスロットからパケットを受け取った後に受信する前の一部のパケットのパケットの並べ替えが原因である可能性があります。この状況を適切に処理するための措置を講じることをお勧めします。つまり、この状況でタイムスロットの変更をトリガーしないようにすることをお勧めします。これの1つの簡単なメカニズムは次のとおりです。差異I-JモジュロTを計算します。ここで、Iは受信パケットのCTSIであり、Jはレシーバーの現在のCTSIです。ゼロの差は、もちろん、タイムスロットの変更ではありません。さらに、非常に大きな違い、たとえばT-Q/2よりも大きい差も、タイムスロットの変更をトリガーする必要はありません。
Each time the receiver detects a lost packet (based on the sequence numbers in the packets scoped by the channel number), the receiver records the start of a new loss event and sets a Boolean variable LOSS_EVENT to true that will automatically reset to false after ARTT seconds. All subsequent packet loss for a period of ARTT seconds is considered as part of the same loss event. When a start of a loss event is detected, the value of SSR_P is updated to max{SSMINR_P, P*TRR_P}.
レシーバーが失われたパケットを検出するたびに（チャネル番号でスコープされたパケットのシーケンス番号に基づいて）、受信機は新しい損失イベントの開始を記録し、ARTTの後にfalseに自動的にリセットするブール変数のloss_eventをtrueに設定します秒。ARTT秒の期間のその後のすべてのパケット損失は、同じ損失イベントの一部と見なされます。損失イベントの開始が検出されると、SSR_Pの値がmax {ssminr_p、p*trr_p}に更新されます。
It is RECOMMENDED that the receiver account for simple misordering of packets without inferring a loss.
レシーバーは、損失を推測せずにパケットの単純な誤った順序をアカウントすることをお勧めします。
This is an event that is triggered by the passage of time at the receiver, which occurs each EL seconds. When this happens, TRR_P and ARR_P are computed as described in Section 3.2.2.5. Immediately after these updates, a decision is made about whether to join the next higher layer as described in Section 3.2.3.6.
これは、レシーバーでの時間の経過によってトリガーされるイベントであり、各EL秒が発生します。これが発生すると、TRR_PとARR_Pはセクション3.2.2.5で説明されているように計算されます。これらの更新の直後に、セクション3.2.3.6で説明されているように、次の高層層に参加するかどうかについて決定が下されます。
At the beginning of each epoch, after updating the values of ARR_P and TRR_P as described in Section 3.2.2.5, the receiver decides whether or not to join the next higher layer as follows:
各エポックの開始時に、セクション3.2.2.5で説明されているARR_PとTRR_Pの値を更新した後、受信者は次の高レイヤーを次のように結合するかどうかを決定します。
o If the first base channel packet has not yet arrived the receiver MUST not join.
o ファーストベースチャネルパケットがまだ到着していない場合、レシーバーは結合してはなりません。
o If there is a loss event in progress (LOSS_EVENT = true) the receiver MUST not join.
o 進行中の損失イベントがある場合（loss_event = true）、受信者は結合してはなりません。
o If a join of a channel is in progress (JOINING = true) the receiver MUST not join.
o チャネルの結合が進行中である場合（結合= true）、受信者は結合してはなりません。
o If NWC = N the receiver MUST not join.
o NWC = nの場合、受信機は結合してはなりません。
o If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has not passed since the first packet arrival on the most recently joined wave channel then the receiver MUST not join.
o セクション3.2.2.6、SSR_P = Infinityで説明されているオプションのルールをレシーバーが採用しており、最近参加したWaveチャネルへの最初のパケット到着以来、完全なエポックが通過していない場合、レシーバーは結合してはなりません。
o If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has passed since the first packet arrival on the most recently joined wave channel, then the receiver checks if TRR_P is greatly below ARR_P as described in Section 3.2.2.6. If TRR_P is greatly below ARR_P the receiver MUST not join.
o 受信者がセクション3.2.2.6、SSR_P = Infinityで説明されているオプションのルールを採用している場合、最近結合したWaveチャネルへの最初のパケット到着から完全なエポックが通過した場合、レシーバーは、記載されているようにTRR_PがARR_Pを大きく下回っているかどうかをチェックします。セクション3.2.2.6で。TRR_PがARR_Pを大きく下回っている場合、受信機は結合してはなりません。
o The receiver calculates REQN as described in Section 3.2.2.3.
o 受信機は、セクション3.2.2.3で説明されているようにREQNを計算します。
o The receiver calculates TRATE as described in Section 3.2.2.7.
o 受信機は、セクション3.2.2.7で説明されているようにTRATEを計算します。
o If the sender is not sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1), the receiver MUST not join. If the sender is sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1) and TRATE < SR_P, the receiver MUST not join.
o 送信者が一定の集合レートで送信していない場合、trate <arr_p*（（1/p）^{nwc 2} -1）/（（1/p）^{nwc 1} -1）。送信者が一定の集合レートとtrate <arr_p*（（1/p）^{nwc 2} -1）/（（1/p）^{nwc 1} -1）およびtrate <sr_pで送信している場合、受信者参加してはいけません。
o If SSR_P is finite and the sender is not sending at constant aggregate rate or SSR_P is finite and the sender is sending at constant aggregate rate and TRATE < SR_P then the receiver MAY apply one additional OPTIONAL check before deciding to join.
o SSR_Pが有限であり、送信者が一定の集計レートで送信していない場合、またはSSR_Pが有限であり、送信者が一定の集合レートとTRATE <SR_Pで送信している場合、受信者は参加を決定する前に追加のオプションのチェックを1つ適用できます。
It is RECOMMENDED that the receiver not join if the value of RR_P is not sufficiently lower than the maximum value of RR_P observed since the last join. It is RECOMMENDED that RR_P is sufficiently low to allow a join if RR_P <= max{RRmax-2/EL,P*RRmax}, where RRmax is the maximum measured RR_P since the last join.
RR_Pの値が最後の結合以降に観察されたRR_Pの最大値よりも十分に低くない場合、受信機が結合しないことをお勧めします。RR_P <= max {rrmax-2/el、p*rrmax}の場合、rr_pは結合を許可するのに十分に低いことをお勧めします。ここで、rrmaxは最後の結合以来測定された最大rr_pです。
If the receiver does not join because RR_P is not sufficiently small then a value of LOSSP is calculated so as to make the value of the REQN equation given in Section 3.2.2.3 evaluate to ARR_P*((1/P)^(NWC+2)-1)/((1/P)^(NWC+1)-1) with respect to the current value of ARR_P. Then, the variables associated with LOSSP are reset based on this calculated value of LOSSP as described at the end of Section 3.2.2.1.
RR_Pが十分に小さいために受信機が結合しない場合、セクション3.2.2.3で与えられたREQN方程式の値をARR_P*（（1/P）^（NWC 2）に評価するために、損失の値が計算されます。-1）/（（1/p）^（nwc 1）-1）arr_pの現在の値に関して。次に、セクション3.2.2.1の最後に記載されているように、損失に関連付けられた変数は、この計算された損失値の計算値に基づいてリセットされます。
o Otherwise, the receiver MAY join the next higher layer.
o それ以外の場合、受信機は次の高層層に参加できます。
Suppose the receiver has decided to join and CTSI = i. The receiver joins the next higher wave channel, i.e., the wave channel with CN = i+NWC modulo T, increments NWC by 1, and then updates ARR_P to ARR_P*((1/P)^{NWC+1}-1)/((1/P)^NWC-1) as described in Section 3.2.2.5. The time of the join is recorded for use in updating ARTT as described in Section 3.2.2.2.
受信者が参加することを決定したとします。CTSI= i。受信機は次の高波チャネル、つまりCN = I NWC Modulo Tの波チャネル、NWCを1で増分し、ARR_PをARR_P*（（1/P）^{NWC 1} -1）/（（）に更新します。（1/p）^nwc-1）セクション3.2.2.5で説明されています。結合時間は、セクション3.2.2.2で説明されているように、ARTTの更新に使用するために記録されます。
When no packet arrives in response to the join of channel for a long period of time, the join times out. The receiver sets JOINING to false, updates ARR_P to ARR_P*((1/P)^NWC-1)/((1/P)^{NWC+1}-1), and then decrements NWC by 1.
チャンネルの結合に応じて長期間パケットが到着しない場合、参加は時間を出します。受信機はfalseに結合し、arr_p*（（1/p）^nwc-1）/（（1/p）^{nwc 1} -1）にarr_pを更新し、NWCを1で減少させます。
The RECOMMENDED threshold for a join timeout is max{2*V/ARTT,10*ARTT} seconds.
結合タイムアウトの推奨しきい値は、max {2*v/artt、10*artt}秒です。
These are timeouts when the packet reception behavior is far from what it should be and these MUST trigger the receiver to leave the session. Exceptional timeouts include
これらは、パケット受信の動作が本来あるべきものとはほど遠い場合のタイムアウトであり、セッションを離れるように受信者にトリガーする必要があります。例外的なタイムアウトには含まれます
o No packets are received for a long period. A RECOMMENDED threshold is max{10,TSD} seconds.
o 長期間にわたってパケットは受信されていません。推奨されるしきい値は、最大{10、TSD}秒です。
o There is no change in time slot index for a long period. A RECOMMENDED threshold is max{20,2*TSD} seconds.
o 時間スロットインデックスに長い間変更はありません。推奨されるしきい値は、最大{20,2*TSD}秒です。
WEBRC is intended to be a congestion control scheme that can be used in a complete protocol instantiation that delivers objects and streams (both reliable content delivery and streaming of multimedia information). WEBRC is most applicable for delivery of objects or streams of substantial length, i.e., objects or streams that range in length from hundreds of kilobytes to many gigabytes, and whose transfer time is on the order of tens of seconds or more.
WEBRCは、オブジェクトとストリームを提供する完全なプロトコルインスタンス化（信頼できるコンテンツ配信とマルチメディア情報のストリーミングの両方）で使用できる混雑制御スキームであることを目的としています。WeBRCは、かなりの長さのオブジェクトまたはストリームの配信に最も適用できます。つまり、数百キロバイトから多くのギガバイトに至るまでの長さの範囲のオブジェクトまたはストリーム、およびその転送時間は数秒以上です。
WEBRC can be used with both multicast and unicast networks. However, the scope of this document is limited to multicast. WEBRC requires connectivity between a sender and receivers, but does not require connectivity from receivers to the sender.
WEBRCは、マルチキャストネットワークとユニキャストネットワークの両方で使用できます。ただし、このドキュメントの範囲はマルチキャストに限定されています。WeBRCは、送信者と受信機間の接続を必要としますが、受信者から送信者への接続は必要ありません。
WEBRC inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of WEBRC is unlimited. However, in some network environments varying reception rates to receivers may not be advantageous. For example, the network may have dedicated a fixed amount of bandwidth to the session or there may be no effective way for receivers to dynamically vary the set of channels they are joined to, as in a satellite network.
WEBRCは、LAN、WAN、イントラネット、インターネット、非対称ネットワーク、ワイヤレスネットワーク、衛星ネットワークなど、あらゆる種類のネットワークで本質的に動作します。したがって、WEBRCの固有の生のスケーラビリティは無制限です。ただし、一部のネットワーク環境では、受信率をレシーバーに変化させることは有利ではない場合があります。たとえば、ネットワークはセッションに固定量の帯域幅を専用にしている可能性があります。または、衛星ネットワークのように、レシーバーが結合されたチャネルのセットを動的に変化させる効果的な方法がない場合があります。
Receivers join and leave channels using the appropriate multicast join and leave messages. For IPv4 multicast, IGMP messages are used by receivers to join and leave channels. For IPv6, MLDv2 messages are used by receivers to join and leave channels. This is the only dependency of WEBRC on the IP version.
受信者は、適切なマルチキャスト結合およびメッセージを使用して、チャンネルに参加して離れます。IPv4マルチキャストの場合、IGMPメッセージはレシーバーがチャンネルに参加および離れるために使用されます。IPv6の場合、MLDV2メッセージはレシーバーによってチャネルに参加して出発するために使用されます。これは、WEBRCのIPバージョンへの唯一の依存関係です。
WEBRC requires receivers to be able to uniquely identify and demultiplex packets associated with a session in order to effectively perform congestion control over all packets associated with the session. How receivers achieve this is outside the scope of this document.
WEBRCは、セッションに関連するすべてのパケットを効果的に実行するために、セッションに関連付けられたパケットを一意に識別および非難するパケットを一意に識別および非難することができることを要求しています。受信者がこれを達成する方法は、このドキュメントの範囲外です。
WEBRC is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [7] is such a best effort network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers.
WEBRCは、パケットの受信、パケット受信順序を保証せず、フローや輻輳制御をサポートしていない「最良の努力」サービスである基礎となるネットワークまたは輸送サービスで使用されると推定されます。たとえば、RFC 1112 [7]で定義されているIPマルチキャストの任意のソースマルチキャスト（ASM）モデルは、非常に最良の努力ネットワークサービスです。RFC 1112が提供する基本的なサービスは大部分がスケーラブルですが、特に不均一なレシーバーセットが存在する場合、深刻なスケーラビリティの制限を回避するために、渋滞制御または信頼性を慎重に提供する必要があります。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [7] and the Source-Specific Multicast (SSM) model as defined in [10]. WEBRC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and the WEBRC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the WEBRC channel address coincides with the SSM channel address.
現在、RFC 1112 [7]で定義されている任意のソースマルチキャスト（ASM）モデルと、[10]で定義されているソース固有のマルチキャスト（SSM）モデル、マルチキャスト配信の2つのモデルがあります。WEBRCは両方のマルチキャストモデルで動作しますが、やや異なる環境の懸念を抱えてやや異なる方法で動作します。ASMを使用する場合、送信者SはマルチキャストグループGにパケットを送信し、WEBRCチャネルアドレスはペア（S、G）で構成され、Sは送信者のIPアドレス、Gはマルチキャストグループアドレスです。SSMを使用する場合、送信者SはパケットをSSMチャネル（S、G）に送信し、WEBRCチャネルアドレスはSSMチャネルアドレスと一致します。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of channel addresses easy with SSM. To allocate channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of WEBRC channel addresses more difficult with ASM. This is an issue for WEBRC because several channels are used per session.
送信者は、一意のSSMチャネルアドレスをローカルに割り当てることができ、これによりSSMでチャネルアドレスの割り当てが簡単になります。ASMを使用してチャネルアドレスを割り当てるには、送信者はグループの範囲全体でASMマルチキャストグループアドレスを一意に選択する必要があります。これにより、ASMでWEBRCチャネルアドレスの割り当てがより困難になります。セッションごとにいくつかのチャネルが使用されるため、これはWEBRCの問題です。
WEBRC channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested WEBRC channel. With ASM, the receiver joins a channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources.
WeBRCチャネルとSSMチャネルが一致するため、受信機は要求されたWEBRCチャネルに送信されたパケットのみを受信します。ASMを使用すると、レシーバーはマルチキャストグループGに参加してチャネルに結合し、送信者に関係なくGに送信されるすべてのパケットが受信者によって受信される場合があります。したがって、SSMには、サービス拒否攻撃の防止のためにASMよりも説得力のあるセキュリティの利点があります。どちらの場合でも、受信機はメカニズムを使用して、不要なソースからパケットを除外する必要があります。
WEBRC assumes that the packet route between the sender and a particular receiver is the same for all channels associated with a session. For SSM this assumption is true because the multicast tree is a shortest path tree from each receiver to the sender and generally this path changes infrequently. For ASM there are some issues that if not properly considered may invalidate this assumption. With ASM, the packet route between the sender and receivers may initially be through the Rendezvous Point (RP) and then switch over to the shortest path to the sender as packets start flowing in a channel. The first issue is that the RP may not be the same for all channels associated with a session, and thus the first packets sent to the channels may follow a route that depends on the RP of the channel. This depends on the RP configuration for the sender. If the sender registers all channels associated with the session with the same RP then the assumption is true, but if the sender registers different channels with different RPs then the assumption may not be true. Thus, it is RECOMMENDED that the sender register all channels associated with a session with the same RP. Another issue is that when the channel switches over from the RP to the sender-based tree then the route to the receivers may vary within a channel. Furthermore, this may cause either the receipt of duplicate packets at receivers or loss of packets depending on the smoothness of the switchover. Thus, it is RECOMMENDED that the RP be placed as close as possible to the sender. The best location for the RP is that it be the first-hop router closest to the sender, in which case the path to the sender and the path to the RP is the same for each receiver and the problems mentioned above are eliminated. The consequences of this assumption not being true are that the receiver reaction to congestion may not be appropriate. Generally, the WEBRC receiver will act conservatively and reduce its reception rate too much if this assumption is not true, but there can be cases where the receivers will act inappropriately.
Webrcは、送信者と特定のレシーバー間のパケットルートがセッションに関連付けられているすべてのチャネルで同じであると想定しています。SSMの場合、マルチキャストツリーは各レシーバーから送信者への最短パスツリーであり、一般にこのパスはまれに変化するため、この仮定は真実です。ASMには、適切に考慮されていない場合、この仮定を無効にする可能性があるいくつかの問題があります。ASMを使用すると、送信者と受信機の間のパケットルートは、最初はRendezvous Point（RP）を通過し、パケットがチャネルで流れるようになり、送信者への最短パスに切り替えることができます。最初の問題は、RPがセッションに関連付けられたすべてのチャネルで同じではない可能性があるため、チャネルに送信された最初のパケットは、チャネルのRPに依存するルートに従うことができます。これは、送信者のRP構成に依存します。送信者が同じRPでセッションに関連付けられているすべてのチャネルを登録する場合、仮定は真ですが、送信者が異なるRPで異なるチャネルを登録すると、仮定は真でない場合があります。したがって、送信者は、同じRPとのセッションに関連付けられたすべてのチャネルを登録することをお勧めします。別の問題は、チャネルがRPから送信者ベースのツリーに切り替わると、レシーバーへのルートがチャネル内で異なる場合があることです。さらに、これにより、スイッチオーバーの滑らかさに応じて、受信機で重複したパケットを受け取るか、パケットの喪失のいずれかを引き起こす可能性があります。したがって、RPを送信者にできるだけ近くに配置することをお勧めします。RPに最適な場所は、送信者に最も近い最初のホップルーターであることです。その場合、送信者へのパスとRPへのパスは各受信機で同じであり、上記の問題が排除されます。この仮定が真実ではないことの結果は、輻輳に対する受信者の反応が適切ではないかもしれないということです。一般に、WEBRCレシーバーは保守的に行動し、この仮定が真実ではない場合、受信率を大きすぎますが、受信機が不適切に作用する場合があります。
Packets sent to a session using WEBRC MUST include Congestion Control Information fields as specified in this section. This document specifies short and long formats for the Congestion Control Information, and it is RECOMMENDED that protocol instantiations use one of these two formats. Other formats for the Congestion Control Information fields MAY be used by protocol instantiations, but all protocol instantiations are REQUIRED to use these fields in a format that is compatible with the interpretations of these fields. Thus, if a protocol does use a different format for the fields in the Congestion Control Information then it MUST specify the lengths and positions of these fields within the packet header.
WEBRCを使用してセッションに送信されたパケットには、このセクションで指定されているように、うっ血制御情報フィールドを含める必要があります。このドキュメントは、輻輳制御情報の短い形式と長い形式を指定しており、プロトコルインスタンス化はこれら2つの形式のいずれかを使用することをお勧めします。輻輳制御情報フィールドの他の形式は、プロトコルインスタンス化で使用できますが、これらのフィールドをこれらのフィールドの解釈と互換性のある形式で使用するには、すべてのプロトコルインスタンス化が必要です。したがって、プロトコルが輻輳制御情報のフィールドに異なる形式を使用する場合、パケットヘッダー内のこれらのフィールドの長さと位置を指定する必要があります。
All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. All constants, unless otherwise specified, are expressed in base ten.
すべての整数フィールドは、「ビッグエンディアン」または「ネットワーク注文」形式で運ばれます。つまり、最も重要なバイト（オクテット）です。特に指定がない限り、すべての定数はベース10で表されます。
The short format for the Congestion Control Information is shown in Fig. 1. The total length of the short format is 32-bits.
輻輳制御情報の短い形式を図1に示します。短い形式の全長は32ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTSI | Channel Number| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 - Short format for Congestion Control Information
図1-混雑制御情報の短い形式
The function of each field in the Congestion Control Information is the following.
混雑制御情報における各フィールドの機能は次のとおりです。
Current Time Slot Index (CTSI): 8 bits
現在の時間スロットインデックス（CTSI）：8ビット
CTSI indicates the index of the current time slot. This must be sent in each packet within the session. The Current Time Slot Index increases by one modulo T each TSD seconds at the sender, where T is the number of time slots associated with the session and TSD is the time slot duration. Note that T is also the number of wave channels associated with the session, and thus T MUST be at most 255.
CTSIは、現在の時間スロットのインデックスを示します。これは、セッション内の各パケットに送信する必要があります。現在のタイムスロットインデックスは、送信者で各TSD秒を1モジュロT秒増加します。Tはセッションに関連付けられた時間スロット数であり、TSDは時間スロットの持続時間です。Tはセッションに関連する波チャネルの数でもあるため、Tは最大255でなければならないことに注意してください。
Channel Number (CN): 8 bits
チャネル番号（CN）：8ビット
CN is the channel number that this packet belongs to. CN for the base channel is T, and the CNs for the wave channels are 0 through T-1. Thus, T+1 channels in total are used, and thus T MUST be at most 255.
CNは、このパケットが属するチャネル番号です。ベースチャネルのCNはTで、波チャネルのCNSは0〜T-1です。したがって、合計で1チャネルが使用されるため、Tは最大255でなければなりません。
Packet Sequence Number (PSN): 16 bits
パケットシーケンス番号（PSN）：16ビット
The PSN of each packet is scoped by its CN value. The sequence numbers of consecutive packets sent to the base channel are numbered consecutively modulo 2^16. The same sequence of PSNs are used for each wave channel in each cycle. The sequence numbers of consecutive packets sent to a wave channel are numbered consecutively modulo 2^16 within each cycle, ending with the last packet sent to the channel before the channel goes quiescent with PSN = 2^16-1.
各パケットのPSNは、そのCN値によってスコープされます。ベースチャネルに送信された連続したパケットのシーケンス番号には、連続して数字が記載されています。各サイクルの各ウェーブチャネルに同じシーケンスが使用されます。ウェーブチャネルに送信された連続したパケットのシーケンス番号は、各サイクル内で連続して数字で数字であり、チャネルがPSN = 2^16-1で静止する前にチャネルに送信される最後のパケットで終了します。
The long format for the Congestion Control Information is shown in Fig. 2. The total length of the long format is 64-bits.
輻輳制御情報の長い形式を図2に示します。長い形式の総長さは64ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTSI | Channel Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2 - Long format for Congestion Control Information
図2-混雑制御情報の長い形式
The meaning of each field for the long format is the same as for the short format, the only difference is that each field is twice as long.
長い形式の各フィールドの意味は、短い形式の場合と同じです。唯一の違いは、各フィールドが2倍の長さであることです。
Current Time Slot Index (CTSI): 16 bits
現在の時間スロットインデックス（CTSI）：16ビット
CTSI indicates the index of the current time slot. This must be sent in each packet within the session. The Current Time Slot Index increases by one modulo T each TSD seconds at the sender, where T is the number of time slots associated with the session and TSD is the time slot duration. Note that T is also the number of wave channels associated with the session, and thus T MUST be at most 65,535.
CTSIは、現在の時間スロットのインデックスを示します。これは、セッション内の各パケットに送信する必要があります。現在のタイムスロットインデックスは、送信者で各TSD秒を1モジュロT秒増加します。Tはセッションに関連付けられた時間スロット数であり、TSDは時間スロットの持続時間です。Tはセッションに関連する波チャネルの数でもあるため、Tは最大65,535でなければならないことに注意してください。
Channel Number (CN): 16 bits
チャネル番号（CN）：16ビット
CN is the channel number that this packet belongs to. CN for the base channel is T, and the CNs for the wave channels are 0 through T-1. Thus, T+1 channels in total are used, and thus T MUST be at most 65,535.
CNは、このパケットが属するチャネル番号です。ベースチャネルのCNはTで、波チャネルのCNSは0〜T-1です。したがって、合計で1チャネルが使用されるため、Tは最大65,535でなければなりません。
Packet Sequence Number (PSN): 32 bits
パケットシーケンス番号（PSN）：32ビット
The PSN of each packet is scoped by its CN value. The sequence numbers of consecutive packets sent to the base channel are numbered consecutively modulo 2^32. The same sequence of PSNs are used for each wave channel in each cycle. The sequence numbers of consecutive packets sent to a wave channel are numbered consecutively modulo 2^32 within each cycle, ending with the last packet sent to the channel before the channel goes quiescent with PSN = 2^32-1.
各パケットのPSNは、そのCN値によってスコープされます。ベースチャネルに送信された連続したパケットのシーケンス番号には、連続して数字が記載されています。各サイクルの各ウェーブチャネルに同じシーケンスが使用されます。ウェーブチャネルに送信された連続したパケットのシーケンス番号には、各サイクル内で連続して数字が記載されており、チャネルがPSN = 2^32-1で静止する前にチャネルに送信される最後のパケットで終了します。
As described in RFC 3048 [4], WEBRC is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation.
RFC 3048 [4]で説明されているように、WeBRCは、他のビルディングブロックと組み合わせて、プロトコルのインスタンス化を指定するために使用することを目的としたビルディングブロックです。
WEBRC does not provide higher level session support, e.g., how receivers obtain the necessary session description and how the receivers demultiplex received packets based on their session. There is support provided by other building blocks that can be used in conjunction with WEBRC to provide some of this support. For example, LCT [12] can provide some of the higher level in-band session support that may be needed by receivers, and the WEBRC Congestion Control Information (CCI) required in each packet can be carried in the CCI field of the LCT header [12].
WeBRCは、より高いレベルのセッションサポートを提供しません。たとえば、受信者が必要なセッションの説明を取得する方法や、受信者がセッションに基づいてパケットをDemultiplexを受信する方法。このサポートの一部を提供するためにWEBRCと組み合わせて使用できる他のビルディングブロックから提供されるサポートがあります。たとえば、LCT [12]は、受信機が必要とするより高いレベルのバンドインセッションサポートの一部を提供でき、各パケットに必要なWEBRC輻輳制御情報（CCI）は、LCTヘッダーのCCIフィールドで運ぶことができます。[12]。
WEBRC does not provide any type of reliability, and in particular does not provide support for retransmission of loss packets. Reliability can be added by independent means, such as by the use of FEC codes as described in [13] and specified in the FEC building block [14].
WeBRCは、いかなるタイプの信頼性も提供しておらず、特に損失パケットの再送信のサポートを提供しません。信頼性は、[13]で説明されているFECコードの使用やFECビルディングブロック[14]で指定されているなど、独立した手段によって追加できます。
WEBRC can be subject to denial-of-service attacks by attackers that try to confuse the congestion control mechanism for receivers by injecting forged packets into the multicast stream. This attack most adversely affects network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Because of this and because of the potential attacks due to the use of FEC described above, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
WEBRCは、鍛造パケットをマルチキャストストリームに注入することにより、受信機の混雑制御メカニズムを混同しようとする攻撃者によるサービス拒否攻撃の対象となります。この攻撃は、攻撃の下流のネットワーク要素とレシーバーに最も悪影響を及ぼし、ネットワークやその他のレシーバーの残りの部分にはそれほど有意ではありません。このため、上記のFECの使用により潜在的な攻撃のために、すべてのネットワークルーターと送信者から受信機へのパスに沿ってスイッチで逆パス転送チェックを有効にすることをお勧めします。鍛造パケットをマルチキャストツリーデータパスに注入します。
It is also RECOMMENDED that packet authentication be used to authenticate each packet immediately upon receipt before the receiver performs any WEBRC actions based upon its receipt. Unfortunately, there are currently no practical multicast packet authentication schemes that offer instant packet authentication upon receipt. However, TESLA [17] can be used to authenticate each packet a few seconds after receipt. Thus, TESLA could be used in conjunction with WEBRC to authenticate packets and for example terminate the session upon detection of a forged packet. However, it is RECOMMENDED that the normal WEBRC receiver responses to received packets occur immediately -- not delayed by the TESLA authentication process. This is because the overall WEBRC performance would be greatly degraded if the receiver delayed its WEBRC response to packet receipt for several seconds.
また、受信者が受領に基づいてWEBRCアクションを実行する前に、受領前に各パケットを認証するために、パケット認証を使用することもお勧めします。残念ながら、現在、受領時にインスタントパケット認証を提供する実用的なマルチキャストパケット認証スキームはありません。ただし、Tesla [17]を使用して、受領後数秒後に各パケットを認証できます。したがって、テスラはWEBRCと併用してパケットを認証し、たとえば偽造パケットの検出時にセッションを終了することができます。ただし、受信したパケットに対する通常のWEBRCレシーバー応答はすぐに発生することをお勧めします - Tesla認証プロセスによって遅延はありません。これは、レシーバーが数秒間パケット領収書に対するWEBRCの応答を遅らせた場合、全体的なWEBRCパフォーマンスが大幅に低下するためです。
A receiver with an incorrect or corrupted implementation of WEBRC may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session.
WEBRCの誤ったまたは破損した実装を持つレシーバーは、送信者と受信機の間のパスでのネットワークの健康に影響を与える可能性があり、セッションに参加した他の受信者の受信率にも影響を与える可能性があります。したがって、受信者は、セッションに参加するために必要なセッションの説明を受け取る前に、自分自身を正当であると特定する必要があることをお勧めします。
Another vulnerability of WEBRC is the potential of receivers obtaining an incorrect session description for the session. The consequences of this could be that legitimate receivers with the wrong session description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders.
WEBRCのもう1つの脆弱性は、セッションの誤ったセッションの説明を取得するレシーバーの可能性です。この結果、セッションの説明が間違っている正当な受信者がセッションコンテンツを正しく受信できないこと、または受信者が誤って能力よりもはるかに高いレートで受け取ることを試み、それによりネットワークの一部のトラフィックを破壊することです。これらの問題を回避するために、レシーバーが誤ったセッションの説明を受け入れるのを防ぐための措置を講じることをお勧めします。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[2] Kermode、R。およびL. Vicisano、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[3] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[3] Mankin、A.、Romanow、A.、Bradner、S。and V. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[4] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[4] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[5] Byers, J., Horn, G., Luby, M., Mitzenmacher, M. and W. Shaver. "FLID-DL: Congestion control for layered multicast," IEEE J. on Selected Areas in Communications, Special Issue on Network Support for Multicast Communication, Vol. 20, No. 8, October 2002, pp. 1558-1570.
[5] Byers、J.、Horn、G.、Luby、M.、Mitzenmacher、M。およびW. Shaver。「flid-dl：階層化されたマルチキャストの輻輳制御」、IEEE J.20、No。8、2002年10月、pp。1558-1570。
[6] Dagum, P., Karp, R., Luby, M. and S. Ross, "An optimal algorithm for Monte Carlo estimation," SIAM J. Comput., 29(5):1484-1496, April 2000.
[6] Dagum、P.、Karp、R.、Luby、M。and S. Ross、「モンテカルロ推定のための最適なアルゴリズム」、Siam J. Comput。、29（5）：1484-1496、2000年4月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[8] Goyal, V., "On WEBRC Wave Design and Server Implementation", Digital Fountain Technical Report no. DF2002-09-001, September 2002, available at http://www.digitalfountain.com/technology/.
[8] Goyal、V。、「Webrc Wave Design and Serverの実装について」、Digital Fountain Technical Report no。DF2002-09-001、2002年9月、http：//www.digitalfountain.com/technology/で入手可能。
[9] Handley, M., Floyd, S., Padhye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[9] Handley、M.、Floyd、S.、Padhye、J。and J. Widmer、「TCP Friendly Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[10] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[10] Holbrook、H。、「マルチキャストのチャネルモデル」、博士号論文、スタンフォード大学、2001年8月、カリフォルニア州スタンフォード大学コンピューターサイエンス学科。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[11] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コード（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[12] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L.、Handley、M。and J. Crowcroft、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 3451、2002年12月。
[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[13] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[14] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。and J. Crowcroft、「Forward Error Correction（FEC）ビルディングブロック」、RFC 3452、2002年12月。
[15] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report", Digital Fountain Technical Report no. DF2002-07-001, September 2002, available at http://www.digitalfountain.com/technology/.
[15] Luby、M。and V. Goyal、「マルチキャストラウンドトリップ時間を使用した波と方程式ベースのレートコントロール：拡張レポート」、Digital Fountain Technical Report no。DF2002-07-001、2002年9月、http：//www.digitalfountain.com/technology/で入手可能。
[16] Luby, M., Goyal, V., Skaria, S. and G. Horn, "Wave and Equation Based Rate Control Using Multicast Round Trip Time", Proc. ACM SIGCOMM 2002, Pittsburgh, PA, August 2002, pp. 191-214.
[16] Luby、M.、Goyal、V.、Skaria、S。and G. Horn、「マルチキャストラウンドトリップ時間を使用した波と方程式ベースのレートコントロール」、Proc。ACM Sigcomm 2002、ペンシルバニア州ピッツバーグ、2002年8月、191-214ページ。
[17] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[17] Perrig、A.、Canetti、R.、Song、D。and J. Tygar、「マルチキャストの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS 2001、pp。35-46、2001年2月。
[18] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", Proc. IEEE Infocom '98, San Francisco, CA, March-April 1998, pp. 996-1003.
[18] Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「層状マルチキャストデータ転送のためのTCPのような混雑制御」、Proc。IEEE Infocom '98、カリフォルニア州サンフランシスコ、1998年3月〜4月、996-1003。
Michael Luby Digital Fountain 39141 Civic Center Drive, Suite 300 Fremont, CA, USA, 94538
Michael Luby Digital Fountain 39141 Civic Center Drive、Suite 300 Fremont、CA、USA、94538
EMail: luby@digitalfountain.com
Vivek K Goyal Massachusetts Institute of Technology Room 36-690 77 Massachusetts Avenue Cambridge, MA, USA, 02139
Vivek K Goyal Massachusetts Institute of Technology Room 36-690 77 Massachusetts Avenue Cambridge、MA、USA、02139
EMail: v.goyal@ieee.org
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）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。