[要約] RFC 9064は、CCNxのような情報中心のネットワーキングプロトコルのQoSアーキテクチャ開発における考慮事項について述べています。この文書の目的は、情報中心のネットワークでの品質保証の枠組みを提案することです。利用場面としては、効率的なデータ配信、信頼性の高い通信、およびネットワークリソースの最適化が挙げられます。
Internet Research Task Force (IRTF) D. Oran
Request for Comments: 9064 Network Systems Research and Design
Category: Informational June 2021
ISSN: 2070-1721
Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols
CCNXのような情報中心ネットワーキングプロトコルのためのQoSアーキテクチャの開発における考察
Abstract
概要
This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above.
これはポジションペーパーです。著者の個人的な見解は、サービスの品質（QoS）機能（CCNX）または名前付きデータネットワーキング（NDN）などの情報中心のネットワーキング（CCN）プロトコルにどのように対応するかについての著者の個人的な見解を文書化しています。 /データ交換とホップバイホップ転送状態は、基本的な機械として。そのようなプロトコルは、TCP / IPでのQoSへの実質的に異なるアプローチを要求し、そして流量と集約基準の両方で分類と区別QoS処理の両方を達成するために特定の設計パターンを提案すると主張している。また、メモリ、CPU、およびリンク帯域幅に加えて、明示的に不正なリソース割り当てを受ける必要があるリソースとしてのキャッシュの影響も考慮します。提案された方法は、純粋にネットワーク層で動作することを意図しており、トランスポートおよび高層QoS目標を達成するために必要なプリミティブを提供する。それは明示的に経験の質（QoE）の議論を明確に除外し、それはアプリケーション層以上でのみ評価され制御されます。
This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.
この文書はIRTF情報中心のネットワーキング研究グループ（ICNRG）の製品ではありませんが、正式な最後のコールを通じて、個人の提出物としての出版の研究グループの参加者の支援を受けています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットリサーチタスクフォース（IRTF）の製品です。IRTFはインターネット関連の研究開発活動の結果を発行しています。これらの結果は展開には適していない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）の情報中心のネットワーキング研究グループの1つ以上のメンバーの個々の意見を表しています。IRSGによる出版が承認された文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9064.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9064で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
1.1. Applicability Assessment by ICNRG Chairs
2. Requirements Language
3. Background on Quality of Service in Network Protocols
3.1. Basics on How ICN Protocols like NDN and CCNx Work
3.2. Congestion Control Basics Relevant to ICN
4. What Can We Control to Achieve QoS in ICN?
5. How Does This Relate to QoS in TCP/IP?
6. Why Is ICN Different? Can We Do Better?
6.1. Equivalence Class Capabilities
6.2. Topology Interactions with QoS
6.3. Specification of QoS Treatments
6.4. ICN Forwarding Semantics Effect on QoS
6.5. QoS Interactions with Caching
7. Strawman Principles for an ICN QoS Architecture
7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS
Semantics?
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Author's Address
The TCP/IP protocol suite used on today's Internet has over 30 years of accumulated research and engineering into the provisioning of QoS machinery, employed with varying success in different environments. ICN protocols like NDN [NDN] and CCNx [RFC8569] [RFC8609] have an accumulated ten years of research and very little deployment. We therefore have the opportunity to either recapitulate the approaches taken with TCP/IP (e.g., Intserv [RFC2998] and Diffserv [RFC2474]) or design a new architecture and associated mechanisms aligned with the properties of ICN protocols, which differ substantially from those of TCP/IP. This position paper advocates the latter approach and comprises the author's personal views on how QoS capabilities ought to be accommodated in ICN protocols like CCNx or NDN. Specifically, these protocols differ in fundamental ways from TCP/IP. The important differences are summarized in Table 1:
今日のインターネットで使用されているTCP / IPプロトコルスイートは、さまざまな環境で成功した成功を積んでQoS機械のプロビジョニングに30年以上の研究とエンジニアリングを採用しています。NDN [NDN]とCCNX [RFC8569]のようなICNプロトコル[RFC8609]は、10年間の研究と非常に少ない展開を積んでいます。したがって、我々は、TCP / IP（intServ [RFC2998]およびDIFFSERV [RFC2474]）で撮影されたアプローチを再設定するか、またはICNプロトコルの特性と整列した新しいアーキテクチャおよび関連するメカニズムを設計する機会があります。TCP / IP。このポジションペーパーは後者のアプローチを提唱し、QoS機能がCCNXまたはNDNのようなICNプロトコルにどのように対応するべきかについての著者の個人的な見解を含む。具体的には、これらのプロトコルはTCP / IPからの基本的な方法が異なります。重要な違いは表1に要約されています。
+=============================+====================================+
| TCP/IP | CCNx or NDN |
+=============================+====================================+
| Stateless forwarding | Stateful forwarding |
+-----------------------------+------------------------------------+
| Simple packets | Object model with optional caching |
+-----------------------------+------------------------------------+
| Pure datagram model | Request-response model |
+-----------------------------+------------------------------------+
| Asymmetric routing | Symmetric routing |
+-----------------------------+------------------------------------+
| Independent flow directions | Flow balance (see note below) |
+-----------------------------+------------------------------------+
| Flows grouped by IP prefix | Flows grouped by name prefix |
| and port | |
+-----------------------------+------------------------------------+
| End-to-end congestion | Hop-by-hop congestion control |
| control | |
+-----------------------------+------------------------------------+
Table 1: Differences between IP and ICN Relevant to QoS Architecture
表1：QoSアーキテクチャに関連するIPとICNの違い
Note: Flow balance is a property of NDN and CCNx that ensures one Interest packet provokes a response of no more than one Data packet. Further discussion of the relevance of this to QoS can be found in [FLOWBALANCE].
注：フローバランスはNDNとCCNXのプロパティであり、1つの関心パケットが1つのデータパケットの応答を引き起こすことを保証することを保証します。QoSへの関連性についてのさらなる議論は[流動性]に見出すことができる。
This document proposes specific design patterns to achieve both flow classification and differentiated QoS treatment for ICN on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve both transport and higher-layer QoS objectives. It does not propose detailed protocol machinery to achieve these goals; it leaves these to supplementary specifications, such as [FLOWCLASS] and [DNC-QOS-ICN]. It explicitly excludes any discussion of QoE, which can only be assessed and controlled at the application layer or above.
この文書は、流れと集計基準の両方でICNのフロー分類と区別QoS処理の両方を達成するための特定の設計パターンを提案します。また、メモリ、CPU、およびリンク帯域幅に加えて、明示的に不正なリソース割り当てを受ける必要があるリソースとしてのキャッシュの影響も考慮します。提案された方法は、純粋にネットワーク層で動作することを意図しており、輸送および上層の両方のQoS目標を達成するために必要とされるプリミティブを提供する。これらの目標を達成するための詳細なプロトコル機械を提案するものではありません。それは、[FlowClass]や[DNC-QoS-ICN]などの補足仕様に残ります。それはQoEの議論を明確に除外し、それはアプリケーション層以上でのみ評価され制御され得る。
Much of this document is derived from presentations the author has given at ICNRG meetings over the last few years that are available through the IETF datatracker (see, for example, [Oran2018QoSslides]).
この文書の多くは、著者がIETF DataTrackerを介して入手可能な最後の数年間にICNRG会議で行ったプレゼンテーションから派生しています（たとえば、[Oran2018Qosslides]を参照）。
QoS in ICN is an important topic with a huge design space. ICNRG has been discussing different specific protocol mechanisms as well as conceptual approaches. This document presents architectural considerations for QoS, leveraging ICN properties instead of merely applying IP-QoS mechanisms, without defining a specific architecture or specific protocol mechanisms yet. However, there is consensus in ICNRG that this document, clarifying the author's views, could inspire such work and should hence be published as a position paper.
ICNのQoSは、巨大なデザインスペースを持つ重要なトピックです。ICNRGは、異なる特定のプロトコルメカニズムと概念的なアプローチについて議論されています。この文書は、特定のアーキテクチャまたは特定のプロトコルメカニズムをまだ定義せずに、IP-QoSメカニズムを単に適用するのではなく、ICNプロパティを活用して、QoSのアーキテクチャ上の考慮事項を示しています。ただし、著者の見解を明確にするこの文書がそのような作業を促すことができ、したがってポジションペーパーとして公開されるべきであることをICNRGにはコンセンサスがあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Much of this background material is tutorial and can be simply skipped by readers familiar with the long and checkered history of quality of service in packet networks. Other parts of it are polemical yet serve to illuminate the author's personal biases and technical views.
この背景素材の多くはチュートリアルであり、パケットネットワークにおけるサービス品質の長い時間と市松模様の歴史に精通している読者によって簡単にスキップできます。その他の部分は偽造でありながら著者の個人的な偏りや技術的な見解を照らすのに役立ちます。
All networking systems provide some degree of "quality of service" in that they exhibit nonzero utility when offered traffic to carry. In other words, the network is totally useless if it never delivers any of the traffic injected by applications. The term QoS is therefore more correctly applied in a more restricted sense to describe systems that control the allocation of various resources in order to achieve _managed unfairness_. Absent explicit mechanisms to decide which traffic to treat unfairly, most systems try to achieve some form of "fairness" in the allocation of resources, optimizing the overall utility delivered to all traffic under the constraint of available resources. From this, it should be obvious that you cannot use QoS mechanisms to create or otherwise increase resource capacity! In fact, all known QoS schemes have nonzero overhead and hence may (albeit slightly) decrease the total resources available to carry user traffic.
すべてのネットワーキングシステムは、キャリーへのトラフィックを提供したときにゼロ以外のユーティリティを示すという点で、ある程度の「サービス品質」を提供します。言い換えれば、ネットワークは、アプリケーションによって注入されたトラフィックを決して配信しない場合、ネットワークは完全に無駄です。したがって、QoSという用語は、_managed不正確さを達成するために様々なリソースの割り当てを制御するシステムを記述するために、より制限された意味でより正確に適用される。明示的なメカニズムが不当に扱うためにどのトラフィックを不当に扱うかを決定するために、ほとんどのシステムはリソースの割り当てにおいて何らかの形式の「公平性」を達成しようとし、利用可能なリソースの制約の下ですべてのトラフィックに配信される全体的なユーティリティを最適化します。このことから、QoSメカニズムを使用してリソース容量を作成するか、その他の方法で増やすことができないことは明らかです。実際、すべての既知のQoS方式はゼロ以外のオーバーヘッドを持ち、したがってユーザートラフィックを搬送するために利用可能な総リソースを減らすことができます。
Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of network conditions:
さらに、累積経験は、QoSがかなり狭い範囲のネットワーク状態で役立つことを示すようです。
* If your resources are lightly loaded, you don't need it, as neither congestive loss nor substantial queuing delay occurs.
* リソースが軽くロードされている場合は、鬱血損失も実質的なキューイング遅延も発生しないため、必要ありません。
* If your resources are heavily oversubscribed, it doesn't save you. So many users will be unhappy that you are probably not delivering a viable service.
* あなたのリソースが重くオーバーサブスクライブされている場合は、節約できません。そんなに多くのユーザーがあなたがおそらく実行可能なサービスを提供していないことが不幸になるでしょう。
* Failures can rapidly shift your state from the first above to the second, in which case either:
* 障害は、上の最初のものから2番目まで迅速にあなたの状態をシフトすることができます。
- Your QoS machinery cannot respond quickly enough to maintain the advertised service quality continuously, or
- あなたのQoS機械類は、宣伝されたサービス品質を連続的に維持するのに十分に速く対応することはできません。
- Resource allocations are sufficiently conservative to result in substantial wasted capacity under non-failure conditions.
- リソース割り当ては、故障状態の下で実質的な無駄な能力をもたらすのに十分に保守的です。
Nevertheless, though not universally deployed, QoS is advantageous at least for some applications and some network environments. Some examples include:
それにもかかわらず、普遍的に展開されていないが、QoSは少なくともいくつかのアプリケーションおよびいくつかのネットワーク環境に対して有利である。いくつかの例は次のとおりです。
* Applications with steep utility functions [Shenker2006], such as real-time multimedia
* リアルタイムマルチメディアなどの急なユーティリティ関数[Shenker2006]のアプリケーション
* Applications with safety-critical operational constraints, such as avionics or industrial automation
* アビオニクスや産業用オートメーションなどの安全に重大な運用上の制約を持つアプリケーション
* Dedicated or tightly managed networks whose economics depend on strict adherence to challenging service level agreements (SLAs)
* 経済学が厳しいサービスレベル契約への厳密な遵守に依存する専用または厳密に管理されたネットワーク（SLA）
Another factor in the design and deployment of QoS is the scalability and scope over which the desired service can be achieved. Here there are two major considerations, one technical, the other economic/ political:
QoSの設計および展開における別の要因は、所望のサービスが達成され得るスケーラビリティおよびスコープである。ここでは、2つの主要な考慮事項、1つの技術的、その他の経済的/政治的なものがあります。
* Some signaled QoS schemes, such as the Resource reSerVation Protocol (RSVP) [RFC2205], maintain state in routers for each flow, which scales linearly with the number of flows. For core routers through which pass millions to billions of flows, the memory required is infeasible to provide.
* リソース予約プロトコル（RSVP）[RFC2205]などのシグナリングQoS方式は、各フローに対してルータ内の状態を維持し、これはフロー数と共に拡大縮小します。何百万ものフローを通過するコアルータの場合、必要なメモリは提供できない。
* The Internet is comprised of many minimally cooperating autonomous systems [AS]. There are practically no successful examples of QoS deployments crossing the AS boundaries of multiple service providers. In almost all cases, this limits the applicability of QoS capabilities to be intra-domain.
* インターネットは、多くの最小限の協力的な自律システムで構成されています。複数のサービスプロバイダのAS境界を横切るQoS展開の正常な例は実質的にありません。ほとんどすべての場合において、これはQoS機能の適用性をドメイン内に制限します。
This document adopts a narrow definition of QoS as _managed unfairness_ (see note below). However, much of the networking literature uses the term more colloquially, applying it to any mechanism that improves overall performance. One could use a different, broader definition of QoS that encompasses optimizing the allocation of network resources across all offered traffic without considering individual users' traffic. A consequence would be the need to cover whether (and how) ICN might result in better overall performance than IP under constant resource conditions, which is a much broader goal than that attempted here. The chosen narrower scope comports with the commonly understood meaning of "QoS" in the research community. Under this scope, and under constant resource constraints, the only way to provide traffic discrimination is in fact to sacrifice fairness. Readers assuming the broader context will find a large class of proven techniques to be ignored. This is intentional. Among these are seamless producer mobility schemes like MAP-Me [Auge2018] and network coding of ICN data as discussed in [NWC-CCN-REQS].
この文書は_managed不正確さ_としてQoSの狭い定義を採用しています（下記の注文を参照）。しかしながら、ネットワーキングの文献の多くは、全体的な性能を向上させるあらゆるメカニズムにそれを適用して、その用語をよりゾーンに使用します。個々のユーザーのトラフィックを考慮せずに、すべての提供されたトラフィックにわたるネットワークリソースの割り当てを最適化するQoSの異なるより広範な定義を使用することができます。その結果、ICNが一定のリソース条件下でIPよりも優れた全体的なパフォーマンスをもたらす可能性があるかどうかをカバーする必要があります。これは、ここで試行されたものよりはるかに幅広い目標です。選択されたより狭いスコープは、研究界の「QoS」の一般的に理解されている意味で詰まっています。この範囲の下で、そして一定のリソース制約の下で、トラフィック差別を提供する唯一の方法は実際に公平性を犠牲にすることです。より広範な文脈を想定している読者は、無視するための大きなクラスの証明された技術を見つけるでしょう。これは意図的です。これらの中には、MAP-ME [AUGE2018]のようなシームレスプロデューサーモビリティスキームと[NWC-CCN-REQS]で説明したようなICNデータのネットワークコーディングです。
Note: The term _managed unfairness_ used to explain QoS is generally ascribed to Van Jacobson, who in talks in the late 1990s said, "[The problem we are solving is to] Give 'better' service to some at the expense of giving worse service to others. QoS fantasies to the contrary, it's a zero-sum game. In other words, QoS is _managed unfairness_."
注：QoSを説明するために使用される_managed不正行為は一般に、1990年代後半の協議では、「解決している問題は、より悪いサービスを与える費用で「より良い」サービスを与えることです。他の人に。反対のQoS Fantasiesはゼロムゲームです。言い換えれば、QoSは_managed afairness_です。 "
Finally, the relationship between QoS and either accounting or billing is murky. Some schemes can accurately account for resource consumption and ascertain to which user to allocate the usage. Others cannot. While the choice of mechanism may have important practical economic and political consequences for cost and workable business models, this document considers none of those things and discusses QoS only in the context of providing managed unfairness.
最後に、QoSと会計または請求の関係は曖昧です。一部の方式は、リソース消費を正確に説明し、どのユーザーを使用するかを確認することができます。他の人はできません。メカニズムの選択は、コストや作業可能なビジネスモデルにとって重要な実用的な経済的および政治的な結果を持っているかもしれませんが、この文書はこれらのことのどれも考えず、管理されていない不公平を提供するという文脈でのみQOSを議論します。
For those unfamiliar with ICN protocols, a brief description of how NDN and CCNx operate as a packet network is in Section 3.1. Some further background on congestion control for ICN follows in Section 3.2.
ICNプロトコルに不慣れな方は、パケットネットワークとしてNDNとCCNXが動作する方法の簡単な説明がセクション3.1にあります。ICNの輻輳制御のさらなる背景は、セクション3.2に続く。
The following summarizes the salient features of the NDN and CCNx ICN protocols relevant to congestion control and QoS. Quite extensive tutorial information may be found in a number of places, including material available from [NDNTutorials].
以下は、輻輳制御およびQoSに関連するNDNおよびCCNX ICNプロトコルの顕著な機能をまとめたものです。かなり広範なチュートリアル情報は、[NDNTTUTORIALS]から入手可能な材料を含む、いくつかの場所にあるかもしれません。
In NDN and CCNx, all protocol interactions operate as a two-way handshake. Named content is requested by a _consumer_ via an _Interest message_ that is routed hop-by-hop through a series of _forwarders_ until it reaches a node that stores the requested data. This can be either the _producer_ of the data or a forwarder holding a cached copy of the requested data. The content matching the name in the Interest message is returned to the requester over the _inverse_ of the path traversed by the corresponding Interest.
NDNとCCNXでは、すべてのプロトコルインタラクションが双方向ハンドシェイクとして動作します。名前付きコンテンツは、要求されたデータを格納するノードに到達するまで、一連の_Forwarders_を介してルーティングされた_interest message_を介して_consumer_によって要求されます。これは、データの_producer_または要求されたデータのキャッシュされたコピーを保持するフォワーダーのいずれかです。関心のある関心メッセージ内の名前と一致するコンテンツは、対応する関心によって通過したパスの_inverse_を介してリクエスターに返されます。
Forwarding in CCNx and NDN is _per-packet stateful_. Routing information to select next hop(s) for an Interest is obtained from a _Forwarding Information Base (FIB)_, which is similar in function to the FIB in an IP router except that it holds name prefixes rather than IP address prefixes. Conventionally, a _Longest Name Prefix Match (LNPM)_ is used for lookup, although other algorithms are possible, including controlled flooding and adaptive learning based on prior history.
CCNXとNDNの転送は_per-packet stateful_です。関心のためのネクストホップを選択するためのルーティング情報は、IPアドレスプレフィックスではなく名前の接頭部を保持することを除いて、IPルータ内のFIBと同様の_FOFフォワード情報ベース（FIB）_から得られる。従来、_longest名プレフィックス一致（LNPM）_がルックアップに使用されますが、以前の歴史に基づく制御フラッディングと適応学習を含む他のアルゴリズムも可能です。
Each Interest message leaves a trail of "breadcrumbs" as state in each forwarder. This state, held in a data structure known as a _Pending Interest Table (PIT)_, is used to forward the returning Data message to the consumer. Since the PIT constitutes per-packet state, it is therefore a large consumer of memory resources, especially in forwarders carrying high traffic loads over long Round-Trip Time (RTT) paths, and hence plays a substantial role as a QoS-controllable resource in ICN forwarders.
各興味メッセージは、各フォワーダの状態として「ブレッドクラム」の軌跡を残します。この状態は、_pendingの関心テーブル（PIT）_として知られているデータ構造に保持されているので、戻りデータメッセージを消費者に転送するために使用されます。ピットはパケットごとの状態を構成するので、特に長い往復時間（RTT）経路にわたって高いトラフィック負荷を伝送するフォワーダにおいて、メモリリソースの大規模な消費者であり、したがってQoS制御可能なリソースとして実質的な役割を果たす。ICNフォワーダ。
In addition to its role in forwarding Interest messages and returning the corresponding Data messages, an ICN forwarder can also operate as a cache, optionally storing a copy of any Data messages it has seen in a local data structure known as a _Content Store (CS)_. Data in the CS may be returned in response to a matching Interest rather than forwarding the Interest further through the network to the original Producer. Both CCNx and NDN have a variety of ways to configure caching, including mechanisms to avoid both cache pollution and cache poisoning (these are clearly beyond the scope of this brief introduction).
興味メッセージを転送して対応するデータメッセージを返すというその役割に加えて、ICNフォワーダはまた、任意選択でそれが既知のローカルデータ構造（CS）として知られているローカルデータ構造であるデータメッセージのコピーをオプションで保存することもできる。_。CS内のデータは、ネットワークをさらに元のプロデューサに送るのをさらに転送するのではなく、一致する関心に応答して返すことができる。CCNXとNDNの両方に、キャッシュ汚染とキャッシュの中毒の両方を回避するためのメカニズムを含むキャッシュを設定するためのさまざまな方法があります（これらは明らかにこの簡単な紹介の範囲を超えています）。
In any packet network that multiplexes traffic among multiple sources and destinations, congestion control is necessary in order to:
複数のソースと宛先の間でトラフィックを多重化するパケットネットワークでは、次のために輻輳制御が必要です。
1. Prevent collapse of utility due to overload, where the total offered service declines as load increases, perhaps precipitously, rather than increasing or remaining flat.
1. オーバーロードによる有用性の崩壊を防ぐ。これは、負荷の合計が負荷が増加するにつれて、おそらく急激に増加していると平らになるか、平らに増加しています。
2. Avoid starvation of some traffic due to excessive demand by other traffic.
2. 他のトラフィックによる過度の需要のために、ある交通量の飢餓を避けてください。
3. Beyond the basic protections against starvation, achieve "fairness" among competing traffic. Two common objective functions are max-min fairness [minmaxfairness] and proportional fairness [proportionalfairness], both of which have been implemented and deployed successfully on packet networks for many years.
3. 飢餓に対する基本的な保護を超えて、競合するトラフィックの中で「公平性」を達成します。2つの一般的な目的関数は、最大で、比例公平性[MinmaxFairness]と比例公平性[比例燃料]が長年にわたってパケットネットワーク上で正常に展開されています。
Before moving on to QoS, it is useful to consider how congestion control works in NDN or CCNx. Unlike the IP protocol family, which relies exclusively on end-to-end congestion control (e.g., TCP [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and QUIC [RFC9000]), CCNx and NDN can employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path, and therefore outstanding Interests provide information that can be used to optimize resource allocation for data returning on the inverse path, such as bandwidth sharing, prioritization, and overload control. In current designs, this allocation is often done using Interest counting. By accepting one Interest packet from a downstream node, this implicitly provides a guarantee (either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send back one Data packet. A number of congestion control schemes have been developed for ICN that operate in this fashion, for example, [Wang2013], [Mahdian2016], [Song2018], and [Carofiglio2012]. Other schemes, like [Schneider2016], neither count nor police Interests but instead monitor queues using AQM (active queue management) to mark returning Data packets that have experienced congestion. This later class of schemes is similar to those used on IP in the sense that they depend on consumers adequately reducing their rate of Interest injection to avoid Data packet drops due to buffer overflow in forwarders. The former class of schemes is (arguably) more robust against misbehavior by consumers.
QoSに移動する前に、NDNまたはCCNXで輻輳制御がどのように機能するかを検討すると便利です。エンドツーエンドの輻輳制御（例：TCP [RFC0793]、DCCP [RFC4340]、SCTP [RFC4960]、およびQUIC [RFC9000]）に依存しているIPプロトコルファミリとは異なり、CCNXとNDNはホップバイを使用できます。 - ホップ輻輳制御パスのあらゆるホップに関心がない/データ状態があり、したがって優れた利益は帯域幅共有、優先順位付け、および過負荷制御などの逆経路に戻るデータのリソース割り当てを最適化するために使用できる情報を提供する。現在の設計では、この割り当ては利子カウントを使用して行われることがよくあります。ダウンストリームノードから1つの関心パケットを受け入れることによって、これは暗黙的に（ハードまたはソフト）を提供し、1つのデータパケットを送信するためのリンクの逆方向に十分な帯域幅があることを示します。このように動作するICNについては、例えば、[Wang2013]、[Mahdian2016]、[Song2018]、および[Carofiglio2012]などの輻輳制御方式が開発されてきた。 [Schneider2016]のような他の方式は、カウントも警察の関心もなく、代わりにAQM（アクティブキュー管理）を使用してキューを監視して、経験豊富なデータパケットを返します。この後のスキームクラスは、転送率のバッファオーバーフローによるデータパケットの降下を回避するために、それらが消費者に依存するという意味でIPで使用されるものと似ています。前者のスキームは、消費者によって不正行為に対して（おそらく）より堅牢です。
Given the stochastic nature of RTTs, and the ubiquity of wireless links and encapsulation tunnels with variable bandwidth, a simple scheme that admits Interests only based on a time-invariant estimate of the returning link bandwidth will perform poorly. However, two characteristics of NDN and CCNx-like protocols can help substantially to improve the accuracy and responsiveness of the bandwidth allocation:
RTTの確率的な性質、および可変帯域幅を有する無線リンクおよびカプセル化トンネルのユビキタ性を考えると、戻りリンク帯域幅の時間不変推定値に基づいて興味を認める単純な方式は不十分になります。しかしながら、NDNおよびCCNX様プロトコルの2つの特性は、帯域幅割り当ての正確さおよび応答性を実質的に改善するのを助けることができる。
1. RTT is bounded by the inclusion of an _Interest Lifetime_ in each Interest message, which puts an upper bound on the RTT uncertainty for any given Interest/Data exchange. If Interest Lifetimes are kept reasonably short (a few RTTs), the allocation of local forwarder resources do not have to deal with an arbitrarily long tail. One could in fact do a deterministic allocation on this basis, but the result would be highly pessimistic. Nevertheless, having a cutoff does improve the performance of an optimistic allocation scheme.
1. RTTは、各関心メッセージにおいて_interest lifetime_を含めることによって制限されます。金利の寿命が合理的に短く（数RTT）、ローカルフォワーダリソースの割り当ては任意の長い尾に対処する必要はありません。実際にはこの基礎上の決定論的割り当てを行うことができるが、結果は非常に悲観的であろう。それにもかかわらず、カットオフを有することは、楽観的割り当て方式の性能を向上させる。
2. A congestion marking scheme like that used in Explicit Congestion Notification (ECN) can be used to mark returning Data packets if the inverse link starts experiencing long queue occupancy or other congestion indication. Unlike TCP/IP, where the rate adjustment can only be done end-to-end, this feedback is usable immediately by the downstream ICN forwarder, and the Interest shaping rate is lowered after a single link RTT. This may allow rate adjustment schemes that are less pessimistic than the Additive Increase, Multiplicative Decrease (AIMD) scheme with .5 multiplier that is commonly used on TCP/IP networks. It also allows the rate adjustments to be spread more accurately among the Interest/Data flows traversing a link sending congestion signals.
2. 明示的な輻輳通知（ECN）で使用される輻輳マーキング方式を使用して、逆リンクが長いキューの占有率または他の輻輳表示を経験し始める場合にデータパケットを返すために使用できます。レート調整が終了しか実行できないTCP / IPとは異なり、このフィードバックはダウンストリームICNフォワーダによってすぐに使用可能であり、単一リンクRTTの後に関心整形率が低下する。これは、ADDIVEの増加よりも悲観的ではないレート調整方式で、TCP / IPネットワークで一般的に使用されている.5乗数を備えた。それはまた、輻輳信号を送信するリンクを横切る関心/データフローの間でより正確に速度調整をより正確に拡張することを可能にする。
A useful discussion of these properties and how they demonstrate the advantages of ICN approaches to congestion control can be found in [Carofiglio2016].
これらの特性の有用な議論と彼らが輻輳制御へのICNアプローチの利点をどのように実証するかについての議論は、[Carofiglio2016]にあります。
QoS is achieved through managed unfairness in the allocation of resources in network elements, particularly in the routers that forward ICN packets. Hence, the first-order questions are the following: Which resources need to be allocated? How do you ascertain which traffic gets those allocations? In the case of CCNx or NDN, the important network element resources are given in Table 2:
QoSは、特にICNパケットを転送するルータ内のネットワーク要素内のリソースの割り当てにおける管理された不当な性を介して達成されます。したがって、一次の質問は次のとおりです。どのリソースを割り当てる必要がありますか？どのトラフィックがそれらの割り当てを取得するかをどのように把握しますか？CCNXまたはNDNの場合、重要なネットワーク要素リソースは表2に示されています。
+=============================+===================================+
| Resource | ICN Usage |
+=============================+===================================+
| Communication link capacity | buffering for queued packets |
+-----------------------------+-----------------------------------+
| CS capacity | to hold cached data |
+-----------------------------+-----------------------------------+
| Forwarder memory | for the PIT |
+-----------------------------+-----------------------------------+
| Compute capacity | for forwarding packets, including |
| | the cost of FIB lookups |
+-----------------------------+-----------------------------------+
Table 2: ICN-Related Network Element Resources
表2：ICN関連のネットワーク要素リソース
For these resources, any QoS scheme has to specify two things:
これらのリソースの場合、任意のQoSスキームは2つのことを指定する必要があります。
1. How do you create _equivalence classes_ (a.k.a. flows) of traffic to which different QoS treatments are applied?
1. さまざまなQoS処理が適用されるトラフィックの_equivalenceクラス（a.k.a.flows）をどのように作成しますか？
2. What are the possible treatments and how are those mapped to the resource allocation algorithms?
2. 可能な治療法は何ですか、そしてそれらはリソース割り当てアルゴリズムにマッピングされているのでしょうか。
Two critical facts of life come into play when designing a QoS scheme. First, the number of equivalence classes that can be simultaneously tracked in a network element is bounded by both memory and processing capacity to do the necessary lookups. One can allow very fine-grained equivalence classes but not be able to employ them globally because of scaling limits of core routers. That means it is wise to either restrict the range of equivalence classes or allow them to be _aggregated_, trading off accuracy in policing traffic against ability to scale.
QoS方式を設計するときに、人生の2つの重大な事実が再生されます。第1に、ネットワーク要素で同時に追跡することができる等価クラスの数は、必要なルックアップを行うためにメモリと処理能力の両方によって制限されます。コアルータのスケーリング制限のため、非常にきめ細かい等価クラスを許可するが、それらをグローバルに採用することはできない。つまり、同等のクラスの範囲を制限するか、_Aggrgated_、スケール能力に対するポリシングトラフィックの正確さを取引することが賢明です。
Second, the flexibility of expressible treatments can be tightly constrained by both protocol encoding and algorithmic limitations. The ability to encode the treatment requests in the protocol can be limited -- as it is for IP where there are only six of the Type of Service (TOS) bits available for Diffserv treatments. However, an equal or more important issue is whether there are practical traffic policing, queuing, and pacing algorithms that can be combined to support a rich set of QoS treatments.
第二に、表現可能な治療の柔軟性は、プロトコル符号化とアルゴリズムの制限の両方によって厳密に制約され得る。プロトコル内の治療要求をエンコードする能力は制限される可能性があります - DIFFSERVトリートメントで利用可能なサービスの種類のうちの6つのみがあるIPのためのものです。しかしながら、等しいまたはそれ以上の重要な問題は、豊富なQoS処理のセットをサポートするために組み合わせることができる実用的なトラフィックポリシング、キューイング、およびペーシングアルゴリズムがあるかどうかである。
The two considerations above in combination can easily be substantially more expressive than what can be achieved in practice with the available number of queues on real network interfaces or the amount of per-packet computation needed to enqueue or dequeue a packet.
上記の2つの考慮事項は、実際のネットワークインターフェース上の利用可能なキュー数、またはパケットをエンキューまたはデキューするために必要なパケットごとの計算の量で実際に達成できるものよりも実質的に表現できるものよりも実質的に表現できます。
TCP/IP has fewer resource types to manage than ICN, and in some cases, the allocation methods are simpler, as shown in Table 3:
TCP / IPには、ICNより管理するためのリソースタイプが少なく、場合によっては、表3に示すように、割り当て方法が簡単です。
+===============+=============+================================+
| Resource | IP Relevant | TCP/IP Usage |
+===============+=============+================================+
| Communication | YES | buffering for queued packets |
| link capacity | | |
+---------------+-------------+--------------------------------+
| CS capacity | NO | no CS in IP |
+---------------+-------------+--------------------------------+
| Forwarder | MAYBE | not needed for output-buffered |
| memory | | designs (see note below) |
+---------------+-------------+--------------------------------+
| Compute | YES | for forwarding packets, but |
| capacity | | arguably much cheaper than ICN |
+---------------+-------------+--------------------------------+
Table 3: IP-Related Network Element Resources
表3：IP関連のネットワーク要素リソース
Note: In an output-buffered design, all packet buffering resources are associated with the output interfaces, and neither the receiver interface nor the internal forwarding buffers can be over-subscribed. Output-buffered switches or routers are common but not universal, as they generally require an internal speedup factor where forwarding capacity is greater than the sum of the input capacity of the interfaces.
注：出力バッファ設計では、すべてのパケットバッファリングリソースが出力インターフェイスに関連付けられ、受信側インタフェースも内部転送バッファもオーバーサブライブされていない可能性があります。出力バッファスイッチまたはルータは一般に、転送容量がインターフェイスの入力容量の合計よりも大きい内部スピードアップファクタを必要とするため、一般的なものではありません。
For these resources, IP has specified three fundamental things, as shown in Table 4:
これらのリソースの場合、表4に示すように、IPは3つの基本的なものを指定しました。
+=============+====================================================+
| What | How |
+=============+====================================================+
| Equivalence | subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT} |
| classes | SA=Source Address |
| | DA=Destination Address |
| | SP=Source Port |
| | DP=Destination Port |
| | PT=IP Protocol Type |
+-------------+----------------------------------------------------+
| Diffserv | (very) small number of globally-agreed traffic |
| treatments | classes |
+-------------+----------------------------------------------------+
| Intserv | per-flow parameterized _Controlled Load_ and |
| treatments | _Guaranteed_ service classes |
+-------------+----------------------------------------------------+
Table 4: Fundamental Protocol Elements to Achieve QoS for TCP/IP
表4：TCP / IP用のQoSを達成するための基本プロトコル要素
Equivalence classes for IP can be pairwise, by matching against both source and destination address+port, pure group using only destination address+port, or source-specific multicast with source address+port and destination multicast address+port.
IPの等価クラスは、ソースアドレスポートと宛先アドレスポート、宛先アドレスポートのみを使用して純粋なグループ、または送信元アドレスポートと送信先マルチキャストアドレスポートを使用してソース固有のマルチキャストの両方にマッチングすることによって、PAINISEにすることができます。
With Intserv, RSVP [RFC2205] carries two data structures: the Flow Specifier (FLOWSPEC) and the Traffic Specifier (TSPEC). The former fulfills the requirement to identify the equivalence class to which the QoS being signaled applies. The latter comprises the desired QoS treatment along with a description of the dynamic character of the traffic (e.g., average bandwidth and delay, peak bandwidth, etc.). Both of these encounter substantial scaling limits, which has meant that Intserv has historically been limited to confined topologies, and/or high-value usages, like traffic engineering.
INTSERVでは、RSVP [RFC2205]は2つのデータ構造を搭載しています。フロー指定子（FLOWSPEC）およびトラフィック指定子（TSPEC）。前者は、シグナリングされているQoSが適用される等価クラスを識別するための要件を満たします。後者は、トラフィックの動的文字（例えば、平均帯域幅および遅延、ピーク帯域幅など）の説明と共に所望のQoS処理を含む。これらの遭遇の両方の遭遇は、IntServが歴史的に限られたトポロジに限定されていたこと、および/または交通技術のような高価値の使用法があることを意味しています。
With Diffserv, the protocol encoding (six bits in the TOS field of the IP header) artificially limits the number of classes one can specify. These are documented in [RFC4594]. Nonetheless, when used with fine-grained equivalence classes, one still runs into limits on the number of queues required.
DIFFSEVERを使用すると、プロトコルエンコーディング（IPヘッダーのTOSフィールドの6ビット）は、指定できるクラスの数を明確に制限します。これらは[RFC4594]に文書化されています。それにもかかわらず、きめ細かい等価クラスで使用されると、それでも必要なキュー数の制限に依存します。
While one could adopt an approach to QoS that mirrors the extensive experience with TCP/IP, this would, in the author's view, be a mistake. The implementation and deployment of QoS in IP networks has been spotty at best. There are, of course, economic and political reasons as well as technical reasons for these mixed results, but there are several architectural choices in ICN that make it a potentially much better protocol base to enhance with QoS machinery. This section discusses those differences and their consequences.
TCP / IPで豊富な経験を乱すQoSへのアプローチを採用することはできますが、これは作者の見解では間違いになります。IPネットワークにおけるQoSの実装と展開は、最良の点で著に行われています。もちろん、経済的および政治的な理由とこれらの混在結果の技術的な理由があるが、ICNにはいくつかの建築選択があり、それがQoS機械を強化するための潜在的にはるかに優れたプロトコル基盤を作る。このセクションでは、それらの違いとその結果について説明します。
First and foremost, hierarchical names are a much richer basis for specifying equivalence classes than IP 5-tuples. The IP address (or prefix) can only separate traffic by topology to the granularity of hosts and cannot express actual computational instances nor sets of data. Ports give some degree of per-instance demultiplexing, but this tends to be both coarse and ephemeral, while confounding the demultiplexing function with the assignment of QoS treatments to particular subsets of the data. Some degree of finer granularity is possible with IPv6 by exploiting the ability to use up to 64 bits of address for classifying traffic. In fact, the Hybrid Information-Centric Networking (hICN) project [HICN], while adopting the request-response model of CCNx, uses IPv6 addresses as the available namespace, and IPv6 packets (plus "fake" TCP headers) as the wire format.
まず第一に、階層名はIP 5-Tuplesよりも等価クラスを指定するための多くの豊かな基礎です。IPアドレス（または接頭辞）は、トポロジによってトラフィックをホストの粒度に分離することができ、実際の計算インスタンスもデータセットを表現することはできません。ポートはある程度のインスタンスごとの逆多重化を与えますが、これは、データの特定のサブセットへのQoS処理の割り当てを使用して逆多重化関数を交絡しながら、粗大とエフェラルの両方である傾向があります。トラフィックを分類するために最大64ビットのアドレスを使用する能力を悪用することで、IPv6である程度の細かい粒度が可能です。実際、ハイブリッド情報中心のネットワーキング（HICN）プロジェクト[HICN]は、CCNXの要求応答モデルを採用しながら、IPv6アドレスを使用可能なネームスペース、およびIPv6パケット（プラス "偽の" TCPヘッダ）をワイヤフォーマットとして使用します。。
Nonetheless, the flexibility of tokenized (i.e., strings treated as opaque tokens), variable length, hierarchical names allows one to directly associate classes of traffic for QoS purposes with the structure of an application namespace. The classification can be as coarse or fine-grained as desired by the application. While not _always_ the case, there is typically a straightforward association between how objects are named and how they are grouped together for common treatment. Examples abound; a number can be conveniently found in [FLOWCLASS].
それにもかかわらず、トークン化されたトークン化の柔軟性（すなわち、不透明トークンとして扱われる文字列）、可変長の階層名では、QoS目的でトラフィックのクラスをアプリケーションネームスペースの構造に直接関連付けることができます。分類は、適用によって望まれるように粗いまたは粒微粒化することができる。_always_の場合は_always_は、通常、オブジェクトの名前とそれらが共通の扱いのためにどのようにグループ化されているかの間に簡単な関連付けがあります。例がたくさんあります。[フロークラス]には、数値を便利に見つけることができます。
In ICN, QoS is not pre-bound to network topology since names are non-topological, unlike unicast IP addresses. This allows QoS to be applied to multi-destination and multipath environments in a straightforward manner, rather than requiring either multicast with coarse class-based scheduling or complex signaling like that in RSVP Traffic Engineering (RSVP-TE) [RFC3209] that is needed to make point-to-multipoint Multiprotocol Label Switching (MPLS) work.
ICNでは、QoSはネットワークトポロジーにプリバインドされていません。名前は、ユニキャストIPアドレスとは異なり、名前は非トポロジです。これにより、RSVPトラフィックエンジニアリング（RSVP-TE）[RFC3209]のように、粗クラスベースのスケジューリングまたは複雑なシグナリングを使用して、QoSを多数の方法でQoSに適用することができます。ポイントツーマルチポイントマルチプロトコルラベルスイッチング（MPLS）作業を行います。
Because of IP's stateless forwarding model, complicated by the ubiquity of asymmetric routes, any flow-based QoS requires state that is decoupled from the actual arrival of traffic and hence must be maintained, at least as soft state, even during quiescent periods. Intserv, for example, requires flow signaling on the order of O(number of flows). ICN, even worst case, requires order of O(number of active Interest/Data exchanges), since state can be instantiated on arrival of an Interest and removed (perhaps lazily) once the data has been returned.
非対称経路のユビキタティによって複雑になるIPのステートレス転送モデルのために、任意のフローベースのQoSは、実際のトラフィックの到着から切り離されている状態を必要とし、したがって、静止期間中でさえも、少なくともソフト状態として維持されなければならない。たとえば、intServには、O of Oのオーダーでフローシグナリングが必要です（フロー数）。ICN、最悪の場合でも、状態が到着し、データが返されたら（おそらく遅延）、除去された（おそらく怠惰に）除去することができるので、最悪の場合はOの順序（積極的な関心/データ交換）が必要です。
Unlike Intserv, Diffserv eschews signaling in favor of class-based configuration of resources and queues in network elements. However, Diffserv limits traffic treatments to a few bits taken from the TOS field of IP. No such wire encoding limitations exist for NDN or CCNx, as the protocol is completely TLV (Type-Length-Value) based, and one (or even more than one) new field can be easily defined to carry QoS treatment information.
INTSERVとは異なり、DiffServは、ネットワーク要素のリソースのクラスベースの構成を支持してシグナリングをシグナリングします。ただし、DIFFSERVはIPのTOSフィールドから取られた数ビットにトラフィックトリートメントを制限します。プロトコルが完全にTLV（Type-Length-Value）に基づいているため、そのようなワイヤ符号化の制限は存在しません（タイプ長さ）、新しいフィールドはQoS治療情報を搬送するために簡単に定義できます。
Therefore, there are greenfield possibilities for more powerful QoS treatment options in ICN. For example, IP has no way to express a QoS treatment like "try hard to deliver reliably, even at the expense of delay or bandwidth". Such a QoS treatment for ICN could invoke native ICN mechanisms, none of which are present in IP, such as the following:
したがって、ICNでは、より強力なQoS治療オプションのためのグリーンフィールドの可能性があります。例えば、IPは、「遅延や帯域幅を犠牲にしても、確実に配信することを困難にすることを試みるように努力してください」のようなQoS治療を表現する方法はありません。ICNのそのようなQoS処理は、ネイティブICNメカニズムを呼び出すことができ、そのどちらもIPに存在しないため、次のようなIPに存在する可能性があります。
* Retransmitting in-network in response to hop-by-hop errors returned from upstream forwarders
* アップストリームフォワーダから返されたホップバイホップエラーに応答してネットワーク内インネットワークを再送信する
* Trying multiple paths to multiple content sources either in parallel or serially
* 並列または直列に複数のコンテンツソースへの複数のパスを試す
* Assigning higher precedence for short-term caching to recover from downstream (see note below) errors
* 下流から回復するための短期キャッシングの優先順位の高い割り当て（以下の注）エラー
* Coordinating cache utilization with forwarding resources
* 転送リソースとのキャッシュ使用率の調整
Note: _Downstream_ refers to the direction Data messages flow toward the consumer (the issuer of Interests). Conversely, _Upstream_ refers to the direction Interests flow toward the producer of data.
注：_downstream_は、消費者に向かって流れる方向データメッセージ（興味の発行者）を指します。逆に、_upstream_は、データのプロデューサへの方向への流れの流れを指します。
Such mechanisms are typically described in NDN and CCNx as _forwarding strategies_. However, there is little or no guidance for which application actions or protocol machinery a forwarder should use to select the appropriate forwarding strategy for arriving Interest messages. See [BenAbraham2018] for an investigation of these issues. Associating forwarding strategies with the equivalence classes and QoS treatments directly can make them more accessible and useful to implement and deploy.
そのようなメカニズムは、通常、NDNおよびCCNXとして_Forwiding Strategies_。ただし、対戦相手が到着するための適切な転送戦略を選択するために、アプリケーションの行動やプロトコル機械が使用する必要があるガイダンスはほとんどまたはまったくありません。これらの問題を調査するために[Benabraham2018]を参照してください。転送戦略の同等のクラスとQoS治療に直接関連付けることで、それらをより多くのアクセスしやすく、実装と展開することができます。
Stateless forwarding and asymmetric routing in IP limits available state/feedback to manage link resources. In contrast, NDN or CCNx forwarding allows all link resource allocation to occur as part of Interest forwarding, potentially simplifying things considerably. In particular, with symmetric routing, producers have no control over the paths their Data packets traverse; hence, any QoS treatments intended to influence routing paths from producer to consumer will have no effect.
IPのステートレス転送と非対称ルーティングは、リンクリソースを管理するために利用可能な状態/フィードバックを制限します。対照的に、NDNまたはCCNX転送により、すべてのリンクリソース割り当てが興味のある転送の一部として発生することができ、物事をかなり単純化することができます。特に、対称ルーティングでは、プロデューサはそれらのデータパケットがトラバースする経路を制御することはできません。したがって、プロデューサーから消費者へのルーティング経路に影響を与えることを目的としたQoS処理は効果がありません。
One complication in the handling of ICN QoS treatments is not present in IP and hence worth mentioning. CCNx and NDN both perform _Interest aggregation_ (see Section 2.4.2 of [RFC8569]). If an Interest arrives matching an existing PIT entry, but with a different QoS treatment from an Interest already forwarded, it can be tricky to decide whether to aggregate the Interest or forward it, and how to keep track of the differing QoS treatments for the two Interests. Exploration of the details surrounding these situations is beyond the scope of this document; further discussion can be found for the general case of flow balance and congestion control in [FLOWBALANCE] and specifically for QoS treatments in [DNC-QOS-ICN].
ICN QoS処理の取り扱いにおける一方の合併症はIPには存在せず、したがって言及する価値があります。CCNXとNDNはどちらも_interest Aggregation_を実行します（[RFC8569]のセクション2.4.2を参照）。興味が既存のPITエントリーに一致しているが、すでに転送された興味から異なるQoS治療を伴う場合、それは興味を集約するか、そして2つのために異なるQoSトリートメントを追跡する方法を決定するのは難しいことがある。興味。これらの状況を囲む詳細の探査はこの文書の範囲を超えています。[フローバランス]、特に[DNC-QoS-ICN]のQoS処理のためのフローバランスおよび輻輳制御の一般的なケースについては、さらなる議論が見られる。
IP has three forwarding semantics, with different QoS needs (Unicast, Anycast, Multicast). ICN has the single forwarding semantic, so any QoS machinery can be uniformly applied across any request/response invocation. This applies whether the forwarder employs dynamic destination routing, multi-destination forwarding with next hops tried serially, multi-destination with next hops used in parallel, or even localized flooding (e.g., directly on Layer 2 multicast mechanisms). Additionally, the pull-based model of ICN avoids a number of thorny multicast QoS problems that IP has (see [Wang2000], [RFC3170], and [Tseng2003]).
IPには3つの転送セマンティクスがあり、さまざまなQoSニーズ（ユニキャスト、Anycast、マルチキャスト）があります。ICNは単一の転送意味を持ち、そのため、任意のQoS機械類を任意の要求/応答呼び出しにわたって一様に適用できます。これは動的宛先ルーティングを使用しているかどうか適用されます。次のホップを使用したマルチ宛先の転送は、並行して使用されている次のホップ、あるいはローカライズされたフラッディングでさえ（例えば、レイヤ2マルチキャストメカニズム上で）直列にマルチデスを試行しました。さらに、ICNのプルベースのモデルは、IPが持つという点にあります（[wang2000]、[RFC3170]、[TSENG2003]を参照）。
The Multi-destination/multipath forwarding model in ICN changes resource allocation needs in a fairly deep way. IP treats all endpoints as open-loop packet sources, whereas NDN and CCNx have strong asymmetry between producers and consumers as packet sources.
ICNにおけるマルチデスティネーション/マルチパス転送モデルは、リソース割り当てのニーズをかなり深い方法で変更します。IPはすべてのエンドポイントをオープンループパケットソースとして扱いますが、NDNとCCNXはプロデューサとコンシューマの間の強い非対称性をパケットソースとして持ちます。
IP has no caching in routers, whereas ICN needs ways to allocate cache resources. Treatments to control caching operation are unlikely to look much like the treatments used to control link resources. NDN and CCNx already have useful cache control directives associated with Data messages. The CCNx controls include the following:
IPにはルータにキャッシュがないが、ICNはキャッシュリソースを割り当てる方法を必要とします。キャッシング操作を制御するための治療は、リンクリソースを制御するために使用される治療法のように見える可能性は低いです。NDNとCCNXはすでにデータメッセージに関連付けられている便利なキャッシュ制御ディレクティブを持っています。CCNXコントロールには次のものがあります。
ExpiryTime: time after which a cached Content Object is considered expired and MUST no longer be used to respond to an Interest from a cache.
expiryTime：キャッシュされたコンテンツオブジェクトが期限切れと見なされ、キャッシュからの関心に応答するために使用されなくなる必要があります。
Recommended Cache Time: time after which the publisher considers the Content Object to be of low value to cache.
推奨キャッシュ時間：パブリッシャがContentオブジェクトをキャッシュに低い値にすると考える時間。
See [RFC8569] for the formal definitions.
正式な定義については[RFC8569]を参照してください。
ICN flow classifiers, such as those in [FLOWCLASS] can be used to achieve soft or hard partitioning (see note below) of cache resources in the CS of an ICN forwarder. For example, cached content for a given equivalence class can be considered _fate shared_ in a cache whereby objects from the same equivalence class can be purged as a group rather than individually. This can recover cache space more quickly and at lower overhead than pure per-object replacement when a cache is under extreme pressure and in danger of thrashing. In addition, since the forwarder remembers the QoS treatment for each pending Interest in its PIT, the above cache controls can be augmented by policy to prefer retention of cached content for some equivalence classes as part of the cache replacement algorithm.
[FlowClass]内のICNフロー分類器は、ICNフォワーダのCS内のキャッシュリソースのソフトまたはハードパーティション化（以下の注）を実現するために使用できます。たとえば、特定の等価クラスのキャッシュされたコンテンツは、同じ等価クラスのオブジェクトを個別にはなくグループとしてパージすることができるキャッシュ内の_fate shared_と見なすことができます。これは、キャッシュが極端な圧力の下でスラッシングの危険性がある場合よりも純粋なオブジェクトの交換よりも迅速かつ低いオーバーヘッドでキャッシュスペースを回復できます。さらに、フォワーダはそのピットに対処するたびにQoS治療を覚えているので、キャッシュ交換アルゴリズムの一部として、いくつかの等価クラスのキャッシュされたコンテンツの保持を好むためのポリシーによって上記のキャッシュコントロールを強化することができる。
Note: With hard partitioning, there are dedicated cache resources for each equivalence class (or enumerated list of equivalence classes). With soft partitioning, resources are at least partly shared among the (sets of) equivalence classes of traffic.
注：ハードパーティション化では、各同値クラス（または列挙型の等価クラスのリスト）に対して専用のキャッシュリソースがあります。ソフトパーティショニングでは、リソースはトラフィックの同値クラスの（一連の）同値クラスの間で少なくとも部分的に共有されています。
Based on the observations made in the earlier sections, this summary section captures the author's ideas for clear and actionable architectural principles for incorporating QoS machinery into ICN protocols like NDN and CCNx. Hopefully, they can guide further work and focus effort on portions of the giant design space for QoS that have the best trade-offs in terms of flexibility, simplicity, and deployability.
以前のセクションで行われた観察結果に基づいて、この概要セクションは、QoS機械をNDNとCCNXのようなICNプロトコルに組み込むための明確かつ実用的なアーキテクチャ原則のための著者のアイデアを捉えています。うまくいけば、彼らは柔軟性、単純さ、および展開可能性の観点から、最良のトレードオフを持つQoSのための巨大な設計スペースの一部にさらなる仕事を導くことができます。
*Define equivalence classes using the name hierarchy rather than creating an independent traffic class definition*. This directly associates the specification of equivalence classes of traffic with the structure of the application namespace. It can allow hierarchical decomposition of equivalence classes in a natural way because of the way hierarchical ICN names are constructed. Two practical mechanisms are presented in [FLOWCLASS] with different trade-offs between security and the ability to aggregate flows. Either the prefix-based mechanism (the equivalence class component count (EC3) scheme) or the explicit name component-based mechanism (the equivalence class name component type (ECNCT) scheme), or both, could be adopted as the part of the QoS architecture for defining equivalence classes.
*独立したトラフィッククラス定義を作成するのではなく、名前階層を使用して等価クラスを定義します。これにより、トラフィックの同値クラスの指定をアプリケーションネームスペースの構造と直接関連付けます。階層ICN名が構築されている方法のために、それは自然な方法で等価クラスの階層的な分解を可能にすることができます。セキュリティとフローを集約する能力との間の異なるトレードオフを持つ2つの実用的なメカニズムが[FlowClass]に表示されます。プレフィックスベースのメカニズム（等価クラスコンポーネントカウント（EC3）方式）または明示的な名前コンポーネントベースのメカニズム（等価クラス名コンポーネントタイプ（ECNCT）方式）、またはその両方をQoSの一部として採用することができます。等価クラスを定義するためのアーキテクチャ。
*Put consumers in control of link and forwarding resource allocation*. Base all link buffering and forwarding (both memory and CPU) resource allocations on Interest arrivals. This is attractive because it provides early congestion feedback to consumers and allows scheduling the reverse link direction for carrying the matching data in advance. It makes enforcement of QoS treatments a single-ended (i.e., at the consumer) rather than a double-ended problem and can avoid wasting resources on fetching data that will be dropped when it arrives at a bottleneck link.
*消費者をリンクと転送リソース割り当て*の制御に挿入します。関心のあるすべてのリンクバッファリングと転送（メモリとCPUの両方）リソース割り当てに到着します。これは消費者に早期の輻輳フィードバックを提供し、一致するデータを事前に運ぶための逆方向リンク方向をスケジュールすることを可能にするので魅力的です。それはQoS処理の執行を二重終了の問題ではなくシングルエンド（すなわち消費者で）を執行することで、それがボトルネックリンクに到着したときにドロップされるデータの取得上のリソースの無駄を避けることができます。
*Allow producers to influence the allocation of cache resources*. Producers want to affect caching decisions in order to do the following:
*プロデューサーがキャッシュリソースの割り当てに影響を与える*。プロデューサーは、次のことを行うために決定の決定に影響を与えたいです。
* Shed load by having Interests served by CSes in forwarders before they reach the producer itself
* プロデューサー自体に到達する前に、運送業者のCSEが提供していることによる荷物を小屋
* Survive transient producer reachability or link outages close to the producer
* 生産者に近い過渡生産者の到達可能性またはリンク停止を生き残る
For caching to be effective, individual Data objects in an equivalence class need to have similar treatment; otherwise, well-known cache-thrashing pathologies due to self-interference emerge. Producers have the most direct control over caching policies through the caching directives in Data messages. It therefore makes sense to put the producer, rather than the consumer or network operator, in charge of specifying these equivalence classes.
キャッシングが有効であるためには、同等のクラスの個々のデータオブジェクトが同様の扱いをする必要があります。それ以外の場合は、自己干渉のためによく知られているキャッシュスラッシングの病理が浮上します。プロデューサは、データメッセージのキャッシングディレクティブを通るキャッシングポリシーを最も直接制御します。したがって、これらの等価クラスを指定することを担当する、プロデューサーをコンシューマまたはネットワーク事業者ではなく、プロデューサーを配置することを意味します。
See [FLOWCLASS] for specific mechanisms to achieve this.
これを達成するための特定のメカニズムの[FlowClass]を参照してください。
*Allow consumers to influence the allocation of cache resources*. Consumers want to affect caching decisions in order to do the following:
*消費者がキャッシュリソースの割り当てに影響を与えることを許可します*。消費者は次のことを実行するためにキャッシュ決定に影響を与えたいと考えています。
* Reduce latency for retrieving data
* データを取得するための待ち時間を短縮してください
* Survive transient outages of either a producer or links close to the consumer
* プロデューサーまたは消費者の近くのリンクの一時的な停止を生き残る
Consumers can have indirect control over caching by specifying QoS treatments in their Interests. Consider the following potential QoS treatments by consumers that can drive caching policies:
消費者は、興味のQoS治療法を指定することによって、キャッシングを間接的に制御することができます。キャッシングポリシーを駆動できる消費者による次の潜在的なQoS治療を考慮してください。
* A QoS treatment requesting better robustness against transient disconnection can be used by a forwarder close to the consumer (or downstream of an unreliable link) to preferentially cache the corresponding data.
* 一時的な切断に対してより良い堅牢性を要求するQoS処理は、対応するデータを優先的にキャッシュするために消費者（または信頼性の低いリンクの下流）の近くでフォワーダによって使用され得る。
* Conversely, a QoS treatment together with, or in addition to, a request for short latency indicating that the forwarder should only pay attention to the caching preferences of the producer because caching requested data would be ineffective (i.e., new data will be requested shortly).
* 逆に、要求されたデータをキャッシングすることが無効であるため、ローダーがプロデューサーのキャッシュ環境設定に注意を払うべきであることを示す短期間の要求とともに、短期間の要求と一緒に、またはそれに加えて、運送業者がプロデューサーのキャッシング設定に注意を払うべきであることを示す（すなわち、新しいデータが間もなく要求されます）。。
* A QoS treatment indicating that a mobile consumer will likely incur a mobility event within an RTT (or a few RTTs). Such a treatment would allow a mobile network operator to preferentially cache the data at a forwarder positioned at a _join point_ or _rendezvous point_ of their topology.
* モバイル消費者がRTT（または数RTT）内でモビリティイベントを発生させる可能性があることを示すQoS治療。そのような治療は、モバイルネットワーク事業者がそれらのトポロジの_join Point_または_Rendezvous Point_で位置決めされたフォワーダでデータを優先的にキャッシュすることを可能にするであろう。
*Give network operators the ability to match customer SLAs to cache resource availability*. Network operators, whether closely tied administratively to producer or consumer, or constituting an independent transit administration, provide the storage resources in the ICN forwarders. Therefore, they are the ultimate arbiters of how the cache resources are managed. In addition to any local policies they may enforce, the cache behavior from the QoS standpoint emerges from the mapping of producer-specified equivalence classes onto cache space availability, including whether cache entries are treated individually or fate-shared. Forwarders also determine the mapping of consumer-specified QoS treatments to the precedence used for retaining Data objects in the cache.
*ネットワーク事業者に、顧客SLAをキャッシュリソースの可用性をキャッシュする機能*。ネットワーク事業者は、プロデューサまたはコンシューマに管理上、または独立した通過管理を構成するかどうか、またはICNフォワーダにストレージリソースを提供します。したがって、それらはキャッシュリソースの管理方法の究極のアービターです。それらが強制することができるローカルポリシーに加えて、QoSのスタンドポイントからのキャッシュ動作は、キャッシュエントリが個別にまたはFate-Sharedのどちらで扱われるかどうかを含む、プロデューサ指定の等価クラスのマッピングからキャッシュスペースの可用性へのマッピングから発生します。フォワーダは、キャッシュ内のデータオブジェクトを保持するために使用される優先順位までの消費者指定のQoSトリートメントのマッピングも決定します。
Besides utilizing cache resources to meet the QoS goals of individual producers and consumers, network operators also want to manage their cache resources in order to do the following:
キャッシュリソースを利用して、個々のプロデューサと消費者のQoSの目標を達成するために、ネットワーク事業者は次のことを実行するためにキャッシュリソースを管理したいと考えています。
* Ameliorate congestion hotspots by reducing load converging on producers they host on their network
* 彼らのネットワーク上でホストするプロデューサに収束する負荷を減らすことによって輻輳ホットスポットを改善する
* Improve Interest satisfaction rates by utilizing caches as short-term retransmission buffers to recover from transient producer reachability problems, link errors, or link outages
* 一時的なプロデューサーの到達可能性の問題、リンクエラー、またはリンク停止から回復するための短期再送信バッファとしてのキャッシュを利用することによって利益満足度を向上させる
* Improve both latency and reliability in environments when consumers are mobile in the operator's topology
* オペレータのトポロジの消費者が携帯である場合の環境の待ち時間と信頼性の両方を向上させる
*Rethink how to specify traffic treatments -- don't just copy Diffserv*. Some of the Diffserv classes may form a good starting point, as their mappings onto queuing algorithms for managing link buffering are well understood. However, Diffserv alone does not capture more complex QoS treatments, such as:
*トラフィックトリートメントの指定方法 - DiffServ *をコピーするだけではありません。リンクバッファリングを管理するためのキューイングアルゴリズムに対するそれらのマッピングがよく理解されるので、いくつかのDiffServクラスは良い出発点を形成するかもしれません。ただし、DiffServだけでは、次のようなより複雑なQoSトリートメントを捕捉しません。
* Trading off latency against reliability
* 信頼性に対する待ち時間を取引する
* Trading off resource usage against delivery probability through controlled flooding or other forwarding mechanisms
* 制御された洪水や他の転送メカニズムによる配達確率に対するリソース使用量の取引
* Allocating resources based on rich TSPEC-like traffic descriptions that appear in signaled QoS schemes like Intserv
* INTSERVのようなシグナリングQoSスキームに表示されるリッチなTSPECのようなトラフィック記述に基づいてリソースの割り当て
Here are some examples:
ここではいくつかの例を示します。
* A "burst" treatment, where an initial Interest gives an aggregate data size to request allocation of link capacity for a large burst of Interest/Data exchanges. The Interest can be rejected at any hop if the resources are not available. Such a treatment can also accommodate Data implosion produced by the discovery procedures of management protocols like [CCNINFO].
* 初期の関心がある「バースト」治療は、関心のある関心/データ交換のためのリンク容量の割り当てを要求するために集約データサイズを与える。リソースが利用できない場合は、任意のホップで任意のホップで拒否できます。そのような治療はまた、[CCNInfo]のような管理プロトコルの発見手順によって生成されたデータ爆縮にも適応することができる。
* A "reliable" treatment, which affects preference for allocation of PIT space for the Interest and CS space for the Data in order to improve the robustness of IoT data delivery in a constrained environment, as is described in [IOTQOS].
* 「IOTQOS」に記載されているように、制約付き環境でのIOTデータ配信の堅牢性を向上させるために、データのための利息およびCSスペースの割り当てのための「信頼できる」治療。
* A "search" treatment, which, within the specified Interest Lifetime, tries many paths either in parallel or serially to potentially many content sources, to maximize the probability that the requested item will be found. This is done at the expense of the extra bandwidth of both forwarding Interests and receiving multiple responses upstream of an aggregation point. The treatment can encode a value expressing trade-offs like breadth-first versus depth-first search, and bounds on the total resource expenditure. Such a treatment would be useful for instrumentation protocols like [ICNTRACEROUTE].
* 指定された金利の有効期間内にある「検索」治療は、要求されたアイテムが見つかった可能性を最大にするために、潜在的に多くのコンテンツソースに並行してまたは直列に多くのパスを試みます。これは、転送興味の両方の帯域幅を犠牲にし、集計点の上流の複数の応答を受信します。この治療は、幅優先探索のような幅優先探索のようなトレードオフを表す値を符号化することができ、そして総リソース支出の境界。そのような治療は、[Icntraceroute]のような計装プロトコルに役立ちます。
| As an aside, loose latency control (on the order of seconds or
| tens of milliseconds as opposed milliseconds or microseconds)
| can be achieved by bounding Interest Lifetime as long as this
| lifetime machinery is not also used as an application mechanism
| to provide subscriptions or to establish path traces for
| producer mobility. See [Krol2018] for a discussion of the
| network versus application timescale issues in ICN protocols.
7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS Semantics?
7.1. ICNのINTSERVのようなトラフィックコントロールは豊かなQoSセマンティクスを提供できますか？
Basic QoS treatments such as those summarized above may not be adequate to cover the whole range of application utility functions and deployment environments we expect for ICN. While it is true that one does not necessarily need a separate signaling protocol like RSVP given the state carried in the ICN data plane by forwarders, simple QoS treatments applied per Interest/Data exchanges lack some potentially important capabilities. Intserv's richer QoS capabilities may be of value, especially if they can be provided in ICN at lower complexity and protocol overhead than Intserv plus RSVP.
上記のもののような基本的なQoS処理は、ICNに期待されるアプリケーションユーティリティ機能および展開環境の全範囲をカバーするのに十分ではないかもしれません。FORFORDERSによってICNデータプレーンで運ばれる状態を考慮してRSVPのような別のシグナリングプロトコルを必要としないのは、必ずしもRSVPのような別のシグナリングプロトコルを必要としないが、関心/データ交換ごとに適用される単純なQoSトリートメントは、いくつかの潜在的に重要な機能を欠いている。IntServの豊富なQoS機能は、特にICNでINTSERSとRSVPよりも低い複雑さとプロトコルオーバーヘッドで提供できる場合は、値のものである可能性があります。
There are three key capabilities missing from Diffserv-like QoS treatments, no matter how sophisticated they may be in describing the desired treatment for a given equivalence class of traffic. Intserv-like QoS provides all of these:
与えられた等価クラスのトラフィックのための所望の治療法をどのように記述することができるかにかかわらず、DiffServのようなQoS治療から3つの重要な機能が欠けている。IntServのようなQoSはこれらすべてを提供します。
1. The ability to *describe traffic flows* in a mathematically meaningful way. This is done through parameters like average rate, peak rate, and maximum burst size. The parameters are encapsulated in a data structure called a "TSPEC", which can be placed in whatever protocol needs the information (in the case of TCP/IP Intserv, this is RSVP).
1. *トラフィックフロー*を数学的に意味のある方法で説明する能力。これは、平均レート、ピークレート、最大バーストサイズなどのパラメータを介して行われます。パラメータは「TSPEC」と呼ばれるデータ構造にカプセル化されています。これは、情報を必要とするプロトコルにはどのプロトコルが必要です（TCP / IP INTSERVの場合はこれがRSVPです）。
2. The ability to perform *admission control*, where the element requesting the QoS treatment can know _before_ introducing traffic whether the network elements have agreed to provide the requested traffic treatment. An important side effect of providing this assurance is that the network elements install state that allows the forwarding and queuing machinery to police and shape the traffic in a way that provides a sufficient degree of _isolation_ from the dynamic behavior of other traffic. Depending on the admission-control mechanism, it may or may not be possible to explicitly release that state when the application no longer needs the QoS treatment.
2. QoS処理を要求する要素が、ネットワーク要素が要求されたトラフィック処理を提供することに合意したかどうかをQuece_Beforeを紹介することができる、* Addission Control *を実行する機能。この保証を提供するという重要な副作用は、ネットワーク要素が、他のトラフィックの動的挙動から十分な程度の_isolation_を提供する方法でトラフィックを警察およびキューイングすることを可能にする状態をインストールすることです。入学制御メカニズムに応じて、アプリケーションがQoS治療を必要としなくなったときに明示的に解放することができない場合があります。
3. The ability to specify the permissible *degree of divergence* in the actual traffic handling from the requested handling. Intserv provides two choices here: the _controlled load_ service and the _guaranteed_ service. The former allows stochastic deviation equivalent to what one would experience on an unloaded path of a packet network. The latter conforms to the TSPEC deterministically, at the obvious expense of demanding extremely conservative resource allocation.
3. 要求された処理からの実際のトラフィック処理において、許容される*二乗度*を指定する機能。IntServはここで2つの選択肢を提供します。_controlled load_サービスと_guaranteed_サービス。前者は、パケットネットワークのアンロードされた経路で経験するものと同等の確率偏差を可能にする。後者はTSPECに決定されていますが、非常に保守的なリソース割り当ての厳しい費用の明らかな費用で。
Given the limited applicability of these capabilities in today's Internet, the author does not take any position as to whether any of these Intserv-like capabilities are needed for ICN to be successful. However, a few things seem important to consider. The following paragraphs speculate about the consequences of incorporating these features into the CCNx or NDN protocol architectures.
今日のインターネットにおけるこれらの機能の限られた適用性を考えると、著者はICNが成功するためにこれらのINTSERVのような機能のいずれかが必要かどうかに関してはどのような立場にもかかりません。しかし、考慮することが重要に見えることがいくつかあります。次の段落は、これらの機能をCCNXまたはNDNプロトコルアーキテクチャに組み込むことの結果について推測します。
Superficially, it would be quite straightforward to accommodate Intserv-equivalent traffic descriptions in CCNx or NDN. One could define a new TLV for the Interest message to carry a TSPEC. A forwarder encountering this, together with a QoS treatment request (e.g., as proposed in Section 6.3), could associate the traffic specification with the corresponding equivalence class derived from the name in the Interest. This would allow the forwarder to create state that not only would apply to the returning Data for that Interest when being queued on the downstream interface but also be maintained as soft state across multiple Interest/Data exchanges to drive policing and shaping algorithms at per-flow granularity. The cost in Interest message overhead would be modest; however, the complications associated with managing different traffic specifications in different Interests for the same equivalence class might be substantial. Of course, all the scalability considerations with maintaining per-flow state also come into play.
超微妙には、CCNXまたはNDNのINTSERVに同等のトラフィック記述を収容することは非常に簡単です。 TSPECを運ぶために興味メッセージのための新しいTLVを定義することができます。これに遭遇したフォワーダは、QoS処理要求（例えば、セクション6.3で提案されているように）と共に、トラフィック仕様を、関心のある名前から派生した対応する等価クラスと関連付けることができる。これにより、フォワーダは、ダウンストリームインタフェースでキューに入れられたときにその興味のための返却データに適用されるだけでなく、ポリシングとシェーピングアルゴリズムを駆動するための柔らかい状態として維持される状態を作成することができます。粒状性。関心のあるコストは、メッセージオーバーヘッドが控えめになるでしょう。しかしながら、同じ等価クラスに対する異なる興味において異なるトラフィック仕様を管理することに関連する複雑さはかなりのものかもしれない。もちろん、フローごとの状態を維持することでのスケーラビリティ上の考慮事項もすべて再生されます。
Similarly, it would be equally straightforward to have a way to express the degree of divergence capability that Intserv provides through its controlled load and guaranteed service definitions. This could either be packaged with the traffic specification or encoded separately.
同様に、INTSERVが制御された負荷および保証されたサービス定義を通じて提供する乖離能力の程度を表現する方法を持つことが同様に簡単になります。これは、トラフィック仕様でパッケージ化されるか、別々にエンコードされる可能性があります。
In contrast to the above, performing admission control for ICN flows is likely to be just as heavyweight as it is with IP using RSVP. The dynamic multipath, multi-destination forwarding model of ICN makes performing admission control particularly tricky. Just to illustrate:
上記とは対照的に、ICNフローのための入学制御を行うことは、RSVPを使用してIPと同じように重量のようになる可能性があります。ICNのダイナミックマルチパス、マルチデスティネーション転送モデルは、特にトリッキーを実行することを実行する。説明するためだけに：
* Forwarding next-hop selection is not confined to single paths (or a few ECMP equivalent paths) as it is with IP, making it difficult to know where to install state in advance of the arrival of an Interest to forward.
* フォワーティングネクストホップ選択は、IPとのように単一のパス（または数少ないECMP等価経路）に限定されず、前向きの到着の到着前にどこにインストールするかを知ることは困難です。
* As with point-to-multipoint complexities when using RSVP for MPLS-TE, state has to be installed to multiple producers over multiple paths before an admission-control algorithm can commit the resources and say "yes" to a consumer needing admission-control capabilities.
* MPLS-TEのRSVPを使用する場合のポイントツーマルチポイントの複雑さと同様に、アドミッションコントロールアルゴリズムがリソースをコミットする前に、複数のパスを介して複数のプロデューサにインストールする必要があります。。
* Knowing when to remove admission-control state is difficult in the absence of a heavyweight resource reservation protocol. Soft state timeout may or may not be an adequate answer.
* Advision-Control Stateを除去する場合を知ることは、ヘビー級リソース予約プロトコルがない場合に困難です。ソフトステートタイムアウトが適切な答えである場合やすることはできません。
Despite the challenges above, it may be possible to craft an admission-control scheme for ICN that achieves the desired QoS goals of applications without the invention and deployment of a complex, separate admission-control signaling protocol. There have been designs in earlier network architectures that were capable of performing admission control piggybacked on packet transmission.
上記の課題にもかかわらず、本発明を除いて、任意のQoSアプリケーションの目標と複雑な分離制御シグナリングプロトコルの展開を達成するICNのための入学制御方式を作ることが可能であり得る。パケット伝送でPIGGYBACKED PIGGYBACKEDを実行することができる以前のネットワークアーキテクチャで設計が行われています。
| The earliest example the author is aware of is [Autonet].
| ..著者は、著者が知っているのが[自動ネット]です。
Such a scheme might have the following general shape (*warning:* serious hand-waving follows!):
そのような方式は、以下の一般的な形状を持つかもしれません（*警告：*深刻なハンドウをはじく！）：
* In addition to a QoS treatment and a traffic specification, an Interest requesting admission for the corresponding equivalence class would indicate this via a new TLV. It would also need to do the following: (a) indicate an expiration time after which any reserved resources can be released, and (b) indicate that caches be bypassed, so that the admission-control request arrives at a bona fide producer.
* QoS治療とトラフィック仕様に加えて、対応する等価クラスに対する入場を要求する興味はこれを新しいTLV経由で示すであろう。（a）予約されたリソースが解放される可能性がある後の有効期限を示し、（b）はキャッシュがバイパスされることを示しているので、入学制御要求はBONA FIDEプロデューサに到着するようにします。
* Each forwarder processing the Interest would check for resource availability. If the resources are not available, or the requested service is not feasible, the forwarder would reject the Interest with an admission-control failure. If resources are available, the forwarder would record the traffic specification as described above and forward the Interest.
* 関心のある各フォワーダ処理は、リソースの可用性をチェックします。リソースが利用できない場合、または要求されたサービスが実行不可能な場合、転送先はアドミッションコントロールの失敗に興味を拒否します。リソースが利用可能な場合、フォワーダは上記のようにトラフィック指定を記録し、関心を転送します。
* If the Interest successfully arrives at a producer, the producer would return the requested Data.
* 興味が生産者にうまく到着した場合、プロデューサは要求されたデータを返します。
* Upon receiving the matching Data message and if the resources are still available, each on-path forwarder would allocate resources and would mark the admission control TLV as "provisionally approved". Conversely, if the resource reservation fails, the admission control would be marked "failed", although the Data would still be passed downstream.
* 一致するデータメッセージを受信すると、リソースがまだ利用可能である場合、各経路フォワーダはリソースを割り当て、アドミッションコントロールTLVを「仮承認」としてマークする。逆に、リソース予約が失敗した場合、アドミッションコントロールは「失敗」とマークされますが、データは依然として下流に渡されます。
* Upon the Data message arrival, the consumer would know if admission succeeded or not, and subsequent Interests could rely on the QoS state being in place until either some failure occurs, or a topology or other forwarding change alters the forwarding path. To deal with this, additional machinery is needed to ensure subsequent Interests for an admitted flow either follow that path or an error is reported. One possibility (also useful in many other contexts), is to employ a _Path Steering_ mechanism, such as the one described in [Moiseenko2017].
* データメッセージ到着時に、消費者は、承認が成功したかどうかを知っていて、その後の障害が発生するか、またはトポロジや他の転送変更が転送経路を変更するまでQoS状態に依存する可能性があるかどうかを知っています。これに対処するために、入院した流れに対する後続の利益を確実にするために追加の機械が必要とされています。そのパスまたはエラーが報告されます。1つの可能性（他の多くのコンテキストでも有用な）は、[Moiseenko2017]に記載されているものなどの_Path Steering_メカニズムを使用することです。
This document has no IANA actions.
この文書にはIANAの行動がありません。
There are a few ways in which QoS for ICN interacts with security and privacy issues. Since QoS addresses relationships among traffic rather than the inherent characteristics of traffic, it neither enhances nor degrades the security and privacy properties of the data being carried, as long as the machinery does not alter or otherwise compromise the basic security properties of the associated protocols. The QoS approaches advocated here for ICN can serve to amplify existing threats to network traffic. However:
ICNのQoSがセキュリティとプライバシーの問題と対話する方法はいくつかあります。QoSはトラフィックの固有の特性ではなく、トラフィック間の関係に対処しているので、マシンが関連付けられているプロトコルの基本的なセキュリティプロパティを変更しないか、またはそうでなければ、実行されているデータのセキュリティおよびプライバシープロパティも強化も低下させることはできません。ICNのためにここに提唱されているQoSアプローチは、既存の脅威をネットワークトラフィックに増幅するのに役立ちます。しかしながら：
* An attacker able to manipulate the QoS treatments of traffic can mount a more focused (and potentially more effective) denial-of-service attack by suppressing performance on traffic the attacker is targeting. Since the architecture here assumes QoS treatments are manipulatable hop-by-hop, any on-path adversary can wreak havoc. Note, however, that in basic ICN, an on-path attacker can do this and more by dropping, delaying, or misrouting traffic independent of any particular QoS machinery in use.
* トラフィックのQoS処理を操作することができる攻撃者は、攻撃者がターゲティングしているトラフィックのパフォーマンスを抑制することによって、より焦点を尽くし（そして潜在的に効果的に効果的な）サービス拒否攻撃を取り付けることができます。ここでのアーキテクチャはQoSトリートメントを想定しているので、操作可能なホップバイホップであると仮定していますが、ON-PATHの敵は大惨事を覚えています。ただし、基本的なICNでは、使用中の特定のQoS機械類とは無関係のトラフィックをドロップ、遅延、または誤表示することによって、オンパス攻撃者がこれを行うことができます。
* When equivalence classes of traffic are explicitly revealed via either names or other fields in packets, an attacker has yet one more handle to use to discover linkability of multiple requests.
* 同値クラスのトラフィックがパケット内の名前または他のフィールドを介して明示的に明らかにされると、攻撃者はまだ複数の要求のリンク可能性を発見するために使用するもう1つのハンドルを持っています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569] Mosko、M.、Solis、I.、およびC. Wood、 "Content-Centric Networking（CCNX）セマンティクス"、RFC 8569、DOI 10.17487 / RFC8569、2019年7月、<https：//www.rfc-編集者.ORG / INFO / RFC8569>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko、M.、Solis、I。、およびC.木材、「TLV形式のコンテンツ中心ネットワーキング（CCNX）メッセージ」、RFC 8609、DOI 10.17487 / RFC8609、2019年7月、<https：// www。rfc-editor.org/info/rfc8609>。
[AS] Wikipedia, "Autonomous system (Internet)", May 2021, <https://en.wikipedia.org/w/index.php?title=Autonomous_sys tem_(Internet)&oldid=1025244754>.
[AS] Wikipedia、「自律システム（インターネット）」、2021年5月、<https：//en.wikipedia.org/w/index.php?title=autonomous_sys tem_（インターネット）＆oldid = 1025244754>。
[Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks", in IEEE Transactions on Network and Service Management, Vol. 15, No. 2, DOI 10.1109/TNSM.2018.2796720, June 2018, <https://ieeexplore.ieee.org/document/8267132>.
[Auge2018]Augé、J.、Carofiglio、G.、Grassi、G.、Muscariello、L.、Pau、G.、およびX. Zeng、「Map-Me：コンテンツ中心ネットワークにおけるアンカーレスプロデューサーモビリティの管理」、ネットワークとサービス管理に関するIEEEトランザクションでは、Vol。2018年6月15日、<https://ieeexplore.ieee.org/document/8267132>。
[Autonet] Schroeder, M., Birrell, A., Burrows, M., Murray, H., Needham, R., Rodeheffer, T., Satterthwaite, E., and C. Thacker, "Autonet: a High-speed, Self-configuring Local Area Network Using Point-to-point Links", in IEEE Journal on Selected Areas in Communications, Vol. 9, No. 8, DOI 10.1109/49.105178, October 1991, <https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-59.pdf>.
[自動ネット] Schroeder、M.、Birrell、A、Burrows、M.、Murray、H.、Needham、R.、Rodehfer、T.、Satterthwaite、E.、およびC Thacker "AutoNet：高速、ポイントツーポイントリンクを使用した自己構成ローカルエリアネットワーク「通信の選択された領域のIEEEジャーナル」、Vol。9、No.8、DOI 10.1109 / 49.105178、1991年10月、<https：//www.hpl.hp.com/techreports/compaq-dec/src-rr-59.pdf>。
[BenAbraham2018] Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A., and P. Crowley, "Decoupling Information and Connectivity via Information-Centric Transport", in ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking, Boston, MA, USA, DOI 10.1145/3267955.3267963, September 2018, <https://conferences.sigcomm.org/acm-icn/2018/proceedings/ icn18-final31.pdf>.
[Benabraham2018]ベンアブラハム、H.、Parwatikar、J.、Dehart、J.、Dresher、A.、P. Crowley、ICN '18の「情報中心の輸送によるデカップリング情報と接続」、5日の手続き2018年9月、<https://conferences.sigcomm.org/acm-icn/2018/proceedings/ icn18-final31.pdf>。
[Carofiglio2012] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint Hop-by-hop and Receiver-Driven Interest Control Protocol for Content-Centric Networks", in ACM SIGCOMM Computer Communication Review, DOI 10.1145/2377677.2377772, September 2012, <http://conferences.sigcomm.org/sigcomm/2012/paper/icn/ p37.pdf>.
[carofiglio2012] Carofiglio、G.、Gallo、M.、およびL. Muscariello、「コンテンツ中心ネットワークのための共同ホップバイホップおよび受信者駆動関心対照議定書」、ACM SIGCOMM Computer Communication Review、DOI 10.1145 / 2377677.23777722012年9月、<http://conferences.sigcomm.org/sigcomm/2012/paper/icn/ p37.pdf>。
[Carofiglio2016] Carofiglio, G., Gallo, M., and L. Muscariello, "Optimal multipath congestion control and request forwarding in information-centric networks: Protocol design and experimentation", in Computer Networks, Vol. 110, DOI 10.1016/j.comnet.2016.09.012, December 2016, <https://doi.org/10.1016/j.comnet.2016.09.012>.
[carofiglio2016] Carofiglio、G.、Gallo、M.、L. Muscariello、「情報中心のネットワークにおける最適なマルチパス輻輳制御と要求転送：プロトコル設計と実験」、vol。110、Doi 10.1016 / J.comNet.2016.09.012、2016年12月、<https：//doi.org/10.1016/j.0.net.2016.09.012>。
[CCNINFO] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Work in Progress, Internet-Draft, draft-irtf-icnrg-ccninfo-06, 9 March 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-ccninfo-06>.
[CCNINFO] Asaeda、H.、Ouka、A.、およびX. Shao、 "CCNINFO：コンテンツ中心ネットワークにおけるコンテンツとネットワーク情報の発見"、進行中の作業、インターネットドラフト、ドラフト - IRTF-ICNRG-CCNInfo-06、2021年3月9日、<https://datatracker.ietf.org/doc/html/draft -irtf-icnrg-ccninfo-06>。
[DNC-QOS-ICN] Jangam, A., Ed., Suthar, P., and M. Stolic, "QoS Treatments in ICN using Disaggregated Name Components", Work in Progress, Internet-Draft, draft-anilj-icnrg-dnc-qos-icn-02, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-dnc-qos-icn-02>.
[DNC-QoS-ICN] Jangam、A.、ED。、Suthar、P.、およびM.停止中、「分離名成分を使用したICNのQoSトリートメント」、進行中、インターネットドラフト、ドラフトANILJ-ICNRG-DNC-QoS-ICN-02,2020、<https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-dnc-tos-icn-02>。
[FLOWBALANCE] Oran, D., "Maintaining CCNx or NDN flow balance with highly variable data object sizes", Work in Progress, Internet-Draft, draft-oran-icnrg-flowbalance-05, 14 February 2021, <https://datatracker.ietf.org/doc/html/ draft-oran-icnrg-flowbalance-05>.
[FlowBalancance] Oran、D.、「可変データオブジェクトサイズを持つCCNXまたはNDNフローバランスの維持」、進行中の作業、インターネットドラフト、ドラフト-ORAN-ICNRG-FLOWBALANCE-05,2021、<https：//dataTracker.ietf.org/doc/html/ romft-oran-icnrg-frowbalance-05>。
[FLOWCLASS] Moiseenko, I. and D. Oran, "Flow Classification in Information Centric Networking", Work in Progress, Internet-Draft, draft-moiseenko-icnrg-flowclass-07, 13 January 2021, <https://datatracker.ietf.org/doc/html/ draft-moiseenko-icnrg-flowclass-07>.
[FlowClass] Moiseenko、I.およびD. Oran、「情報中心のネットワーキングのフロー分類」、進行中の作業、インターネットドラフト、ドラフト - Moiseenko-ICNRG-FlowClass-07,2021、<https：// dataTracker。ietf.org/doc/html/ draft-moiseenko-icnrg-flowclass-07>。
[HICN] Muscariello, L., Carofiglio, G., Augé, J., Papalini, M., and M. Sardara, "Hybrid Information-Centric Networking", Work in Progress, Internet-Draft, draft-muscariello-intarea-hicn-04, 20 May 2020, <https://datatracker.ietf.org/doc/html/draft-muscariello-intarea-hicn-04>.
[HICN]マスカリーロ、L.、Carofiglio、G.、Augé、J.、Papalini、M.、およびM. Serdara、「ハイブリッド情報中心のネットワーキング」、進行中の作業、インターネットドラフト、ドラフト - マスカリエロ - INTAREA-HICN-04,2020、2020年5月20日、<https://datatracker.ietf.org/doc/html/draft-muscariello-intarea-hicn-04>。
[ICNTRACEROUTE] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and D. R. Oran, "ICN Traceroute Protocol Specification", Work in Progress, Internet-Draft, draft-irtf-icnrg-icntraceroute-02, 11 April 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icntraceroute-02>.
[ICNTRACEROUTE] Mastorakis、S.、Gibson、J.、Moiseenko、I.、Droms、R.、およびDr Oran、 "ICN Traceroute Protocol Specification"、進行中の作業、インターネットドラフト、ドラフト-IRTF-ICNRG-ICNTRACEROUTE-2021年4月11日、<https://datatracker.ietf.org/doc/html/draft-irfnrg-icntracerOute-02>。
[IOTQOS] Gundogan, C., Schmidt, T. C., Waehlisch, M., Frey, M., Shzu-Juraschek, F., and J. Pfender, "Quality of Service for ICN in the IoT", Work in Progress, Internet-Draft, draft-gundogan-icnrg-iotqos-01, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-gundogan-icnrg-iotqos-01>.
[iotqos] Gundogan、C.、Schmidt、TC、Waehlisch、M.、Frey、M.、Shzu-Juraschek、F.、およびJ.Pfender、「IOTのICNのサービス品質」、進行中の作業、インターネット--draft、draft-gundogan-icnrg-iotqos-01,17月8日、<https：//datatracker.ietf.org/doc/html/draft-gundogan-icnrg-iotqos-01>。
[Krol2018] Król, M., Habak, K., Oran, D., Kutscher, D., and I. Psaras, "RICE: Remote Method Invocation in ICN", in ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking, Boston, MA, USA, DOI 10.1145/3267955.3267956, September 2018, <https://conferences.sigcomm.org/acm-icn/2018/proceedings/ icn18-final9.pdf>.
[Krol2018]Król、M.、Habak、K.、Oran、D.、Kutscher、D.、およびI. Psaras、ICN '18の「ICNにおけるリモートメソッド呼び出し」、「ICNでのリモートメソッド呼び出し」、第5回ACM会議の議事録Information-Centric Networking、Boston、MA、USA、DOI 10.1145 / 3267955.3267956、2018年9月、<https：//conferences.sigcomm.org/acm-icn/2018/proceedings/ icn18-final9.pdf>。
[Mahdian2016] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, "MIRCC: Multipath-aware ICN Rate-based Congestion Control", in ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984365, September 2016, <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ p1-mahdian.pdf>.
[Mahdian2016] Mahdian、M.、Arianfar、S.、Gibson、J.、およびD. Oran、 "Mircc：マルチパス対応ICNレートベース輻輳制御"、ACM-ICN '16：3番目のACM会議の手続き2016年9月、<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ p1-mahdian.pdf>。
[minmaxfairness] Wikipedia, "Max-min fairness", June 2021, <https://en.wikipedia.org/w/index.php?title=Max-min_fairness&oldid=1028246910>.
[MinmaxFairness]ウィキペディア、「マックスマイナスフェアネス」、2021年6月、<https：//en.wikipedia.org/w/index.php?title=max-min_fairness&oldid=1028246910>
[Moiseenko2017] Moiseenko, I. and D. Oran, "Path Switching in Content Centric and Named Data Networks", in ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking, DOI 10.1145/3125719.3125721, September 2017, <https://conferences.sigcomm.org/acm-icn/2017/proceedings/ icn17-2.pdf>.
[Moiseenko2017] ICN '17では、Moiseenko、I.およびD. Oran、ICN '17では、2017年9月、<https://conferences.sigcomm.org/acm-icn/2017/proceedings/ icn17-2.pdf>。
[NDN] "Named Data Networking: Executive Summary", <https://named-data.net/project/execsummary/>.
[NDN] "名前付きデータネットワーキング：Executive Summary"、<https://named-data.net/project/execsummary/>。
[NDNTutorials] "NDN Tutorials", <https://named-data.net/publications/tutorials/>.
[ndntutorials] "NDNチュートリアル"、<https://named-data.net/publications/tutorials/>。
[NWC-CCN-REQS] Matsuzono, K., Asaeda, H., and C. Westphal, "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges", Work in Progress, Internet-Draft, draft-irtf-nwcrg-nwc-ccn-reqs-05, 22 January 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs-05>.
[NWC-CCN-REQS]松音、K.、ASAEDA、H.、およびC.西部、「コンテンツ中心ネットワーキング/名前付きデータネットワーキングのネットワークコーディング：考慮事項および課題」、進行中の作業、インターネットドラフト、ドラフト - IRTF-NWCRG-NWC-CCN-REQ-05,22 1月22日、<https：//datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs-05>。
[Oran2018QoSslides] Oran, D., "Thoughts on Quality of Service for NDN/CCN-style ICN protocol architectures", presented at ICNRG Interim Meeting, Cambridge, MA, 24 September 2018, <https://datatracker.ietf.org/meeting/interim-2018-icnrg-03/materials/slides-interim-2018-icnrg-03-sessa-thoughts-on-qos-for-ndnccn-style-icn-protocol-architectures>.
[Oran2018Qosslides] oran、D.、「NDN / CCNスタイルのICNプロトコルアーキテクチャのサービス品質について」、ICNRG暫定会議、Cambridge、MA、MA、MA、2018年9月24日、<https：//datatracker.ietf.org/Meeting / Interim-2018-ICRG-03 /マテリアル/スライド-NTRIM-2018-ICRG-03-SESSA-Thoughts-On-QoS-for-NDNCCN-STYLE-ICN-Protocol-Architecture - 。
[proportionalfairness] Wikipedia, "Proportional-fair scheduling", June 2021, <https://en.wikipedia.org/w/index.php?title=Proportional-fair_scheduling&oldid=1027073289>.
[比例フェアネス]ウィキペディア、「比例フェアスケジューリング」、2021年6月、<https：//en.wikipedia.org/w/index.php?title=propentional-fair_scheduling &oldid=1027073289>
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、DOI10.17487 / RFC2205、1997年9月、<https：//www.rfc-editor.org/info/rfc2205>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, DOI 10.17487/RFC2998, November 2000, <https://www.rfc-editor.org/info/rfc2998>.
[RFC2998] Bernet、Y、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J.、E。Felstaine、「DiffServネットワーク上の統合サービス操作のためのフレームワーク」、RFC 2998、DOI 10.17487 / RFC2998、2000年11月、<https：//www.rfc-editor.org/info/rfc2998>。
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC3170] Quinn、B.およびK. Almeroth、 "IPマルチキャストアプリケーション：課題とソリューション"、RFC 3170、DOI 10.17487 / RFC3170、2001年9月、<https://www.rfc-editor.org/info/rfc3170>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] awduche、D.、Berger、L.、GaN、D.、Li、T.、Srinivasan、V.、G.Svp-Te：LSPトンネルのRSVPへの拡張機能、RFC 3209、DOI10.17487 / RFC3209、2001年12月、<https：//www.rfc-editor.org/info/rfc3209>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M.、S. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<https：//www.rfc-編集者。ORG / INFO / RFC4340>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https：//www.rfc-editor.org/ info / rfc4594>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ED。そして、「Q. Thomson」、「QUIC：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487 / RFC9000、<https：//www.rfc-editor.org/info/rfc9000>。
[Schneider2016] Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A Practical Congestion Control Scheme for Named Data Networking", in ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984369, September 2016, <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ p21-schneider.pdf>.
[Schneider2016] Schneider、K.、Yi、C.、Zhang、B.、L. Zhang、ACM-ICN '16では、「名前付きデータネットワーキングの実用的な輻輳制御方式」：情報に関する3番目のACM会議の手続き2016年9月、<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ p21-schneider.pdf>。
[Shenker2006] Shenker, S., "Fundamental design issues for the future Internet", in IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7, DOI 10.1109/49.414637, September 2006, <https://dl.acm.org/doi/10.1109/49.414637>.
[Shenker2006] Shenker、S、「将来のインターネットのための基本的な設計上の問題」、コミュニケーションの選択された分野のIEEEジャーナル、Vol。13、No.7、DOI 10.1109 / 49.414637、2006年9月、<https：//dl.acm.org/doi/10.1109/49.414637>。
[Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level Multi-path Interest Control for Information Centric Networking", ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking, DOI 10.1145/3267955.3267971, September 2018, <https://conferences.sigcomm.org/acm-icn/2018/proceedings/ icn18-final62.pdf>.
[Song2018] Song、J.、Lee、M.、T.Kwon、 "SMIC：情報中心のネットワーキングのためのサブフローレベルマルチパスコントロール"、ICN '18：情報中心のネットワーキングに関する第5回ACM会議の手続き、Doi 10.1145 / 3267955.3267971、2018年9月、<https：//conferences.sigcomm.org/acm-icn/2018/proceed / icn18-final62.pdf>。
[Tseng2003] Tseng, C.-J. and C.-H. Chen, "The performance of QoS-aware IP multicast routing protocols", in Networks, Vol. 42, DOI 10.1002/net.10084, September 2003, <https://onlinelibrary.wiley.com/doi/abs/10.1002/ net.10084>.
[TSENG2003] Tseng、C.そしてC.h.「ネットワーク」、「QoS対応IPマルチキャストルーティングプロトコルのパフォーマンス」、vol。42、DOI 10.1002 / Net.10084、2003年9月、<https：//onlinelibrary.wiley.com/doi/abs/10.1002/ net.10084>。
[Wang2000] Wang, B. and J. C. Hou, "Multicast routing and its QoS extension: problems, algorithms, and protocols", in IEEE Network, Vol. 14, Issue 1, DOI 10.1109/65.819168, January 2000, <https://ieeexplore.ieee.org/document/819168>.
[Wang2000] Wang、B.およびJ.C. Multicast RoutingおよびそのQoS拡張：IEEEネットワーク、vol.jpの問題、アルゴリズム、プロトコル "。14、問題1、DOI 10.1109 / 65.819168、2000年1月、<https：//ieeexplore.ieee.org/document/819168>。
[Wang2013] Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I. Rhee, "An improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking", in ACM SIGCOMM Computer Communication Review, DOI 10.1145/2534169.2491233, August 2013, <https://conferences.sigcomm.org/sigcomm/2013/papers/icn/ p55.pdf>.
[wang2013] Wang、Y.、Rozhnova、N.、Narayanan、A.、Oran、D.、およびI。Rhee、「名前付きデータネットワーキングにおける輻輳制御のための改良されたホッホホップの関心シェーパー」、ACM SIGCOMMコンピュータ通信レビュー、DOI 10.1145 / 2534169.2491233、<https：//conferences.sigcomm.org/sigcomm/2013/papers/icn/ p55.pdf>。
Author's Address
著者の住所
Dave Oran Network Systems Research and Design 4 Shady Hill Square Cambridge, MA 02138 United States of America
Dave Oran Network Systems Research and Design 4 Shady Hill Square Cambridge、MA 02138アメリカ合衆国
Email: daveoran@orandom.net