[要約] RFC 9318 は、2021年9月14日から16日にかけてインターネットアーキテクチャ委員会（IAB）が開催したワークショップ「Measuring Network Quality for End-Users」の報告書です。この報告書は、ワークショップで議論されたトピックや最終的な結論を要約しています。
Internet Architecture Board (IAB) W. Hardaker
Request for Comments: 9318
Category: Informational O. Shapira
ISSN: 2070-1721 October 2022
IAB Workshop Report: Measuring Network Quality for End-Users
IABワークショップレポート：エンドユーザーのネットワーク品質の測定
Abstract
概要
The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September 14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.
エンドユーザーワークショップの測定ネットワーク品質は、2021年9月14〜16日にインターネットアーキテクチャボード（IAB）によって事実上開催されました。このレポートは、ワークショップ、議論されたトピック、およびワークショップの最後に描かれたいくつかの予備的な結論を要約しています。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
このドキュメントは、ワークショップの議事録に関するレポートであることに注意してください。このレポートに記録されているビューとポジションは、ワークショップ参加者の見解であり、必ずしもIABのビューとポジションを反映しているわけではありません。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供する価値があるとみなした情報を表しています。インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。IABによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。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/rfc9318.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9318で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Problem Space
2. Workshop Agenda
3. Position Papers
4. Workshop Topics and Discussion
4.1. Introduction and Overviews
4.1.1. Key Points from the Keynote by Vint Cerf
4.1.2. Introductory Talks
4.1.3. Introductory Talks - Key Points
4.2. Metrics Considerations
4.2.1. Common Performance Metrics
4.2.2. Availability Metrics
4.2.3. Capacity Metrics
4.2.4. Latency Metrics
4.2.5. Measurement Case Studies
4.2.6. Metrics Key Points
4.3. Cross-Layer Considerations
4.3.1. Separation of Concerns
4.3.2. Security and Privacy Considerations
4.3.3. Metric Measurement Considerations
4.3.4. Towards Improving Future Cross-Layer Observability
4.3.5. Efficient Collaboration between Hardware and Transport
Protocols
4.3.6. Cross-Layer Key Points
4.4. Synthesis
4.4.1. Measurement and Metrics Considerations
4.4.2. End-User Metrics Presentation
4.4.3. Synthesis Key Points
5. Conclusions
5.1. General Statements
5.2. Specific Statements about Detailed Protocols/Techniques
5.3. Problem Statements and Concerns
5.4. No-Consensus-Reached Statements
6. Follow-On Work
7. IANA Considerations
8. Security Considerations
9. Informative References
Appendix A. Program Committee
Appendix B. Workshop Chairs
Appendix C. Workshop Participants
IAB Members at the Time of Approval
Acknowledgments
Contributors
Authors' Addresses
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計された時折のワークショップを開催しています。IABのこの長期計画機能は、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループが実施する継続的なエンジニアリングの取り組みを補完しています。
The Measuring Network Quality for End-Users workshop [WORKSHOP] was held virtually by the Internet Architecture Board (IAB) on September 14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.
エンドユーザーワークショップ[ワークショップ]の測定ネットワークの品質は、2021年9月14〜16日にインターネットアーキテクチャボード（IAB）によって事実上開催されました。このレポートは、ワークショップ、議論されたトピック、およびいくつかの予備的な結論をまとめたものです。ワークショップ。
The Internet in 2021 is quite different from what it was 10 years ago. Today, it is a crucial part of everyone's daily life. People use the Internet for their social life, for their daily jobs, for routine shopping, and for keeping up with major events. An increasing number of people can access a gigabit connection, which would be hard to imagine a decade ago. Additionally, thanks to improvements in security, people trust the Internet for financial banking transactions, purchasing goods, and everyday bill payments.
2021年のインターネットは、10年前とはまったく異なります。今日、それは皆の日常生活の重要な部分です。人々は、社会生活、日常の仕事、日常的な買い物、主要なイベントに遅れずについていくために、社会生活のためにインターネットを使用します。ますます多くの人がギガビット接続にアクセスできます。これは、10年前に想像するのが難しいでしょう。さらに、セキュリティの改善のおかげで、人々は金融銀行取引、商品の購入、日常の請求書の支払いについてインターネットを信頼しています。
At the same time, some aspects of the end-user experience have not improved as much. Many users have typical connection latencies that remain at decade-old levels. Despite significant reliability improvements in data center environments, end users also still often see interruptions in service. Despite algorithmic advances in the field of control theory, one still finds that the queuing delays in the last-mile equipment exceeds the accumulated transit delays. Transport improvements, such as QUIC, Multipath TCP, and TCP Fast Open, are still not fully supported in some networks. Likewise, various advances in the security and privacy of user data are not widely supported, such as encrypted DNS to the local resolver.
同時に、エンドユーザーエクスペリエンスのいくつかの側面はそれほど改善されていません。多くのユーザーは、10年前のレベルのままである典型的な接続レイテンシを持っています。データセンター環境の大幅な信頼性の向上にもかかわらず、エンドユーザーは依然としてサービスの中断も頻繁に見られます。制御理論の分野でのアルゴリズムの進歩にもかかわらず、ラストマイル機器のキューイングの遅延が累積輸送遅延を超えることがまだわかります。QUIC、MultiPath TCP、TCP Fast Openなどの輸送の改善は、一部のネットワークではまだ完全にはサポートされていません。同様に、ユーザーデータのセキュリティとプライバシーのさまざまな進歩は、ローカルリゾルバーへの暗号化されたDNSなど、広くサポートされていません。
Some of the major factors behind this lack of progress is the popular perception that throughput is often the sole measure of the quality of Internet connectivity. With such a narrow focus, the Measuring Network Quality for End-Users workshop aimed to discuss various topics:
この進歩の欠如の背後にある主要な要因のいくつかは、スループットが多くの場合、インターネット接続の品質の唯一の尺度であるという一般的な認識です。このような狭い焦点により、エンドユーザーワークショップの測定ネットワーク品質は、さまざまなトピックについて議論することを目的としています。
* What is user latency under typical working conditions?
* 典型的な労働条件下でのユーザーレイテンシとは何ですか？
* How reliable is connectivity across longer time periods?
* より長い期間にわたって接続性はどの程度信頼できますか？
* Do networks allow the use of a broad range of protocols?
* ネットワークは、幅広いプロトコルの使用を許可していますか？
* What services can be run by network clients?
* ネットワーククライアントがどのようなサービスを実行できますか？
* What kind of IPv4, NAT, or IPv6 connectivity is offered, and are there firewalls?
* どのようなIPv4、NAT、またはIPv6接続が提供されていますか？ファイアウォールはありますか？
* What security mechanisms are available for local services, such as DNS?
* DNSなどのローカルサービスで利用できるセキュリティメカニズムは何ですか？
* To what degree are the privacy, confidentiality, integrity, and authenticity of user communications guarded?
* ユーザーコミュニケーションのプライバシー、機密性、整合性、信頼性はどの程度ですか？
* Improving these aspects of network quality will likely depend on measuring and exposing metrics in a meaningful way to all involved parties, including to end users. Such measurement and exposure of the right metrics will allow service providers and network operators to concentrate focus on their users' experience and will simultaneously empower users to choose the Internet Service Providers (ISPs) that can deliver the best experience based on their needs.
* ネットワークの品質のこれらの側面を改善することは、おそらくエンドユーザーを含むすべての関係者に意味のある方法でメトリックを測定および公開することに依存する可能性があります。このような適切なメトリックの測定と露出により、サービスプロバイダーとネットワークオペレーターはユーザーのエクスペリエンスに集中することができ、同時にユーザーがニーズに基づいて最高のエクスペリエンスを提供できるインターネットサービスプロバイダー（ISP）を選択できるようになります。
* What are the fundamental properties of a network that contributes to a good user experience?
* 優れたユーザーエクスペリエンスに貢献するネットワークの基本的なプロパティは何ですか？
* What metrics quantify these properties, and how can we collect such metrics in a practical way?
* これらのプロパティを定量化するメトリックは、どのようにしてそのようなメトリックを実用的に収集できますか？
* What are the best practices for interpreting those metrics and incorporating them in a decision-making process?
* これらのメトリックを解釈し、意思決定プロセスに組み込むためのベストプラクティスは何ですか？
* What are the best ways to communicate these properties to service providers and network operators?
* これらのプロパティをサービスプロバイダーとネットワークオペレーターに伝える最良の方法は何ですか？
* How can these metrics be displayed to users in a meaningful way?
* これらのメトリックは、意味のある方法でユーザーにどのように表示できますか？
The Measuring Network Quality for End-Users workshop was divided into the following main topic areas; see further discussion in Sections 4 and 5:
エンドユーザーワークショップの測定ネットワーク品質は、次の主要なトピック領域に分けられました。セクション4および5の詳細については、
* Introduction overviews and a keynote by Vint Cerf
* はじめに概要とヴィントCerfによる基調講演
* Metrics considerations
* メトリックの考慮事項
* Cross-layer considerations
* 交差層の考慮事項
* Synthesis
* 合成
* Group conclusions
* グループ結論
The following position papers were received for consideration by the workshop attendees. The workshop's web page [WORKSHOP] contains archives of the papers, presentations, and recorded videos.
ワークショップの参加者から検討のために、次のポジションペーパーが受け取られました。ワークショップのWebページ[ワークショップ]には、論文、プレゼンテーション、録画されたビデオのアーカイブが含まれています。
* Ahmed Aldabbagh. "Regulatory perspective on measuring network quality for end users" [Aldabbagh2021]
* アーメド・アルダブバグ。「エンドユーザーのネットワーク品質の測定に関する規制の視点」[aldabbagh2021]
* Al Morton. "Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?" [Morton2021]
* アル・モートン。「ドリームパイプまたはパイプドリーム：ユーザーは何を望んでいますか（そしてどうすればそれを保証できますか）？」[Morton2021]
* Alexander Kozlov. "The 2021 National Internet Segment Reliability Research"
* アレクサンダー・コズロフ。「2021年の全国インターネットセグメント信頼性の研究」
* Anna Brunstrom. "Measuring network quality - the MONROE experience"
* アンナブルンストローム。「ネットワークの品質の測定 - モンローエクスペリエンス」
* Bob Briscoe, Greg White, Vidhi Goel, and Koen De Schepper. "A Single Common Metric to Characterize Varying Packet Delay" [Briscoe2021]
* ボブ・ブリスコ、グレッグ・ホワイト、ヴィディ・ゴエル、コーン・デ・シェッパー。「さまざまなパケット遅延を特徴付ける単一の一般的なメトリック」[briscoe2021]
* Brandon Schlinker. "Internet Performance from Facebook's Edge" [Schlinker2019]
* ブランドン・シュリンカー。「Facebook's Edgeからのインターネットパフォーマンス」[Schlinker2019]
* Christoph Paasch, Kristen McIntyre, Randall Meyer, Stuart Cheshire, and Omer Shapira. "An end-user approach to the Internet Score" [McIntyre2021]
* クリストフ・パシュ、クリステン・マッキンタイア、ランドール・マイヤー、スチュアート・チェシャー、オメル・シャピラ。「インターネットスコアへのエンドユーザーアプローチ」[McIntyre2021]
* Christoph Paasch, Randall Meyer, Stuart Cheshire, and Omer Shapira. "Responsiveness under Working Conditions" [Paasch2021]
* クリストフ・パシュ、ランドール・マイヤー、スチュアート・チェシャー、オメル・シャピラ。「労働条件下での応答性」[Paasch2021]
* Dave Reed and Levi Perigo. "Measuring ISP Performance in Broadband America: A Study of Latency Under Load" [Reed2021]
* デイブ・リードとレヴィ・ペリゴ。「ブロードバンドアメリカでのISPパフォーマンスの測定：負荷の下での遅延の研究」[Reed2021]
* Eve M. Schooler and Rick Taylor. "Non-traditional Network Metrics"
* イブ・M・スクールアーとリック・テイラー。「非伝統的なネットワークメトリック」
* Gino Dion. "Focusing on latency, not throughput, to provide better internet experience and network quality" [Dion2021]
* ジーノディオン。「スループットではなく、インターネットエクスペリエンスとネットワークの品質を向上させるために、レイテンシに焦点を当てる」[Dion2021]
* Gregory Mirsky, Xiao Min, Gyan Mishra, and Liuyan Han. "The error performance metric in a packet-switched network" [Mirsky2021]
* グレゴリー・ミルスキー、シャオ・ミン、ギャン・ミシュラ、リュヤン・ハン。「パケットスイッチネットワークのエラーパフォーマンスメトリック」[mirsky2021]
* Jana Iyengar. "The Internet Exists In Its Use" [Iyengar2021]
* Jana Iyengar。「インターネットはその使用に存在します」[iyengar2021]
* Jari Arkko and Mirja Kuehlewind. "Observability is needed to improve network quality" [Arkko2021]
* Jari ArkkoとMirja Kuehlewind。「ネットワークの品質を向上させるには観察可能性が必要です」[arkko2021]
* Joachim Fabini. "Network Quality from an End User Perspective" [Fabini2021]
* ヨアヒム・ファビーニ。「エンドユーザーの観点からのネットワーク品質」[Fabini2021]
* Jonathan Foulkes. "Metrics helpful in assessing Internet Quality" [Foulkes2021]
* ジョナサン・フォークス。「インターネットの品質の評価に役立つメトリック」[Foulkes2021]
* Kalevi Kilkki and Benajamin Finley. "In Search of Lost QoS" [Kilkki2021]
* Kalevi KilkkiとBenajamin Finley。「失われたQosを探して」[kilkki2021]
* Karthik Sundaresan, Greg White, and Steve Glennon. "Latency Measurement: What is latency and how do we measure it?"
* Karthik Sundaresan、Greg White、Steve Glennon。「レイテンシ測定：レイテンシとは何ですか？それをどのように測定しますか？」
* Keith Winstein. "Five Observations on Measuring Network Quality for Users of Real-Time Media Applications"
* キース・ウィンスタイン。「リアルタイムメディアアプリケーションのユーザーのネットワーク品質の測定に関する5つの観察」
* Ken Kerpez, Jinous Shafiei, John Cioffi, Pete Chow, and Djamel Bousaber. "Wi-Fi and Broadband Data" [Kerpez2021]
* ケンケルペス、ジナスシャフィエイ、ジョンシオフィ、ピートチョウ、およびダメルブーザバー。「Wi-Fiおよびブロードバンドデータ」[kerpez2021]
* Kenjiro Cho. "Access Network Quality as Fitness for Purpose"
* ケンジロ・チョ。「目的のためのフィットネスとしてのネットワーク品質にアクセス」
* Koen De Schepper, Olivier Tilmans, and Gino Dion. "Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss" [DeSchepper2021]
* Koen de Schepper、Olivier Tilmans、Gino Dion。「パケット損失なしの低いキューイングレイテンシのハードウェアサポートの課題と機会」[Deschepper2021]
* Kyle MacMillian and Nick Feamster. "Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers" [MacMillian2021]
* カイル・マクミランとニック・フィームスター。「速度テストを超えて：異なる速度層にわたる負荷下のレイテンシの測定」[MacMillan 2021]
* Lucas Pardue and Sreeni Tellakula. "Lower-layer performance not indicative of upper-layer success" [Pardue2021]
* ルーカス・パルドとスリーニ・テラクラ。「下層の成功を示す下層層性能」[Pardue2021]
* Matt Mathis. "Preliminary Longitudinal Study of Internet Responsiveness" [Mathis2021]
* マット・マティス。「インターネット応答性の予備的な縦断的研究」[Mathis2021]
* Michael Welzl. "A Case for Long-Term Statistics" [Welzl2021]
* マイケル・ウェルツル。「長期統計のケース」[Welzl2021]
* Mikhail Liubogoshchev. "Cross-layer Cooperation for Better Network Service" [Liubogoshchev2021]
* Mikhail Liubogoshchev。「より良いネットワークサービスのためのクロス層協力」[liubogoshchev2021]
* Mingrui Zhang, Vidhi Goel, and Lisong Xu. "User-Perceived Latency to Measure CCAs" [Zhang2021]
* Mingrui Zhang、Vidhi Goel、およびLisong Xu。「CCASを測定するためのユーザー認識レイテンシ」[Zhang2021]
* Neil Davies and Peter Thompson. "Measuring Network Impact on Application Outcomes Using Quality Attenuation" [Davies2021]
* ニール・デイビスとピーター・トンプソン。「品質減衰を使用したアプリケーションの結果に対するネットワークの測定の影響」[Davies2021]
* Olivier Bonaventure and Francois Michel. "Packet delivery time as a tie-breaker for assessing Wi-Fi access points" [Michel2021]
* Olivier BonaventureとFrancois Michel。「Wi-Fiアクセスポイントを評価するためのタイブレーカーとしてのパケット配送時間」[Michel2021]
* Pedro Casas. "10 Years of Internet-QoE Measurements. Video, Cloud, Conferencing, Web and Apps. What do we Need from the Network Side?" [Casas2021]
* ペドロカサス。「10年のインターネットQoE測定。ビデオ、クラウド、会議、Web、アプリ。ネットワーク側から何が必要ですか？」[CASAS2021]
* Praveen Balasubramanian. "Transport Layer Statistics for Network Quality" [Balasubramanian2021]
* Praveen Balasubramanian。「ネットワーク品質のための輸送層統計」[Balasubramanian2021]
* Rajat Ghai. "Using TCP Connect Latency for measuring CX and Network Optimization" [Ghai2021]
* Rajat Ghai。「TCPを使用して、CXとネットワークの最適化を測定するためにレイテンシを接続します」[Ghai2021]
* Robin Marx and Joris Herbots. "Merge Those Metrics: Towards Holistic (Protocol) Logging" [Marx2021]
* ロビン・マルクスとジョリス・ハーボット。「これらの指標をマージ：総合（プロトコル）ロギングに向けて」[MARX2021]
* Sandor Laki, Szilveszter Nadas, Balazs Varga, and Luis M. Contreras. "Incentive-Based Traffic Management and QoS Measurements" [Laki2021]
* Sandor Laki、Szilveszter Nadas、Balazs Varga、およびLuis M. Contreras。「インセンティブベースのトラフィック管理とQoS測定」[Laki2021]
* Satadal Sengupta, Hyojoon Kim, and Jennifer Rexford. "Fine-Grained RTT Monitoring Inside the Network" [Sengupta2021]
* Satadal Sengupta、Hyojoon Kim、Jennifer Rexford。「ネットワーク内での細粒のRTT監視」[sengupta2021]
* Stuart Cheshire. "The Internet is a Shared Network" [Cheshire2021]
* スチュアートチェシャー。「インターネットは共有ネットワークです」[Cheshire2021]
* Toerless Eckert and Alex Clemm. "network-quality-eckert-clemm-00.4"
* Toerless EckertとAlex Clemm。「ネットワーク品質 - エッカートクラム-00.4」
* Vijay Sivaraman, Sharat Madanapalli, and Himal Kumar. "Measuring Network Experience Meaningfully, Accurately, and Scalably" [Sivaraman2021]
* Vijay Sivaraman、Sharat Madanapalli、Himal Kumar。「ネットワークエクスペリエンスの測定は、有意義に、正確に、そして拡張的に」[Sivaraman2021]
* Yaakov (J) Stein. "The Futility of QoS" [Stein2021]
* ヤコフ（J）スタイン。「Qosの無益」[Stein2021]
The agenda for the three-day workshop was broken into four separate sections that each played a role in framing the discussions. The workshop started with a series of introduction and problem space presentations (Section 4.1), followed by metrics considerations (Section 4.2), cross-layer considerations (Section 4.3), and a synthesis discussion (Section 4.4). After the four subsections concluded, a follow-on discussion was held to draw conclusions that could be agreed upon by workshop participants (Section 5).
3日間のワークショップのアジェンダは、それぞれが議論のフレーミングに役割を果たした4つの別々のセクションに分割されました。ワークショップは、一連の紹介と問題のスペースプレゼンテーション（セクション4.1）から始まり、その後にメトリックの考慮事項（セクション4.2）、交差層の考慮事項（セクション4.3）、および統合の議論（セクション4.4）が続きました。4つのサブセクションが終了した後、ワークショップの参加者が合意する可能性のある結論を導き出すために、次の議論が行われました（セクション5）。
The workshop started with a broad focus on the state of user Quality of Service (QoS) and Quality of Experience (QoE) on the Internet today. The goal of the introductory talks was to set the stage for the workshop by describing both the problem space and the current solutions in place and their limitations.
ワークショップは、今日のインターネット上のユーザーサービス品質（QOS）とエクスペリエンスの品質（QOE）に幅広く焦点を当てて始まりました。紹介講演の目標は、問題のスペースと現在のソリューションの両方を説明し、それらの制限を説明することにより、ワークショップの舞台を設定することでした。
The introduction presentations provided views of existing QoS and QoE measurements and their effectiveness. Also discussed was the interaction between multiple users within the network, as well as the interaction between multiple layers of the OSI stack. Vint Cerf provided a keynote describing the history and importance of the topic.
紹介のプレゼンテーションは、既存のQOSおよびQOE測定値とその有効性の見解を提供しました。また、ネットワーク内の複数のユーザー間の相互作用と、OSIスタックの複数のレイヤー間の相互作用についても説明しました。Vint Cerfは、トピックの歴史と重要性を説明する基調講演を提供しました。
We may be operating in a networking space with dramatically different parameters compared to 30 years ago. This differentiation justifies reconsidering not only the importance of one metric over the other but also reconsidering the entire metaphor.
30年前と比較して、劇的に異なるパラメーターを備えたネットワーキングスペースで動作している可能性があります。この区別は、一方のメトリックの重要性を他のメトリックよりも再考するだけでなく、メタファー全体を再検討することを正当化します。
It is time for the experts to look at not only adjusting TCP but also exploring other protocols, such as QUIC has done lately. It's important that we feel free to consider alternatives to TCP. TCP is not a teddy bear, and one should not be afraid to replace it with a transport layer with better properties that better benefit its users.
専門家がTCPを調整するだけでなく、QUICが最近行ったような他のプロトコルを探ることを検討する時が来ました。TCPの代替案を自由に検討することが重要です。TCPはテディベアではなく、ユーザーの利益を上げるより良いプロパティを備えた輸送層に置き換えることを恐れてはなりません。
A suggestion: we should consider exercises to identify desirable properties. As we are looking at the parametric spaces, one can identify "desirable properties", as opposed to "fundamental properties", for example, a low-latency property. An example coming from the Advanced Research Projects Agency (ARPA): you want to know where the missile is now, not where it was. Understanding drives particular parameter creation and selection in the design space.
提案：望ましい特性を特定するための演習を検討する必要があります。パラメトリックスペースを見ているとき、「基本的な特性」、たとえば低遅延特性とは対照的に、「望ましい特性」を特定できます。Advanced Research Projects Agency（ARPA）からの例：あなたは、ミサイルが今どこにあるかを知りたいのですが、それがどこにあったかではありません。理解は、設計スペースで特定のパラメーターの作成と選択を促進します。
When parameter values are changed in extreme, such as connectiveness, alternative designs will emerge. One case study of note is the interplanetary protocol, where "ping" is no longer indicative of anything useful. While we look at responsiveness, we should not ignore connectivity.
接続性など、パラメーター値が極端に変更されると、代替設計が出現します。メモの1つのケーススタディは、惑星間プロトコルです。ここでは、「ping」はもはや有用なものを示していません。応答性を見ていますが、接続性を無視すべきではありません。
Unfortunately, maintaining backward compatibility is painful. The work on designing IPv6 so as to transition from IPv4 could have been done better if the backward compatibility was considered. It is too late for IPv6, but it is not too late to consider this issue for potential future problems.
残念ながら、後方互換性を維持することは苦痛です。IPv4からの移行に関するIPv6の設計に関する作業は、後方互換性が考慮された場合、より良く行われた可能性があります。IPv6には遅すぎますが、将来の潜在的な問題についてこの問題を考慮するのは遅すぎることはありません。
IPv6 is still not implemented fully everywhere. It's been a long road to deployment since starting work in 1996, and we are still not there. In 1996, the thinking was that it was quite easy to implement IPv6, but that failed to hold true. In 1996, the dot-com boom began, where a lot of money was spent quickly, and the moment was not caught in time while the market expanded exponentially. This should serve as a cautionary tale.
IPv6はまだどこにでも完全に実装されていません。1996年に作業を開始して以来、展開するのは長い道のりでしたが、まだそこにいません。1996年には、IPv6を実装するのは非常に簡単だと考えていましたが、それは真実を保持することができませんでした。1996年、ドットコムブームが始まり、そこで多くのお金が迅速に費やされ、市場が指数関数的に拡大している間、その瞬間は時間に巻き込まれませんでした。これは警告物語として役立つはずです。
One last point: consider performance across multiple hops in the Internet. We've not seen many end-to-end metrics, as successfully developing end-to-end measurements across different network and business boundaries is quite hard to achieve. A good question to ask when developing new protocols is "will the new protocol work across multiple network hops?"
最後のポイント：インターネット内の複数のホップでのパフォーマンスを検討します。さまざまなネットワークやビジネスの境界にわたってエンドツーエンドの測定を正常に開発することを達成するのは非常に困難であるため、多くのエンドツーエンドメトリックを見ていません。新しいプロトコルを開発するときに尋ねるのは良い質問です。「新しいプロトコルは複数のネットワークホップで機能しますか？」
Multi-hop networks are being gradually replaced by humongous, flat networks with sufficient connectivity between operators so that systems become 1 hop, or 2 hops at most, away from each other (e.g., Google, Facebook, and Amazon). The fundamental architecture of the Internet is changing.
マルチホップネットワークは、システム間の十分な接続性を備えた巨大なフラットネットワークに徐々に置き換えられ、システムが1ホップになるか、せいぜい2ホップ（例：Google、Facebook、Amazon）になります。インターネットの基本的なアーキテクチャが変化しています。
The Internet is a shared network built on IP protocols using packet switching to interconnect multiple autonomous networks. The Internet's departure from circuit-switching technologies allowed it to scale beyond any other known network design. On the other hand, the lack of in-network regulation made it difficult to ensure the best experience for every user.
インターネットは、複数の自律ネットワークを相互接続するためにパケットスイッチングを使用して、IPプロトコル上に構築された共有ネットワークです。インターネットがサーキットスイッチングテクノロジーからの逸脱により、他の既知のネットワーク設計を超えてスケーリングすることができました。一方、ネットワーク内の規制がないため、すべてのユーザーに最適なエクスペリエンスを確保することが困難になりました。
As Internet use cases continue to expand, it becomes increasingly more difficult to predict which network characteristics correlate with better user experiences. Different application classes, e.g., video streaming and teleconferencing, can affect user experience in ways that are complex and difficult to measure. Internet utilization shifts rapidly during the course of each day, week, and year, which further complicates identifying key metrics capable of predicting a good user experience.
インターネットのユースケースが拡大し続けるにつれて、どのネットワーク特性がより良いユーザーエクスペリエンスと相関するかを予測することがますます困難になります。さまざまなアプリケーションクラス、たとえば、ビデオストリーミングやテレコンファレンスは、複雑で測定が困難な方法でユーザーエクスペリエンスに影響を与える可能性があります。インターネット利用は、毎日、週、および年の間に急速に変化し、優れたユーザーエクスペリエンスを予測できる重要なメトリックを特定することがさらに複雑になります。
QoS initiatives attempted to overcome these difficulties by strictly prioritizing different types of traffic. However, QoS metrics do not always correlate with user experience. The utility of the QoS metric is further limited by the difficulties in building solutions with the desired QoS characteristics.
QoSイニシアチブは、さまざまな種類のトラフィックを厳密に優先順位付けすることにより、これらの困難を克服しようとしました。ただし、QoSメトリックは常にユーザーエクスペリエンスと相関するとは限りません。QoSメトリックの有用性は、目的のQoS特性を備えたソリューションの構築の難しさによってさらに制限されます。
QoE initiatives attempted to integrate the psychological aspects of how quality is perceived and create statistical models designed to optimize the user experience. Despite these high modeling efforts, the QoE approach proved beneficial in certain application classes. Unfortunately, generalizing the models proved to be difficult, and the question of how different applications affect each other when sharing the same network remains an open problem.
QOEイニシアチブは、品質がどのように認識されるかの心理的側面を統合し、ユーザーエクスペリエンスを最適化するように設計された統計モデルを作成しようとしました。これらの高いモデリングの取り組みにもかかわらず、QOEアプローチは特定のアプリケーションクラスで有益であることが証明されました。残念ながら、モデルの一般化は困難であることが判明し、同じネットワークを共有するときに異なるアプリケーションが互いにどのように影響するかという問題は、オープンな問題のままです。
The industry's focus on giving the end user more throughput/bandwidth led to remarkable advances. In many places around the world, a home user enjoys gigabit speeds to their ISP. This is so remarkable that it would have been brushed off as science fiction a decade ago. However, the focus on increased capacity came at the expense of neglecting another important core metric: latency. As a result, end users whose experience is negatively affected by high latency were advised to upgrade their equipment to get more throughput instead. [MacMillian2021] showed that sometimes such an upgrade can lead to latency improvements, due to the economical reasons of overselling the "value-priced" data plans.
エンドユーザーのスループット/帯域幅を増やすことに業界が焦点を当てているため、驚くべき進歩につながりました。世界中の多くの場所で、ホームユーザーはISPのギガビットスピードを楽しんでいます。これは非常に驚くべきことであるため、10年前にSFとして払いのけられていたでしょう。ただし、容量の増加に焦点を当てることは、別の重要なコアメトリックであるレイテンシを無視することを犠牲にして行われました。その結果、エクスペリエンスが高いレイテンシによって悪影響を受けたエンドユーザーは、代わりにより多くのスループットを得るために機器をアップグレードすることをお勧めしました。[MacMillian2021]は、「価値価格の」データプランを過剰販売する経済的な理由により、このようなアップグレードが遅延の改善につながることがあることを示しました。
As the industry continued to give end users more throughput, while mostly neglecting latency concerns, application designs started to employ various latency and short service disruption hiding techniques. For example, a user's web browser performance experience is closely tied to the content in the browser's local cache. While such techniques can clearly improve the user experience when using stale data is possible, this development further decouples user experience from core metrics.
業界がエンドユーザーにより多くのスループットを提供し続けたため、主に潜在的な懸念を無視している一方で、アプリケーションの設計はさまざまなレイテンシと短いサービスの隠蔽技術を採用し始めました。たとえば、ユーザーのWebブラウザのパフォーマンスエクスペリエンスは、ブラウザのローカルキャッシュのコンテンツと密接に結びついています。このような手法は、古いデータを使用することが可能である場合、ユーザーエクスペリエンスを明確に改善できますが、この開発はコアメトリックからユーザーエクスペリエンスをさらに切り離します。
In the most recent 10 years, efforts by Dave Taht and the bufferbloat society have led to significant progress in updating queuing algorithms to reduce latencies under load compared to simpler FIFO queues. Unfortunately, the home router industry has yet to implement these algorithms, mostly due to marketing and cost concerns. Most home router manufacturers depend on System on a Chip (SoC) acceleration to create products with a desired throughput. SoC manufacturers opt for simpler algorithms and aggressive aggregation, reasoning that a higher-throughput chip will have guaranteed demand. Because consumers are offered choices primarily among different high-throughput devices, the perception that a higher throughput leads to higher a QoS continues to strengthen.
直近の10年間で、Dave TahtとBufferbloat Societyによる努力により、より単純なFIFOキューと比較して、荷重下のレイテンシを減らすためのキューイングアルゴリズムを更新することに大きな進歩がもたらされました。残念ながら、ホームルーター業界は、主にマーケティングとコストの懸念によるこれらのアルゴリズムをまだ実装していません。ほとんどのホームルーターメーカーは、システムに依存してチップ（SOC）加速度に依存して、目的のスループットを備えた製品を作成します。SOCメーカーは、より単純なアルゴリズムと積極的な集約を選択し、ハイスループットチップに需要が保証されると推論しています。消費者は主に異なるハイスループットデバイスの中から選択されているため、スループットが高いほどQoSが増加し続けるという認識が強化され続けています。
The home router is not the only place that can benefit from clearer indications of acceptable performance for users. Since users perceive the Internet via the lens of applications, it is important that we call upon application vendors to adopt solutions that stress lower latencies. Unfortunately, while bandwidth is straightforward to measure, responsiveness is trickier. Many applications have found a set of metrics that are helpful to their realm but do not generalize well and cannot become universally applicable. Furthermore, due to the highly competitive application space, vendors may have economic reasons to avoid sharing their most useful metrics.
ホームルーターは、ユーザーにとって許容可能なパフォーマンスのより明確な兆候から利益を得ることができる唯一の場所ではありません。ユーザーは、アプリケーションのレンズを介してインターネットを認識しているため、アプリケーションベンダーに、より低いレイテンシを強調するソリューションを採用するよう呼びかけることが重要です。残念ながら、帯域幅は簡単に測定するのが簡単ですが、応答性は難しいです。多くのアプリケーションでは、その領域に役立つが、一般化されず、普遍的に適用可能になることはできない一連のメトリックを見つけました。さらに、非常に競争の激しいアプリケーションスペースにより、ベンダーは最も有用なメトリックを共有することを避けるための経済的理由を抱えている可能性があります。
1. Measuring bandwidth is necessary but is not alone sufficient.
1. 帯域幅の測定は必要ですが、単独では十分ではありません。
2. In many cases, Internet users don't need more bandwidth but rather need "better bandwidth", i.e., they need other connectivity improvements.
2. 多くの場合、インターネットユーザーはこれ以上の帯域幅を必要としませんが、「より良い帯域幅」が必要です。つまり、他の接続性の改善が必要です。
3. Users perceive the quality of their Internet connection based on the applications they use, which are affected by a combination of factors. There's little value in exposing a typical user to the entire spectrum of possible reasons for the poor performance perceived in their application-centric view.
3. ユーザーは、要因の組み合わせの影響を受けるアプリケーションに基づいて、インターネット接続の品質を知覚します。典型的なユーザーを、アプリケーション中心の見解で知覚されるパフォーマンスの低さの可能性のある理由の全体にさらされることにはほとんど価値がありません。
4. Many factors affecting user experience are outside the users' sphere of control. It's unclear whether exposing users to these other factors will help them understand the state of their network performance. In general, users prefer simple, categorical choices (e.g., "good", "better", and "best" options).
4. ユーザーエクスペリエンスに影響を与える多くの要因は、ユーザーの制御範囲外です。ユーザーをこれらの他の要因にさらすことで、ネットワークパフォーマンスの状態を理解するのに役立つかどうかは不明です。一般に、ユーザーはシンプルでカテゴリの選択を好みます（例：「良い」、「より良い」、「最高の」オプション）。
5. The Internet content market is highly competitive, and many applications develop their own "secret sauce".
5. インターネットコンテンツ市場は非常に競争が激しく、多くのアプリケーションが独自の「秘密ソース」を開発しています。
In the second agenda section, the workshop continued its discussion about metrics that can be used instead of or in addition to available bandwidth. Several workshop attendees presented deep-dive studies on measurement methodology.
2番目のアジェンダセクションでは、ワークショップは、利用可能な帯域幅の代わりに、またはそれに加えて使用できるメトリックに関する議論を続けました。いくつかのワークショップ参加者は、測定方法に関する深い研究を提示しました。
Losing Internet access entirely is, of course, the worst user experience. Unfortunately, unless rebooting the home router restores connectivity, there is little a user can do other than contacting their service provider. Nevertheless, there is value in the systematic collection of availability metrics on the client side; these can help the user's ISP localize and resolve issues faster while enabling users to better choose between ISPs. One can measure availability directly by simply attempting connections from the client side to distant locations of interest. For example, Ookla's [Speedtest] uses a large number of Android devices to measure network and cellular availability around the globe. Ookla collects hundreds of millions of data points per day and uses these for accurate availability reporting. An alternative approach is to derive availability from the failure rates of other tests. For example, [FCC_MBA] and [FCC_MBA_methodology] use thousands of off-the-shelf routers, with measurement software developed by [SamKnows]. These routers perform an array of network tests and report availability based on whether test connections were successful or not.
もちろん、インターネットアクセスを完全に失うことは、最悪のユーザーエクスペリエンスです。残念ながら、ホームルーターを再起動すると接続が復元されない限り、サービスプロバイダーに連絡する以外にユーザーができることはほとんどありません。それにもかかわらず、クライアント側の可用性メトリックの体系的なコレクションには価値があります。これらは、ユーザーのISPが問題をより速くローカライズして解決するのに役立ち、ユーザーがISPをより適切に選択できるようにします。クライアント側から遠くの関心のある場所に接続を試してみるだけで、可用性を直接測定できます。たとえば、Ooklaの[SpeedTest]は、多数のAndroidデバイスを使用して、世界中のネットワークとセルラーの可用性を測定しています。 Ooklaは1日あたり数億個のデータポイントを収集し、これらを使用して正確な可用性レポートを使用しています。別のアプローチは、他のテストの故障率から可用性を導き出すことです。たとえば、[fcc_mba]および[fcc_mba_methodology]は、[samknows]によって開発された測定ソフトウェアを備えた数千の既製ルーターを使用します。これらのルーターは、テスト接続が成功したかどうかに基づいて、一連のネットワークテストとレポートの可用性を実行します。
Measuring available capacity can be helpful to end users, but it is even more valuable for service providers and application developers. High-definition video streaming requires significantly more capacity than any other type of traffic. At the time of the workshop, video traffic constituted 90% of overall Internet traffic and contributed to 95% of the revenues from monetization (via subscriptions, fees, or ads). As a result, video streaming services, such as Netflix, need to continuously cope with rapid changes in available capacity. The ability to measure available capacity in real time leverages the different adaptive bitrate (ABR) compression algorithms to ensure the best possible user experience. Measuring aggregated capacity demand allows ISPs to be ready for traffic spikes. For example, during the end-of-year holiday season, the global demand for capacity has been shown to be 5-7 times higher than during other seasons. For end users, knowledge of their capacity needs can help them select the best data plan given their intended usage. In many cases, however, end users have more than enough capacity, and adding more bandwidth will not improve their experience -- after a point, it is no longer the limiting factor in user experience. Finally, the ability to differentiate between the "throughput" and the "goodput" can be helpful in identifying when the network is saturated.
利用可能な容量を測定することはエンドユーザーに役立ちますが、サービスプロバイダーやアプリケーション開発者にとってさらに価値があります。高解像度のビデオストリーミングには、他のどのタイプのトラフィックよりも大幅に多くの容量が必要です。ワークショップの時点で、ビデオトラフィックはインターネットトラフィック全体の90％を占め、収益化による収益の95％に貢献しました（サブスクリプション、料金、または広告を介して）。その結果、Netflixなどのビデオストリーミングサービスは、利用可能な能力の急速な変化に継続的に対処する必要があります。利用可能な容量をリアルタイムで測定する機能は、可能な限り最高のユーザーエクスペリエンスを確保するために、異なる適応ビットレート（ABR）圧縮アルゴリズムを活用します。集約された容量の需要を測定することで、ISPは交通スパイクの準備が整うことができます。たとえば、年末のホリデーシーズン中に、能力に対する世界的な需要は、他のシーズンよりも5〜7倍高いことが示されています。エンドユーザーの場合、容量のニーズに関する知識は、意図した使用法を考慮して、最高のデータ計画を選択するのに役立ちます。ただし、多くの場合、エンドユーザーには十分な容量があり、帯域幅を増やすことは体験を改善しません。ポイントの後、ユーザーエクスペリエンスの制限要因ではありません。最後に、「スループット」と「Goodput」を区別する機能は、ネットワークが飽和状態になったときに識別するのに役立ちます。
In measuring network quality, latency is defined as the time it takes a packet to traverse a network path from one end to the other. At the time of this report, users in many places worldwide can enjoy Internet access that has adequately high capacity and availability for their current needs. For these users, latency improvements, rather than bandwidth improvements, can lead to the most significant improvements in QoE. The established latency metric is a round-trip time (RTT), commonly measured in milliseconds. However, users often find RTT values unintuitive since, unlike other performance metrics, high RTT values indicate poor latency and users typically understand higher scores to be better. To address this, [Paasch2021] and [Mathis2021] present an inverse metric, called "Round-trips Per Minute" (RPM).
ネットワークの品質を測定すると、レイテンシは、ネットワークパスを一方の端から他方に通過するのにパケットをかける時間として定義されます。このレポートの時点で、世界中の多くの場所のユーザーは、現在のニーズに適切に能力が高く、可用性があるインターネットアクセスを楽しむことができます。これらのユーザーの場合、帯域幅の改善ではなく、遅延の改善がQOEの最も重要な改善につながる可能性があります。確立されたレイテンシメトリックは、一般にミリ秒で測定される往復時間（RTT）です。ただし、他のパフォーマンスメトリックとは異なり、RTTの値が高いため、レイテンシが不十分であり、ユーザーは通常、より高いスコアがより良いと理解しているため、ユーザーは直感的ではないことがよくあります。これに対処するために、[paasch2021]と[mathis2021]は、「1分あたりのラウンドトリップ」（rpm）と呼ばれる逆メトリックを示します。
There is an important distinction between "idle latency" and "latency under working conditions". The former is measured when the network is underused and reflects a best-case scenario. The latter is measured when the network is under a typical workload. Until recently, typical tools reported a network's idle latency, which can be misleading. For example, data presented at the workshop shows that idle latencies can be up to 25 times lower than the latency under typical working loads. Because of this, it is essential to make a clear distinction between the two when presenting latency to end users.
「アイドルレイテンシ」と「労働条件下でのレイテンシ」には重要な区別があります。前者は、ネットワークが不足しているときに測定され、ベストケースのシナリオを反映しています。後者は、ネットワークが典型的なワークロードの下にあるときに測定されます。最近まで、典型的なツールはネットワークのアイドルレイテンシを報告しましたが、これは誤解を招く可能性があります。たとえば、ワークショップで提示されたデータは、アイドル状態のレイテンシが典型的な作業荷重の下での遅延の最大25倍低いことを示しています。このため、エンドユーザーにレイテンシを提示する際に、2つを明確に区別することが不可欠です。
Data shows that rapid changes in capacity affect latency. [Foulkes2021] attempts to quantify how often a rapid change in capacity can cause network connectivity to become "unstable" (i.e., having high latency with very little throughput). Such changes in capacity can be caused by infrastructure failures but are much more often caused by in-network phenomena, like changing traffic engineering policies or rapid changes in cross-traffic.
データは、容量の急速な変化が遅延に影響することを示しています。[foulkes2021]容量の急速な変化がネットワーク接続を「不安定」にする頻度を定量化しようとすることを試みます（つまり、スループットがほとんどなく、高いレイテンシを持つ）。このような容量の変化は、インフラストラクチャの障害によって引き起こされる可能性がありますが、交通工学ポリシーの変化やトラフィック間の急速な変化など、ネットワーク内の現象によって引き起こされることがよくあります。
Data presented at the workshop shows that 36% of measured lines have capacity metrics that vary by more than 10% throughout the day and across multiple days. These differences are caused by many variables, including local connectivity methods (Wi-Fi vs. Ethernet), competing LAN traffic, device load/configuration, time of day, and local loop/backhaul capacity. These factor variations make measuring capacity using only an end-user device or other end-network measurement difficult. A network router seeing aggregated traffic from multiple devices provides a better vantage point for capacity measurements. Such a test can account for the totality of local traffic and perform an independent capacity test. However, various factors might still limit the accuracy of such a test. Accurate capacity measurement requires multiple samples.
ワークショップで提示されたデータによると、測定された行の36％が容量のメトリックを持ち、1日を通して10％以上変化し、複数日にわたって変化します。これらの違いは、ローカル接続法（Wi-Fi対イーサネット）、競合するLANトラフィック、デバイスの負荷/構成、時刻、ローカルループ/バックホール容量など、多くの変数によって引き起こされます。これらの因子の変動により、エンドユーザーデバイスまたはその他のエンドネットワーク測定のみを使用して測定容量が困難になります。複数のデバイスから集約されたトラフィックを見るネットワークルーターは、容量測定に適した視点を提供します。このようなテストは、ローカルトラフィックの全体を説明し、独立した容量テストを実行できます。ただし、さまざまな要因が依然としてそのようなテストの精度を制限する可能性があります。正確な容量測定には、複数のサンプルが必要です。
As users perceive the Internet through the lens of applications, it may be difficult to correlate changes in capacity and latency with the quality of the end-user experience. For example, web browsers rely on cached page versions to shorten page load times and mitigate connectivity losses. In addition, social networking applications often rely on prefetching their "feed" items. These techniques make the core in-network metrics less indicative of the users' experience and necessitates collecting data from the end-user applications themselves.
ユーザーがアプリケーションのレンズを介してインターネットを認識しているため、容量と遅延の変化をエンドユーザーエクスペリエンスの品質と相関させることは困難な場合があります。たとえば、Webブラウザはキャッシュされたページバージョンに依存して、ページの読み込み時間を短縮し、接続性の損失を軽減します。さらに、ソーシャルネットワーキングアプリケーションは、多くの場合、「フィード」アイテムのプリフェッチに依存しています。これらの手法により、ネットワーク内のコアメトリックがユーザーのエクスペリエンスを示すことが少なくなり、エンドユーザーアプリケーション自体からデータを収集する必要があります。
It is helpful to distinguish between applications that operate on a "fixed latency budget" from those that have more tolerance to latency variance. Cloud gaming serves as an example application that requires a "fixed latency budget", as a sudden latency spike can decide the "win/lose" ratio for a player. Companies that compete in the lucrative cloud gaming market make significant infrastructure investments, such as building entire data centers closer to their users. These data centers highlight the economic benefit that lower numbers of latency spikes outweigh the associated deployment costs. On the other hand, applications that are more tolerant to latency spikes can continue to operate reasonably well through short spikes. Yet, even those applications can benefit from consistently low latency depending on usage shifts. For example, Video-on-Demand (VOD) apps can work reasonably well when the video is consumed linearly, but once the user tries to "switch a channel" or to "skip ahead", the user experience suffers unless the latency is sufficiently low.
「固定レイテンシ予算」で動作するアプリケーションと、レイテンシの差異に対してより耐性があるアプリケーションと区別することは役立ちます。クラウドゲームは、「固定レイテンシ予算」を必要とするアプリケーションの例として機能します。突然の遅延により、スパイクはプレーヤーの「勝ち/負け」比を決定できます。有利なクラウドゲーム市場で競争する企業は、ユーザーの近くにデータセンター全体を構築するなど、重要なインフラストラクチャ投資を行っています。これらのデータセンターは、レイテンシスパイクの数が少ないという経済的利益を強調しています。関連する展開コストを上回っています。一方、レイテンシスパイクに対してより寛容なアプリケーションは、短いスパイクを通じて合理的にうまく動作し続けることができます。しかし、これらのアプリケーションでさえ、使用状況のシフトに応じて一貫して低レイテンシから恩恵を受けることができます。たとえば、ビデオが直線的に消費されると、ビデオオンデマンド（VOD）アプリは合理的にうまく機能しますが、ユーザーが「チャンネルを切り替えよう」または「スキップ先」にしようとすると、レイテンシが十分にある場合を除き、ユーザーエクスペリエンスが苦しみます。低い。
Finally, as applications continue to evolve, in-application metrics are gaining in importance. For example, VOD applications can assess the QoE by application-specific metrics, such as whether the video player is able to use the highest possible resolution, identifying when the video is smooth or freezing, or other similar metrics. Application developers can then effectively use these metrics to prioritize future work. All popular video platforms (YouTube, Instagram, Netflix, and others) have developed frameworks to collect and analyze VOD metrics at scale. One example is the Scuba framework used by Meta [Scuba].
最後に、アプリケーションが進化し続けるにつれて、アプリケーション内のメトリックが重要になっています。たとえば、VODアプリケーションは、ビデオプレーヤーが可能な限り高い解像度を使用できるかどうかなど、アプリケーション固有のメトリックによってQOEを評価できます。ビデオがスムーズまたは凍結するとき、または他の同様のメトリックを識別できます。アプリケーション開発者は、これらのメトリックを効果的に使用して、将来の作業に優先順位を付けることができます。すべての人気のあるビデオプラットフォーム（YouTube、Instagram、Netflixなど）は、VODメトリックを大規模に収集および分析するためのフレームワークを開発しました。1つの例は、Meta [Scuba]で使用されるスキューバフレームワークです。
Unfortunately, in-application metrics can be challenging to use for comparative research purposes. First, different applications often use different metrics to measure the same phenomena. For example, application A may measure the smoothness of video via "mean time to rebuffer", while application B may rely on the "probability of rebuffering per second" for the same purpose. A different challenge with in-application metrics is that VOD is a significant source of revenue for companies, such as YouTube, Facebook, and Netflix, placing a proprietary incentive against exchanging the in-application data. A final concern centers on the privacy issues resulting from in-application metrics that accurately describe the activities and preferences of an individual end user.
残念ながら、適用内の指標は、比較研究の目的で使用するのが難しい場合があります。第一に、異なるアプリケーションは、多くの場合、異なるメトリックを使用して同じ現象を測定します。たとえば、アプリケーションAは「平均時間から拒絶される時間」を介してビデオの滑らかさを測定することができますが、アプリケーションBは同じ目的で「秒あたりの拒絶の確率」に依存する場合があります。アプリケーション内のメトリックを伴う別の課題は、VODがYouTube、Facebook、Netflixなどの企業にとって重要な収益源であり、アプリケーションデータの交換に対して独自のインセンティブを置いていることです。最終的な懸念は、個々のエンドユーザーのアクティビティと好みを正確に説明するアプリケーション内のメトリックに起因するプライバシーの問題に焦点を当てています。
Availability is simply defined as whether or not a packet can be sent and then received by its intended recipient. Availability is naively thought to be the simplest to measure, but it is more complex when considering that continual, instantaneous measurements would be needed to detect the smallest of outages. Also difficult is determining the root cause of infallibility: was the user's line down, was something in the middle of the network, or was it the service with which the user was attempting to communicate?
可用性は、パケットを送信してから受信者が受信できるかどうかとして単純に定義されます。可用性は測定が最も単純であるとナイーに考えられていますが、最小の停止を検出するために継続的で瞬時の測定が必要になると考えると、より複雑です。また、不可fallの根本原因を決定することも困難です。ユーザーのラインがダウンしているか、ネットワークの真ん中にあるものでしたか、それともユーザーが通信しようとしていたサービスでしたか？
If the network capacity does not meet user demands, the network quality will be impacted. Once the capacity meets the demands, increasing capacity won't lead to further quality improvements.
ネットワーク容量がユーザーの要求を満たさない場合、ネットワークの品質が影響を受けます。容量が需要を満たすと、容量の増加はさらなる品質の改善につながることはありません。
The actual network connection capacity is determined by the equipment and the lines along the network path, and it varies throughout the day and across multiple days. Studies involving DSL lines in North America indicate that over 30% of the DSL lines have capacity metrics that vary by more than 10% throughout the day and across multiple days.
実際のネットワーク接続容量は、機器とネットワークパスに沿ったラインによって決定され、1日中および複数日にわたって異なります。北米のDSLラインを含む研究は、DSLラインの30％以上が容量のメトリックを、1日を通して数日間で10％以上変化させる容量メトリックを持っていることを示しています。
Some factors that affect the actual capacity are:
実際の容量に影響を与えるいくつかの要因は次のとおりです。
1. Presence of a competing traffic, either in the LAN or in the WAN environments. In the LAN setting, the competing traffic reflects the multiple devices that share the Internet connection. In the WAN setting, the competing traffic often originates from the unrelated network flows that happen to share the same network path.
1. LANまたはWAN環境での競合するトラフィックの存在。LAN設定では、競合するトラフィックは、インターネット接続を共有する複数のデバイスを反映しています。WAN設定では、競合するトラフィックは、同じネットワークパスを共有する無関係なネットワークフローに由来することがよくあります。
2. Capabilities of the equipment along the path of the network connection, including the data transfer rate and the amount of memory used for buffering.
2. データ転送速度やバッファリングに使用されるメモリの量を含む、ネットワーク接続のパスに沿った機器の機能。
3. Active traffic management measures, such as traffic shapers and policers that are often used by the network providers.
3. ネットワークプロバイダーがよく使用するトラフィックシェイパーやポリサーなどのアクティブなトラフィック管理措置。
There are other factors that can negatively affect the actual line capacities.
実際のライン容量に悪影響を与える可能性のある他の要因があります。
The user demands of the traffic follow the usage patterns and preferences of the particular users. For example, large data transfers can use any available capacity, while the media streaming applications require limited capacity to function correctly. Videoconferencing applications typically need less capacity than high-definition video streaming.
ユーザーの要求は、特定のユーザーの使用パターンと好みに従います。たとえば、大規模なデータ転送は利用可能な容量を使用できますが、メディアストリーミングアプリケーションでは正しく機能するには限られた容量が必要です。ビデオ会議アプリケーションは通常、高解像度のビデオストリーミングよりも少ない容量が必要です。
End-to-end latency is the time that a particular packet takes to traverse the network path from the user to their destination and back. The end-to-end latency comprises several components:
エンドツーエンドのレイテンシは、特定のパケットがユーザーから宛先へのネットワークパスを通過して戻るのにかかる時間です。エンドツーエンドのレイテンシは、いくつかのコンポーネントで構成されています。
1. The propagation delay, which reflects the path distance and the individual link technologies (e.g., fiber vs. satellite). The propagation doesn't depend on the utilization of the network, to the extent that the network path remains constant.
1. 伝播遅延は、パス距離と個々のリンクテクノロジーを反映しています（ファイバー対衛星など）。伝播は、ネットワークパスが一定のままである程度まで、ネットワークの利用に依存しません。
2. The buffering delay, which reflects the time segments spent in the memory of the network equipment that connect the individual network links, as well as in the memory of the transmitting endpoint. The buffering delay depends on the network utilization, as well as on the algorithms that govern the queued segments.
2. バッファリング遅延は、個々のネットワークリンクを接続するネットワーク機器のメモリと送信エンドポイントのメモリに費やされた時間セグメントを反映しています。バッファリング遅延は、ネットワークの使用率と、キューに囲まれたセグメントを管理するアルゴリズムに依存します。
3. The transport protocol delays, which reflect the time spent in retransmission and reassembly, as well as the time spent when the transport is "head-of-line blocked".
3. 輸送プロトコルの遅延は、再送信と再組み立てに費やされた時間と、輸送が「頭の頭のブロック」されたときに費やされる時間を反映しています。
4. Some of the workshop submissions that have explicitly called out the application delay, which reflects the inefficiencies in the application layer.
4. アプリケーションレイヤーの非効率性を反映するアプリケーションの遅延を明示的に呼び出したワークショップの提出物の一部。
Typically, end-to-end latency is measured when the network is idle. Results of such measurements mostly reflect the propagation delay but not other kinds of delay. This report uses the term "idle latency" to refer to results achieved under idle network conditions.
通常、ネットワークがアイドル状態のときにエンドツーエンドのレイテンシが測定されます。そのような測定の結果は、主に伝播遅延を反映していますが、他の種類の遅延は反映されていません。このレポートでは、「アイドルレイテンシ」という用語を使用して、アイドルネットワーク条件下で達成された結果を参照しています。
Alternatively, if the latency is measured when the network is under its typical working conditions, the results reflect multiple types of delays. This report uses the term "working latency" to refer to such results. Other sources use the term "latency under load" (LUL) as a synonym.
あるいは、ネットワークが典型的な作業条件下にあるときにレイテンシが測定される場合、結果は複数のタイプの遅延を反映しています。このレポートでは、「動作レイテンシ」という用語を使用して、そのような結果を参照しています。他の情報源は、「Load Load」（LUL）という用語を同義語として使用します。
Data presented at the workshop reveals a substantial difference between the idle latency and the working latency. Depending on the traffic direction and the technology type, the working latency is between 6 to 25 times higher than the idle latency:
ワークショップで提示されたデータは、アイドルレイテンシと動作レイテンシの実質的な違いを明らかにしています。交通方向とテクノロジータイプに応じて、作業レイテンシはアイドルレイテンシの6〜25倍高くなります。
+============+============+========+=========+============+=========+
| Direction | Technology |Working | Idle | Working - |Working /|
| | Type |Latency | Latency | Idle |Idle |
| | | | | Difference |Ratio |
+============+============+========+=========+============+=========+
| Downstream | FTTH |148 | 10 | 138 |15 |
+------------+------------+--------+---------+------------+---------+
| Downstream | Cable |103 | 13 | 90 |8 |
+------------+------------+--------+---------+------------+---------+
| Downstream | DSL |194 | 10 | 184 |19 |
+------------+------------+--------+---------+------------+---------+
| Upstream | FTTH |207 | 12 | 195 |17 |
+------------+------------+--------+---------+------------+---------+
| Upstream | Cable |176 | 27 | 149 |6 |
+------------+------------+--------+---------+------------+---------+
| Upstream | DSL |686 | 27 | 659 |25 |
+------------+------------+--------+---------+------------+---------+
Table 1
表1
While historically the tooling available for measuring latency focused on measuring the idle latency, there is a trend in the industry to start measuring the working latency as well, e.g., Apple's [NetworkQuality].
歴史的には、アイドルレイテンシの測定に焦点を当てたレイテンシを測定するために利用できるツールは、業界でも作業レイテンシの測定を開始する傾向があります。たとえば、Appleの[ネットワーク品質]。
The participants have proposed several concrete methodologies for measuring the network quality for the end users.
参加者は、エンドユーザーのネットワーク品質を測定するためのいくつかの具体的な方法論を提案しています。
[Paasch2021] introduced a methodology for measuring working latency from the end-user vantage point. The suggested method incrementally adds network flows between the user device and a server endpoint until a bottleneck capacity is reached. From these measurements, a round-trip latency is measured and reported to the end user. The authors chose to report results with the RPM metric. The methodology had been implemented in Apple's macOS Monterey.
[PAASCH2021]は、エンドユーザーの見晴らしの良い点から作業レイテンシを測定するための方法論を導入しました。提案されたメソッドは、ボトルネック容量に到達するまで、ユーザーデバイスとサーバーエンドポイントの間にネットワークフローを段階的に追加します。これらの測定から、往復レイテンシが測定され、エンドユーザーに報告されます。著者は、RPMメトリックで結果を報告することを選択しました。方法論は、AppleのMacOS Montereyに実装されていました。
[Mathis2021] applied the RPM metric to the results of more than 4 billion download tests that M-Lab performed from 2010-2021. During this time frame, the M-Lab measurement platform underwent several upgrades that allowed the research team to compare the effect of different TCP congestion control algorithms (CCAs) on the measured end-to-end latency. The study showed that the use of cubic CCA leads to increased working latency, which is attributed to its use of larger queues.
[Mathis2021]は、M-LABが2010年から2021年に実行した40億を超えるダウンロードテストの結果にRPMメトリックを適用しました。この時間枠では、M-LAB測定プラットフォームはいくつかのアップグレードを受け、研究チームは測定されたエンドツーエンドのレイテンシに対する異なるTCP混雑制御アルゴリズム（CCA）の効果を比較することができました。この研究は、立方体CCAの使用が作業潜時の増加につながることを示しました。これは、より大きなキューの使用に起因しています。
[Schlinker2019] presented a large-scale study that aimed to establish a correlation between goodput and QoE on a large social network. The authors performed the measurements at multiple data centers from which video segments of set sizes were streamed to a large number of end users. The authors used the goodput and throughput metrics to determine whether particular paths were congested.
[Schlinker2019]は、大規模なソーシャルネットワークでGoodputとQOEの間に相関を確立することを目的とした大規模な研究を発表しました。著者は、セットサイズのビデオセグメントが多数のエンドユーザーにストリーミングされた複数のデータセンターで測定を実行しました。著者は、GoodputおよびSultputメトリックを使用して、特定のパスが混雑しているかどうかを判断しました。
[Reed2021] presented the analysis of working latency measurements collected as part of the Measuring Broadband America (MBA) program by the Federal Communication Commission (FCC). The FCC does not include working latency in its yearly report but does offer it in the raw data files. The authors used a subset of the raw data to identify important differences in the working latencies across different ISPs.
[REED2021]は、連邦通信委員会（FCC）によって測定ブロードバンドアメリカ（MBA）プログラムの一部として収集された作業潜時測定の分析を提示しました。FCCには、年間レポートに動作レイテンシは含まれていませんが、生データファイルで提供しています。著者は、生データのサブセットを使用して、異なるISPにわたる作業レイテンシの重要な違いを特定しました。
[MacMillian2021] presented analysis of working latency across multiple service tiers. They found that, unsurprisingly, "premium" tier users experienced lower working latency compared to a "value" tier. The data demonstrated that working latency varies significantly within each tier; one possible explanation is the difference in equipment deployed in the homes.
[MacMillian2021]は、複数のサービス層にわたる動作レイテンシの分析を提示しました。彼らは、当然のことながら、「プレミアム」層のユーザーは、「価値」層と比較してより低い作業レイテンシを経験したことを発見しました。データは、作業潜時が各層内で大きく異なることを実証しました。考えられる説明の1つは、家に配備されている機器の違いです。
These studies have stressed the importance of measurement of working latency. At the time of this report, many home router manufacturers rely on hardware-accelerated routing that uses FIFO queues. Focusing on measuring the working latency measurements on these devices and making the consumer aware of the effect of choosing one manufacturer vs. another can help improve the home router situation. The ideal test would be able to identify the working latency and pinpoint the source of the delay (home router, ISP, server side, or some network node in between).
これらの研究は、動作潜時の測定の重要性を強調しています。このレポートの時点で、多くのホームルーターメーカーは、FIFOキューを使用するハードウェアアクセラレーションのルーティングに依存しています。これらのデバイスでの作業レイテンシ測定の測定に焦点を当て、1つのメーカーと別のメーカーを選択する効果を消費者に認識させることで、ホームルーターの状況を改善するのに役立ちます。理想的なテストでは、作業レイテンシを識別し、遅延のソース（ホームルーター、ISP、サーバー側、またはその間の一部のネットワークノード）を特定できます。
Another source of high working latency comes from network routers exposed to cross-traffic. As [Schlinker2019] indicated, these can become saturated during the peak hours of the day. Systematic testing of the working latency in routers under load can help improve both our understanding of latency and the impact of deployed infrastructure.
高い作業レイテンシのもう1つのソースは、トラフィック横断にさらされたネットワークルーターからのものです。[Schlinker2019]が示したように、これらは1日のピーク時間中に飽和状態になる可能性があります。負荷中のルーターの動作レイテンシの体系的なテストは、潜在性の理解と展開されたインフラストラクチャの影響の両方を改善するのに役立ちます。
The metrics for network quality can be roughly grouped into the following:
ネットワーク品質のメトリックは、大まかに以下にグループ化できます。
1. Availability metrics, which indicate whether the user can access the network at all.
1. ユーザーがネットワークにまったくアクセスできるかどうかを示す可用性メトリック。
2. Capacity metrics, which indicate whether the actual line capacity is sufficient to meet the user's demands.
2. 容量指標は、実際のライン容量がユーザーの要求を満たすのに十分かどうかを示します。
3. Latency metrics, which indicate if the user gets the data in a timely fashion.
3. ユーザーがタイムリーにデータを取得するかどうかを示すレイテンシメトリック。
4. Higher-order metrics, which include both the network metrics, such as inter-packet arrival time, and the application metrics, such as the mean time between rebuffering for video streaming.
4. パケット間到着時間などのネットワークメトリックと、ビデオストリーミングの拒絶までの平均時間などのアプリケーションメトリックの両方を含む高次メトリック。
The availability metrics can be seen as a derivative of either the capacity (zero capacity leading to zero availability) or the latency (infinite latency leading to zero availability).
可用性メトリックは、容量（ゼロ容量が可用性ゼロにつながるゼロ容量）またはレイテンシ（無限のレイテンシが可用性がゼロになる）の派生物として見ることができます。
Key points from the presentations and discussions included the following:
プレゼンテーションとディスカッションからの重要なポイントには、以下が含まれていました。
1. Availability and capacity are "hygienic factors" -- unless an application is capable of using extra capacity, end users will see little benefit from using over-provisioned lines.
1. 可用性と容量は「衛生的要因」です。アプリケーションが余分な容量を使用できない限り、エンドユーザーは過剰な導入されたラインを使用することでほとんど利益を得ません。
2. Working latency has a stronger correlation with the user experience than latency under an idle network load. Working latency can exceed the idle latency by order of magnitude.
2. 動作レイテンシは、アイドルネットワーク負荷の下での遅延よりもユーザーエクスペリエンスとの相関が強いです。動作レイテンシは、桁違いにアイドルレイテンシを超えることができます。
3. The RPM metric is a stable metric, with positive values being better, that may be more effective when communicating latency to end users.
3. RPMメトリックは安定したメトリックであり、正の値が優れているため、エンドユーザーにレイテンシを通信するとより効果的です。
4. The relationship between throughput and goodput can be effective in finding the saturation points, both in client-side [Paasch2021] and server-side [Schlinker2019] settings.
4. スループットとGoodputの関係は、クライアント側[Paasch2021]とサーバー側[Schlinker2019]設定の両方で、飽和点を見つけるのに効果的です。
5. Working latency depends on the algorithm choice for addressing endpoint congestion control and router queuing.
5. 動作レイテンシは、エンドポイントの混雑制御とルーターキューイングに対処するためのアルゴリズムの選択に依存します。
Finally, it was commonly agreed to that the best metrics are those that are actionable.
最後に、最良のメトリックは実用的なメトリックであることが一般的に合意されました。
In the cross-layer segment of the workshop, participants presented material on and discussed how to accurately measure exactly where problems occur. Discussion centered especially on the differences between physically wired and wireless connections and the difficulties of accurately determining problem spots when multiple different types of network segments are responsible for the quality. As an example, [Kerpez2021] showed that a limited bandwidth of 2.4 Ghz Wi-Fi bottlenecks the most frequently. In comparison, the wider bandwidth of the 5 Ghz Wi-Fi has only bottlenecked in 20% of observations.
ワークショップのクロスレイヤーセグメントでは、参加者が資料を提示し、問題が発生する場所を正確に測定する方法を議論しました。特に、物理的に有線接続とワイヤレス接続の違いと、複数の異なるタイプのネットワークセグメントが品質に責任を負っている場合に問題スポットを正確に決定することの難しさに集中しています。例として、[Kerpez2021]は、2.4 GHz Wi-Fiボトルネックの限られた帯域幅が最も頻繁にあることを示しました。それに比べて、5 GHz Wi-Fiのより広い帯域幅は、観測値の20％でのみボトルネックされています。
The participants agreed that no single component of a network connection has all the data required to measure the effects of the network performance on the quality of the end-user experience.
参加者は、ネットワーク接続の単一のコンポーネントが、エンドユーザーエクスペリエンスの品質に対するネットワークパフォーマンスの効果を測定するために必要なすべてのデータを持っていないことに同意しました。
* Applications that are running on the end-user devices have the best insight into their respective performance but have limited visibility into the behavior of the network itself and are unable to act based on their limited perspective.
* エンドユーザーデバイスで実行されているアプリケーションは、それぞれのパフォーマンスについて最高の洞察を持っていますが、ネットワーク自体の動作に対する可視性は限られており、限られた視点に基づいて行動することができません。
* ISPs have good insight into QoS considerations but are not able to infer the effect of the QoS metrics on the quality of end-user experiences.
* ISPはQoSの考慮事項について良い洞察を持っていますが、QoSメトリックの効果をエンドユーザーエクスペリエンスの品質に及ぼす影響を推測することはできません。
* Content providers have good insight into the aggregated behavior of the end users but lack the insight on what aspects of network performance are leading indicators of user behavior.
* コンテンツプロバイダーは、エンドユーザーの集計された動作についての洞察を十分に持っていますが、ネットワークパフォーマンスのどの側面がユーザーの動作の主要な指標であるかについての洞察がありません。
The workshop had identified the need for a standard and extensible way to exchange network performance characteristics. Such an exchange standard should address (at least) the following:
ワークショップは、ネットワークパフォーマンスの特性を交換するための標準的で拡張可能な方法の必要性を特定していました。このような交換基準は（少なくとも）次のことに対処する必要があります。
* A scalable way to capture the performance of multiple (potentially thousands of) endpoints.
* 複数の（潜在的に数千の）エンドポイントのパフォーマンスをキャプチャするスケーラブルな方法。
* The data exchange format should prevent data manipulation so that the different participants won't be able to game the mechanisms.
* データ交換形式は、さまざまな参加者がメカニズムをゲームにすることができないように、データの操作を防ぐ必要があります。
* Preservation of end-user privacy. In particular, federated learning approaches should be preferred so that no centralized entity has the access to the whole picture.
* エンドユーザープライバシーの保存。特に、集中型のエンティティが全体像にアクセスできるように、フェデレーション学習アプローチを優先する必要があります。
* A transparent model for giving the different actors on a network connection an incentive to share the performance data they collect.
* ネットワーク接続上のさまざまなアクターに、収集するパフォーマンスデータを共有するインセンティブを与えるための透明なモデル。
* An accompanying set of tools to analyze the data.
* データを分析するためのツールの付随するセット。
Commonly, there's a tight coupling between collecting performance metrics, interpreting those metrics, and acting upon the interpretation. Unfortunately, such a model is not the best for successfully exchanging cross-layer data, as:
一般的に、パフォーマンスメトリックの収集、それらのメトリックの解釈、および解釈に基づいて行動することとの間には、緊密な結合があります。残念ながら、このようなモデルは、次のように、クロスレイヤーデータを正常に交換するのに最適ではありません。
* actors that are able to collect particular performance metrics (e.g., the TCP RTT) do not necessarily have the context necessary for a meaningful interpretation,
* 特定のパフォーマンスメトリック（TCP RTTなど）を収集できるアクターには、必ずしも意味のある解釈に必要なコンテキストがあるわけではありません。
* the actors that have the context and the computational/storage capacity to interpret metrics do not necessarily have the ability to control the behavior of the network/application, and
* コンテキストと計算/ストレージ容量を持つアクターは、メトリックを解釈するための計算/ストレージ容量が必ずしもネットワーク/アプリケーションの動作を制御する能力を持っているわけではありません。
* the actors that can control the behavior of networks and/or applications typically do not have access to complete measurement data.
* ネットワークやアプリケーションの動作を制御できるアクターは、通常、完全な測定データにアクセスできません。
The participants agreed that it is important to separate the above three aspects, so that:
参加者は、上記の3つの側面を分離することが重要であることに同意しました。
* the different actors that have the data, but not the ability to interpret and/or act upon it, should publish their measured data and
* データを持っているが、それを解釈および/または行動する能力ではないさまざまなアクターは、測定されたデータを公開する必要があります。
* the actors that have the expertise in interpreting and synthesizing performance data should publish the results of their interpretations.
* パフォーマンスデータの解釈と統合の専門知識を持つアクターは、解釈の結果を公開する必要があります。
Preserving the privacy of Internet end users is a difficult requirement to meet when addressing this problem space. There is an intrinsic trade-off between collecting more data about user activities and infringing on their privacy while doing so. Participants agreed that observability across multiple layers is necessary for an accurate measurement of the network quality, but doing so in a way that minimizes privacy leakage is an open question.
インターネットエンドユーザーのプライバシーを保存することは、この問題の分野に対処する際に満たすのが難しい要件です。ユーザーアクティビティに関するより多くのデータを収集することと、そうしている間にプライバシーを侵害することとの間には、本質的なトレードオフがあります。参加者は、ネットワークの品質を正確に測定するためには、複数のレイヤーにわたる観察可能性が必要であることに同意しましたが、プライバシーの漏れを最小限に抑える方法でそうすることは、未解決の問題です。
* The following TCP protocol metrics have been found to be effective and are available for passive measurement:
* 以下のTCPプロトコルメトリックは効果的であることがわかっており、パッシブ測定に利用できます。
- TCP connection latency measured using selective acknowledgment (SACK) or acknowledgment (ACK) timing, as well as the timing between TCP retransmission events, are good proxies for end-to-end RTT measurements.
- TCP接続レイテンシは、選択的承認（SACK）または確認（ACK）タイミングを使用して測定され、TCP再送信イベント間のタイミングは、エンドツーエンドのRTT測定の優れたプロキシです。
- On the Linux platform, the tcp_info structure is the de facto standard for an application to inspect the performance of kernel-space networking. However, there is no equivalent de facto standard for user-space networking.
- Linuxプラットフォームでは、TCP_INFO構造は、カーネル空間ネットワーキングのパフォーマンスを検査するためのアプリケーションの事実上の標準です。ただし、ユーザースペースネットワーキングには同等の事実上の標準はありません。
* The QUIC and MASQUE protocols make passive performance measurements more challenging.
* QUICおよびマスクプロトコルにより、パッシブパフォーマンス測定がより困難になります。
- An approach that uses federated measurement/hierarchical aggregation may be more valuable for these protocols.
- フェデレート測定/階層集約を使用するアプローチは、これらのプロトコルにとってより価値があるかもしれません。
- The QLOG format seems to be the most mature candidate for such an exchange.
- QLOG形式は、そのような交換の最も成熟した候補のようです。
The ownership of the Internet is spread across multiple administrative domains, making measurement of end-to-end performance data difficult. Furthermore, the immense scale of the Internet makes aggregation and analysis of this difficult. [Marx2021] presented a simple logging format that could potentially be used to collect and aggregate data from different layers.
インターネットの所有権は複数の管理ドメインに広がっており、エンドツーエンドのパフォーマンスデータの測定が困難になっています。さらに、インターネットの計り知れない規模により、この総合と分析が困難になります。[MALX2021]は、異なるレイヤーからデータを収集および集約するために使用できる簡単なロギング形式を提示しました。
Another aspect of the cross-layer collaboration hampering measurement is that the majority of current algorithms do not explicitly provide performance data that can be used in cross-layer analysis. The IETF community could be more diligent in identifying each protocol's key performance indicators and exposing them as part of the protocol specification.
クロスレイヤーコラボレーションの妨害測定のもう1つの側面は、現在のアルゴリズムの大部分が、架橋分析で使用できるパフォーマンスデータを明示的に提供していないことです。IETFコミュニティは、各プロトコルの主要なパフォーマンスインジケーターを識別し、プロトコル仕様の一部としてそれらを公開することに熱心になる可能性があります。
Despite all these challenges, it should still be possible to perform limited-scope studies in order to have a better understanding of how user quality is affected by the interaction of the different components that constitute the Internet. Furthermore, recent development of federated learning algorithms suggests that it might be possible to perform cross-layer performance measurements while preserving user privacy.
これらすべての課題にもかかわらず、インターネットを構成するさまざまなコンポーネントの相互作用によってユーザー品質がどのように影響を受けるかをよりよく理解するために、限られたスコープ研究を実行することが可能であるべきです。さらに、最近のフェデレーション学習アルゴリズムの開発は、ユーザーのプライバシーを維持しながら、潜在層のパフォーマンス測定を実行することが可能である可能性があることを示唆しています。
With the advent of the low latency, low loss, and scalable throughput (L4S) congestion notification and control, there is an even higher need for the transport protocols and the underlying hardware to work in unison.
低レイテンシ、低損失、スケーラブルなスループット（L4S）混雑通知と制御の出現により、輸送プロトコルと基礎となるハードウェアが一斉に動作する必要性がさらに高くなります。
At the time of the workshop, the typical home router uses a single FIFO queue that is large enough to allow amortizing the lower-layer header overhead across multiple transport PDUs. These designs worked well with the cubic congestion control algorithm, yet the newer generation of algorithms can operate on much smaller queues. To fully support latencies less than 1 ms, the home router needs to work efficiently on sequential transmissions of just a few segments vs. being optimized for large packet bursts.
ワークショップの時点で、典型的なホームルーターは、複数の輸送PDUにわたって低層ヘッダーのオーバーヘッドを償却できるほど十分に大きい単一のFIFOキューを使用しています。これらの設計は、立方輻輳制御アルゴリズムでうまく機能しましたが、新しい生成のアルゴリズムは、はるかに小さなキューで動作できます。1ミリ秒未満のレイテンシを完全にサポートするには、ホームルーターは、大規模なパケットバーストに最適化されている場合と、ほんの数セグメントの連続的な送信に効率的に動作する必要があります。
Another design trait common in home routers is the use of packet aggregation to further amortize the overhead added by the lower-layer headers. Specifically, multiple IP datagrams are combined into a single, large transfer frame. However, this aggregation can add up to 10 ms to the packet sojourn delay.
ホームルーターで一般的なもう1つの設計特性は、低層ヘッダーによって追加されたオーバーヘッドをさらに除去するためにパケット集約を使用することです。具体的には、複数のIPデータグラムが単一の大きな転送フレームに結合されます。ただし、この集約は、パケットの滞在遅延に最大10ミリ秒になる可能性があります。
Following the famous "you can't improve what you don't measure" adage, it is important to expose these aggregation delays in a way that would allow identifying the source of the bottlenecks and making hardware more suitable for the next generation of transport protocols.
有名な「あなたが測定しないものを改善できない」格付きに続いて、これらの集計の遅延を、ボトルネックのソースを特定し、次世代の輸送プロトコルにより適したものにすることを可能にする方法で公開することが重要です。
* Significant differences exist in the characteristics of metrics to be measured and the required optimizations needed in wireless vs. wired networks.
* 測定するメトリックの特性には大きな違いがあり、ワイヤレスネットワークと有線ネットワークで必要な最適化が必要です。
* Identification of an issue's root cause is hampered by the challenges in measuring multi-segment network paths.
* 問題の根本原因の特定は、マルチセグメントネットワークパスの測定における課題によって妨げられています。
* No single component of a network connection has all the data required to measure the effects of the complete network performance on the quality of the end-user experience.
* ネットワーク接続の単一コンポーネントには、エンドユーザーエクスペリエンスの品質に対する完全なネットワークパフォーマンスの効果を測定するために必要なすべてのデータがありません。
* Actionable results require both proper collection and interpretation.
* 実用的な結果には、適切な収集と解釈の両方が必要です。
* Coordination among network providers is important to successfully improve the measurement of end-user experiences.
* ネットワークプロバイダー間の調整は、エンドユーザーエクスペリエンスの測定をうまく改善するために重要です。
* Simultaneously providing accurate measurements while preserving end-user privacy is challenging.
* エンドユーザーのプライバシーを維持しながら正確な測定値を同時に提供することは困難です。
* Passive measurements from protocol implementations may provide beneficial data.
* プロトコルの実装からのパッシブ測定は、有益なデータを提供する場合があります。
Finally, in the synthesis section of the workshop, the presentations and discussions concentrated on the next steps likely needed to make forward progress. Of particular concern is how to bring forward measurements that can make sense to end users trying to select between various networking subscription options.
最後に、ワークショップの合成セクションで、プレゼンテーションと議論は、前進するために必要な次のステップに集中していました。特に懸念されるのは、さまざまなネットワークサブスクリプションオプションを選択しようとするエンドユーザーにとって理にかなっている測定を進める方法です。
One important consideration is how decisions can be made and what actions can be taken based on collected metrics. Measurements must be integrated with applications in order to get true application views of congestion, as measurements over different infrastructure or via other applications may return incorrect results. Congestion itself can be a temporary problem, and mitigation strategies may need to be different depending on whether it is expected to be a short-term or long-term phenomenon. A significant challenge exists in measuring short-term problems, driving the need for continuous measurements to ensure critical moments and long-term trends are captured. For short-term problems, workshop participants debated whether an issue that goes away is indeed a problem or is a sign that a network is properly adapting and self-recovering.
重要な考慮事項の1つは、収集されたメトリックに基づいて決定を下す方法と、どのようなアクションを実行できるかです。さまざまなインフラストラクチャを介した測定または他のアプリケーションを介して誤った結果を返す可能性があるため、混雑の真のアプリケーションビューを取得するには、測定値をアプリケーションと統合する必要があります。混雑自体は一時的な問題である可能性があり、短期的な現象か長期的な現象であるかによって、緩和戦略は異なる必要がある場合があります。短期的な問題を測定し、継続的な測定の必要性を促進して、重要な瞬間と長期的な傾向を確保することには重要な課題が存在します。短期的な問題については、ワークショップの参加者は、消える問題が実際に問題であるか、ネットワークが適切に適応し、自己回復していることの兆候であるかどうかを議論しました。
Important consideration must be taken when constructing metrics in order to understand the results. Measurements can also be affected by individual packet characteristics -- differently sized packets typically have a linear relationship with their delay. With this in mind, measurements can be divided into a delay based on geographical distances, a packet-size serialization delay, and a variable (noise) delay. Each of these three sub-component delays can be different and individually measured across each segment in a multi-hop path. Variable delay can also be significantly impacted by external factors, such as bufferbloat, routing changes, network load sharing, and other local or remote changes in performance. Network measurements, especially load-specific tests, must also be run long enough to ensure that any problems associated with buffering, queuing, etc. are captured. Measurement technologies should also distinguish between upstream and downstream measurements, as well as measure the difference between end-to-end paths and sub-path measurements.
結果を理解するためにメトリックを構築する際には、重要な考慮が必要です。測定は、個々のパケット特性の影響を受ける可能性があります。異なるサイズのパケットは、通常、遅延と線形関係を持っています。これを念頭に置いて、測定は、地理的距離、パケットサイズのシリアル化遅延、および変数（ノイズ）遅延に基づく遅延に分割できます。これら3つのサブコンポーネントの遅延はそれぞれ異なる可能性があり、マルチホップパスの各セグメント間で個別に測定できます。変動遅延は、バッファーブロート、ルーティングの変更、ネットワーク負荷共有、その他のローカルまたはリモートのパフォーマンスの変更などの外部要因によっても大きな影響を受ける可能性があります。ネットワーク測定、特に負荷固有のテストは、バッファリング、キューイングなどに関連する問題がキャプチャされるように、十分に長く実行する必要があります。また、測定技術は、上流と下流の測定値を区別し、エンドツーエンドパスとサブパス測定の違いを測定する必要があります。
Determining end-user needs requires informative measurements and metrics. How do we provide the users with the service they need or want? Is it possible for users to even voice their desires effectively? Only high-level, simplistic answers like "reliability", "capacity", and "service bundling" are typical answers given in end-user surveys. Technical requirements that operators can consume, like "low-latency" and "congestion avoidance", are not terms known to and used by end users.
エンドユーザーのニーズを決定するには、有益な測定とメトリックが必要です。ユーザーに必要なサービスまたは必要なサービスをどのように提供しますか？ユーザーが自分の欲望を効果的に表明することさえ可能ですか？「信頼性」、「容量」、「サービスバンドル」などの高レベルの単純な答えのみが、エンドユーザー調査で示されています。「低遅延」や「混雑回避」など、オペレーターが消費できる技術的要件は、エンドユーザーによって知られておらず、使用されている用語ではありません。
Example metrics useful to end users might include the number of users supported by a service and the number of applications or streams that a network can support. An example solution to combat networking issues include incentive-based traffic management strategies (e.g., an application requesting lower latency may also mean accepting lower bandwidth). User-perceived latency must be considered, not just network latency -- user experience in-application to in-server latency and network-to-network measurements may only be studying the lowest-level latency. Thus, picking the right protocol to use in a measurement is critical in order to match user experience (for example, users do not transmit data over ICMP, even though it is a common measurement tool).
エンドユーザーに役立つメトリックの例には、サービスでサポートされているユーザーの数と、ネットワークがサポートできるアプリケーションまたはストリームの数が含まれる場合があります。戦闘ネットワーキングの問題に対する解決策の例には、インセンティブベースのトラフィック管理戦略が含まれます（たとえば、低遅延を要求するアプリケーションは、より低い帯域幅を受け入れることも意味する場合があります）。ネットワークレイテンシだけでなく、ユーザーが認識しているレイテンシを考慮する必要があります。これは、サーバー内のレイテンシおよびネットワーク間測定へのアプリケーションでのユーザーエクスペリエンスが、最低レベルのレイテンシのみを調査している可能性があります。したがって、ユーザーエクスペリエンスを一致させるには、測定で使用する適切なプロトコルを選択することが重要です（たとえば、ユーザーは一般的な測定ツールであるにもかかわらず、ICMPを介してデータを送信しません）。
In-application measurements should consider how to measure different types of applications, such as video streaming, file sharing, multi-user gaming, and real-time voice communications. It may be that asking users for what trade-offs they are willing to accept would be a helpful approach: would they rather have a network with low latency or a network with higher bandwidth? Gamers may make different decisions than home office users or content producers, for example.
アプリケーション測定では、ビデオストリーミング、ファイル共有、マルチユーザーゲーム、リアルタイムの音声通信など、さまざまな種類のアプリケーションを測定する方法を検討する必要があります。ユーザーに、受け入れようとするトレードオフをユーザーに尋ねることは有益なアプローチになるかもしれません。むしろ低下のネットワークや帯域幅の高いネットワークを持っているのでしょうか？たとえば、ゲーマーはホームオフィスのユーザーやコンテンツプロデューサーとは異なる決定を下す場合があります。
Furthermore, how can users make these trade-offs in a fair manner that does not impact other users? There is a tension between solutions in this space vs. the cost associated with solving these problems, as well as which customers are willing to front these improvement costs.
さらに、他のユーザーに影響を与えない公正な方法でこれらのトレードオフをどのように行うことができますか？これらの問題の解決に関連するコストと、これらの改善コストを前提とする顧客がいずれかと同様に、このスペースにソリューション間に緊張があります。
Challenges in providing higher-priority traffic to users centers around the ability for networks to be willing to listen to client requests for higher incentives, even though commercial interests may not flow to them without a cost incentive. Shared mediums in general are subject to oversubscribing, such that the number of users a network can support is either accurate on an underutilized network or may assume an average bandwidth or other usage metric that fails to be accurate during utilization spikes. Individual metrics are also affected by in-home devices from cheap routers to microwaves and by (multi-)user behaviors during tests. Thus, a single metric alone or a single reading without context may not be useful in assisting a user or operator to determine where the problem source actually is.
より優先順位のトラフィックをユーザーに提供する際の課題は、コストのインセンティブなしでは商業的利益が彼らに流れない場合でも、より高いインセンティブのクライアント要求に喜んで耳を傾けることを望んでいることを中心にしています。一般に共有媒体はオーバーサブスクライティングの対象となります。これにより、ネットワークがサポートできるユーザーの数は、十分に活用されていないネットワークで正確であるか、使用スパイク中に正確になっていない平均帯域幅またはその他の使用メトリックを想定する場合があります。個々のメトリックは、安価なルーターからマイクロ波への在宅デバイスや、テスト中の（マルチ）ユーザーの動作の影響も受けます。したがって、単一のメトリックのみまたはコンテキストのない単一の読み取り値は、ユーザーまたはオペレーターが実際にどこにあるかを判断するのを支援するのに役立ちません。
User comprehension of a network remains a challenging problem. Multiple workshop participants argued for a single number (potentially calculated with a weighted aggregation formula) or a small number of measurements per expected usage (e.g., a "gaming" score vs. a "content producer" score). Many agreed that some users may instead prefer to consume simplified or color-coded ratings (e.g., good/better/best, red/yellow/green, or bronze/gold/platinum).
ネットワークのユーザーの理解は、依然として困難な問題です。複数のワークショップ参加者は、単一の数（潜在的に加重集約式で計算される可能性があります）または予想される使用法（例：「コンテンツプロデューサー」スコアと「ゲーム」スコア対「ゲーム」スコアなど）を主張しました。一部のユーザーは、代わりに単純化または色分けされた評価（例：良い/ベスト/ベスト、赤/黄色/緑、またはブロンズ/ゴールド/プラチナ）を消費することを好むことに同意しました。
* Some proposed metrics:
* いくつかの提案された指標：
- Round-trips Per Minute (RPM)
- 毎分往復（rpm）
- users per network
- ネットワークごとのユーザー
- latency
- 遅延
- 99% latency and bandwidth
- 99％のレイテンシと帯域幅
* Median and mean measurements are distractions from the real problems.
* 中央値と平均測定値は、実際の問題からの気晴らしです。
* Shared network usage greatly affects quality.
* 共有ネットワークの使用は品質に大きく影響します。
* Long measurements are needed to capture all facets of potential network bottlenecks.
* 潜在的なネットワークボトルネックのすべてのファセットをキャプチャするには、長い測定が必要です。
* Better-funded research in all these areas is needed for progress.
* これらすべての分野での資金精通の研究が進歩に必要です。
* End users will best understand a simplified score or ranking system.
* エンドユーザーは、簡素化されたスコアまたはランキングシステムを最もよく理解します。
During the final hour of the three-day workshop, statements that the group deemed to be summary statements were gathered. Later, any statements that were in contention were discarded (listed further below for completeness). For this document, the authors took the original list and divided it into rough categories, applied some suggested edits discussed on the mailing list, and further edited for clarity and to provide context.
3日間のワークショップの最後の時間に、グループが要約声明とみなした声明が収集されました。その後、競合中の声明は廃棄されました（完全性のためにさらに以下にリストされています）。このドキュメントでは、著者は元のリストを取り、それを大まかなカテゴリに分割し、メーリングリストで説明したいくつかの提案された編集を適用し、明確にしてコンテキストを提供するためにさらに編集しました。
1. Bandwidth is necessary but not alone sufficient.
1. 帯域幅は必要ですが、単独では十分ではありません。
2. In many cases, Internet users don't need more bandwidth but rather need "better bandwidth", i.e., they need other improvements to their connectivity.
2. 多くの場合、インターネットユーザーはこれ以上の帯域幅を必要としませんが、「より良い帯域幅」が必要です。つまり、接続性の他の改善が必要です。
3. We need both active and passive measurements -- passive measurements can provide historical debugging.
3. アクティブ測定とパッシブの両方の測定が必要です。パッシブ測定では、歴史的なデバッグを提供できます。
4. We need passive measurements to be continuous, archivable, and queriable, including reliability/connectivity measurements.
4. 信頼性/接続性測定を含む、連続的でアーカイブ可能な、およびクエリ可能なパッシブ測定が必要です。
5. A really meaningful metric for users is whether their application will work properly or fail because of a lack of a network with sufficient characteristics.
5. ユーザーにとって本当に意味のあるメトリックは、ユーザーが十分な特性を持つネットワークがないためにアプリケーションが適切に機能するか失敗するかです。
6. A useful metric for goodness must actually incentivize goodness -- good metrics should be actionable to help drive industries towards improvement.
6. 善のための有用なメトリックは、実際に善を奨励する必要があります。産業を改善に導くのに役立つ良い指標は実用的でなければなりません。
7. A lower-latency Internet, however achieved, would benefit all end users.
7. しかし、より低い低下のインターネットは、しかし達成されたものの、すべてのエンドユーザーに利益をもたらすでしょう。
1. Round-trips Per Minute (RPM) is a useful, consumable metric.
1. 1分あたりの往復（RPM）は、有用で消耗品のメトリックです。
2. We need a usable tool that fills the current gap between network reachability, latency, and speed tests.
2. ネットワークの到達可能性、レイテンシ、速度テストの間の現在のギャップを埋める使用可能なツールが必要です。
3. End users that want to be involved in QoS decisions should be able to voice their needs and desires.
3. QOSの決定に関与したいエンドユーザーは、自分のニーズと欲求を表明できるはずです。
4. Applications are needed that can perform and report good quality measurements in order to identify insufficient points in network access.
4. ネットワークアクセスに不十分なポイントを特定するために、良質の測定を実行および報告できるアプリケーションが必要です。
5. Research done by regulators indicate that users/consumers prefer a simple metric per application, which frequently resolves to whether the application will work properly or not.
5. 規制当局による調査は、ユーザー/消費者がアプリケーションごとの単純なメトリックを好むことを示しています。これは、アプリケーションが適切に機能するかどうかを頻繁に解決します。
6. New measurements and QoS or QoE techniques should not rely only or depend on reading TCP headers.
6. 新しい測定とQoSまたはQOEテクニックは、TCPヘッダーの読み取りに依存したり、依存したりするべきではありません。
7. It is clear from developers of interactive applications and from network operators that lower latency is a strong factor in user QoE. However, metrics are lacking to support this statement directly.
7. インタラクティブなアプリケーションの開発者から、およびネットワークオペレーターから、レイテンシが低いことがユーザーQOEの強力な要因であることは明らかです。ただし、この声明を直接サポートするメトリックは不足しています。
1. Latency mean and medians are distractions from better measurements.
1. 遅延平均と中央値は、より良い測定から気を散らすものです。
2. It is frustrating to only measure network services without simultaneously improving those services.
2. これらのサービスを同時に改善することなく、ネットワークサービスのみを測定することはイライラします。
3. Stakeholder incentives aren't aligned for easy wins in this space. Incentives are needed to motivate improvements in public network access. Measurements may be one step towards driving competitive market incentives.
3. 利害関係者のインセンティブは、この分野での簡単な勝利のために調整されていません。パブリックネットワークアクセスの改善を動機付けるためには、インセンティブが必要です。測定は、競争力のある市場インセンティブを推進するための1つのステップかもしれません。
4. For future-proof networking, it is important to measure the ecological impact of material and energy usage.
4. 将来の耐性ネットワーキングの場合、材料とエネルギーの使用の生態学的影響を測定することが重要です。
5. We do not have incontrovertible evidence that any one metric (e.g., latency or speed) is more important than others to persuade device vendors to concentrate on any one optimization.
5. 1つのメトリック（潜時や速度など）が他のメトリックよりも重要であり、デバイスベンダーがいずれかの最適化に集中するよう説得するという議論の余地のない証拠はありません。
Additional statements were discussed and recorded that did not have consensus of the group at the time, but they are listed here for completeness:
当時グループのコンセンサスがなかった追加の声明が議論され、記録されましたが、完全性のためにここにリストされています。
1. We do not have incontrovertible evidence that bufferbloat is a prevalent problem.
1. Bufferbloatが一般的な問題であるという議論の余地のない証拠はありません。
2. The measurement needs to support reporting localization in order to find problems. Specifically:
2. 測定は、問題を見つけるために報告ローカリゼーションをサポートする必要があります。具体的には：
* Detecting a problem is not sufficient if you can't find the location.
* 場所が見つからない場合、問題を検出するだけでは不十分です。
* Need more than just English -- different localization concerns.
* 英語だけでなく、異なるローカリゼーションの懸念事項が必要です。
3. Stakeholder incentives aren't aligned for easy wins in this space.
3. 利害関係者のインセンティブは、この分野での簡単な勝利のために調整されていません。
There was discussion during the workshop about where future work should be performed. The group agreed that some work could be done more immediately within existing IETF working groups (e.g., IPPM, DetNet, and RAW), while other longer-term research may be needed in IRTF groups.
ワークショップで、将来の作業がどこに行われるべきかについての議論がありました。グループは、IRTFグループでは他の長期的な研究が必要になるのに対し、既存のIETFワーキンググループ（例：IPPM、DetNet、RAW）内でいくつかの作業をすぐに行うことができることに同意しました。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
A few security-relevant topics were discussed at the workshop, including but not limited to:
いくつかのセキュリティ関連のトピックがワークショップで議論されました。
* what prioritization techniques can work without invading the privacy of the communicating parties and
* コミュニケーションパーティのプライバシーに侵入することなく、どのような優先順位付けテクニックが機能しますか
* how oversubscribed networks can essentially be viewed as a DDoS attack.
* ネットワークをオーバーサブスクライブする方法は、本質的にDDOS攻撃と見なすことができます。
[Aldabbagh2021] Aldabbagh, A., "Regulatory perspective on measuring network quality for end-users", September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/2021-09-07-Aldabbagh-Ofcom-presentationt-to-IAB-1v00-1.pdf>.
[Aldabbagh2021] Aldabbagh、A。、「エンドユーザーのネットワーク品質の測定に関する規制の観点」、2021年9月、<https://www.iab.org/wp-content/iab-uploads/2021/09/2021-09-07-Aldabbagh-ofcom-presentationt-to-iab-1v00-1.pdf>。
[Arkko2021] Arkko, J. and M. Kühlewind, "Observability is needed to improve network quality", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/iab-position-paper-observability.pdf>.
[Arkko2021] Arkko、J。およびM.Kühlewind、「ネットワーク品質を改善するには観察可能性が必要です」、2021年8月<https://www.iab.org/wp-content/iab-uploads/2021/09/iab-Position-Paper-Observability.pdf>。
[Balasubramanian2021] Balasubramanian, P., "Transport Layer Statistics for Network Quality", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/transportstatsquality.pdf>.
[Balasubramanian2021] Balasubramanian、P。、「ネットワーク品質のための輸送層統計」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/transportstatsquality.pdf>。
[Briscoe2021] Briscoe, B., White, G., Goel, V., and K. De Schepper, "A Single Common Metric to Characterize Varying Packet Delay", September 2021, <https://www.iab.org/wp-content/ IAB-uploads/2021/09/single-delay-metric-1.pdf>.
[Briscoe2021] Briscoe、B.、White、G.、Goel、V。、およびK. de Schepper、「さまざまなパケット遅延を特徴付ける単一の共通メトリック」、2021年9月、<https://www.iab.org/wp-content/iab-uploads/2021/09/single-delay-metric-1.pdf>。
[Casas2021] Casas, P., "10 Years of Internet-QoE Measurements Video, Cloud, Conferencing, Web and Apps. What do we need from the Network Side?", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ net_quality_internet_qoe_CASAS.pdf>.
[CASAS2021] CASAS、P。、「10年間のインターネットQOE測定ビデオ、クラウド、会議、Web、アプリ。ネットワーク側から何が必要ですか？」、2021年8月、<https://www.iab.org/wp-content/iab-uploads/2021/09/net_quality_internet_qoe_casas.pdf>。
[Cheshire2021] Cheshire, S., "The Internet is a Shared Network", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ draft-cheshire-internet-is-shared-00b.pdf>.
[Cheshire2021] Cheshire、S。、「インターネットは共有ネットワークです」、2021年8月、<https://www.iab.org/wp-content/iab-uploads/2021/09/ Draft-cheshire-internet-is-shared-00b.pdf>。
[Davies2021] Davies, N. and P. Thompson, "Measuring Network Impact on Application Outcomes Using Quality Attenuation", September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ PNSol-et-al-Submission-to-Measuring-Network-Quality-for-End-Users-1.pdf>.
[Davies2021] Davies、N。およびP. Thompson、「品質減衰を使用したアプリケーションの結果に対するネットワークの影響の測定2021年9月、<https://www.iab.org/wp-content/iab-uploads/2021/09/pnsol-et-al-submission to deasuring-network-for-end-users-1.pdf>。
[DeSchepper2021] De Schepper, K., Tilmans, O., and G. Dion, "Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss", February 2021, <https://www.iab.org/ wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Low-Latency-measurement-workshop-20210802.pdf>.
[Deschepper2021] De Schepper、K.、Tilmans、O.、およびG. Dion、「パケット損失なしの低いキューイングレイテンシに対するハードウェアサポートの課題と機会」、2021年2月、<https://www.iab.org/ wp-content/iab-uploads/2021/09/nokia-iab-measuring-metwork-quality-latow-latency-measurementworkshop-20210802.pdf>。
[Dion2021] Dion, G., De Schepper, K., and O. Tilmans, "Focusing on latency, not throughput, to provide a better internet experience and network quality", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Improving-and-focusing-on-latency-.pdf>.
[Dion2021] Dion、G.、De Schepper、K。、およびO. Tilmans、「スループットではなくレイテンシに焦点を当てて、より良いインターネットエクスペリエンスとネットワーク品質を提供する」、2021年8月、<https：//www.iab。org/wp-content/iab-uploads/2021/09/nokia-iab-measuring-measuring-network-quality-refroving-ausing-on-latency-.pdf>。
[Fabini2021] Fabini, J., "Network Quality from an End User Perspective", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Fabini-IAB-NetworkQuality.txt>.
[Fabini2021] Fabini、J。、「エンドユーザーの観点からのネットワーク品質」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/fabini-iab-networkquality。txt>。
[FCC_MBA] FCC, "Measuring Broadband America", <https://www.fcc.gov/general/measuring-broadband-america>.
[fcc_mba] fcc、「測定ブロードバンドアメリカ」、<https://www.fcc.gov/general/measuring-broadband-america>。
[FCC_MBA_methodology] FCC, "Measuring Broadband America - Open Methodology", <https://www.fcc.gov/general/measuring-broadband-america-open-methodology>.
[fcc_mba_methodology] fcc、「ブロードバンドアメリカの測定 - オープン方法論」、<https://www.fcc.gov/general/measuring-broadband-america-open-methodology>。
[Foulkes2021] Foulkes, J., "Metrics helpful in assessing Internet Quality", September 2021, <https://www.iab.org/wp-content/ IAB-uploads/2021/09/ IAB_Metrics_helpful_in_assessing_Internet_Quality.pdf>.
[Foulkes2021] Foulkes、J。、「インターネットの品質の評価に役立つメトリック」、2021年9月、<https://www.iab.org/wp-content/ iab-uploads/2021/09/iab_metrics_helpful_in_assessing
[Ghai2021] Ghai, R., "Using TCP Connect Latency for measuring CX and Network Optimization", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ xfinity-wifi-ietf-iab-v2-1.pdf>.
[Ghai2021] Ghai、R。、「CXとネットワークの最適化を測定するためにTCP接続レイテンシを使用」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/ xfinity-wifi-ietf-iab-v2-1.pdf>。
[Iyengar2021] Iyengar, J., "The Internet Exists In Its Use", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ The-Internet-Exists-In-Its-Use.pdf>.
[iyengar2021] iyengar、J。、「インターネットはその使用に存在します」、2021年8月<https://www.iab.org/wp-content/iab-uploads/2021/09/ the-internet-exists-in-in-in-its-use.pdf>。
[Kerpez2021] Shafiei, J., Kerpez, K., Cioffi, J., Chow, P., and D. Bousaber, "Wi-Fi and Broadband Data", September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Wi-Fi-Report-ASSIA.pdf>.
[Kerpez2021] Shafiei、J.、Kerpez、K.、Cioffi、J.、Chow、P。、およびD. Bousaber、「Wi-Fi and Broadband Data」、2021年9月、<https://www.iab.org/wp-content/iab-uploads/2021/09/wi-fi-report-assia.pdf>。
[Kilkki2021] Kilkki, K. and B. Finley, "In Search of Lost QoS", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Kilkki-In-Search-of-Lost-QoS.pdf>.
[Kilkki2021] Kilkki、K。and B. Finley、「Lost Qosを探して」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/kilkki-in-Seart-of-lost-qos.pdf>。
[Laki2021] Nadas, S., Varga, B., Contreras, L.M., and S. Laki, "Incentive-Based Traffic Management and QoS Measurements", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/11/CamRdy-IAB_user_meas_WS_Nadas_et_al_IncentiveBasedTMwQoS.pdf>.
[Laki2021] Nadas、S.、Varga、B.、Contreras、L.M.、およびS. Laki、「インセンティブベースのトラフィック管理とQoS測定」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/11/camrdy-iab_user_meas_ws_nadas_et_al_incentivebasedtmwqos.pdf>。
[Liubogoshchev2021] Liubogoshchev, M., "Cross-layer Cooperation for Better Network Service", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Cross-layer-Cooperation-for-Better-Network-Service-2.pdf>.
[liubogoshchev2021] liubogoshchev、M。、「より良いネットワークサービスのためのクロスレイヤー協力」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/cross-leayer-cooperation-better-network-service-2.pdf>。
[MacMillian2021] MacMillian, K. and N. Feamster, "Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers", February 2021, <https://www.iab.org/wp-content/ IAB-uploads/2021/09/2021_nqw_lul.pdf>.
[Macmillian2021] Macmillian、K。およびN. Feamster、「速度テストを超えて：異なる速度層にわたって負荷下での遅延の測定」、2021年2月、<https://www.iab.org/wp-content/ iab-uploads/2021/09/2021_NQW_LUL.pdf>。
[Marx2021] Marx, R. and J. Herbots, "Merge Those Metrics: Towards Holistic (Protocol) Logging", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ MergeThoseMetrics_Marx_Jul2021.pdf>.
[Marx2021] Marx、R。およびJ. Herbots、「それらの指標をマージ：Towarlic（Protocol）Logging」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/ mergethosemetrics_marx_jul2021.pdf>。
[Mathis2021] Mathis, M., "Preliminary Longitudinal Study of Internet Responsiveness", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Preliminary-Longitudinal-Study-of-Internet-Responsiveness-1.pdf>.
[Mathis2021] Mathis、M。、「インターネット応答性の予備的な縦断的研究」、2021年8月、<https://www.iab.org/wp-content/iab-uploads/2021/09/preliminary-longitudinal-study-t-internet-responsivension-1.pdf>。
[McIntyre2021] Paasch, C., McIntyre, K., Shapira, O., Meyer, R., and S. Cheshire, "An end-user approach to an Internet Score", September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Score-2.pdf>.
[McIntyre2021] Paasch、C.、McIntyre、K.、Shapira、O.、Meyer、R。、およびS. Cheshire、「インターネットスコアへのエンドユーザーアプローチ」、2021年9月、<https：// www。iab.org/wp-content/iab-uploads/2021/09/internet-score-2.pdf>。
[Michel2021] Michel, F. and O. Bonaventure, "Packet delivery time as a tie-breaker for assessing Wi-Fi access points", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ camera_ready_Packet_delivery_time_as_a_tie_breaker_for_ass essing_Wi_Fi_access_points.pdf>.
[Michel2021] Michel、F。およびO. Bonaventure、「Wi-Fiアクセスポイントを評価するためのタイブレーカーとしてのパケット配信時間」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/camera_ready_packet_delivery_time_as_a_tie_breaker_ass essing_wi_fi_access_points.pdf>。
[Mirsky2021] Mirsky, G., Min, X., Mishra, G., and L. Han, "The error performance metric in a packet-switched network", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ IAB-worshop-Error-performance-measurement-in-packet-switched-networks.pdf>.
[Mirsky2021] Mirsky、G.、Min、X.、Mishra、G。、およびL. Han、「パケットスイッチネットワークのエラーパフォーマンスメトリック」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/iab-worshop-error-performance-measurement-in-packet-switched-networks.pdf>。
[Morton2021] Morton, A. C., "Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?", Work in Progress, Internet-Draft, draft-morton-ippm-pipe-dream-01, 6 September 2021, <https://datatracker.ietf.org/doc/html/ draft-morton-ippm-pipe-dream-01>.
[Morton2021] Morton、A。C.、「ドリームパイプまたはパイプドリーム：ユーザーは何を望んでいますか（どのように保証できますか）？」、2021年9月6日、<https://datatracker.ietf.org/doc/html/ draft-morton-ippm-pipe-dream-01>。
[NetworkQuality] Apple, "Network Quality", <https://support.apple.com/en-gb/HT212313>.
[ネットワーク品質] Apple、「ネットワーク品質」、<https://support.apple.com/en-gb/ht212313>。
[Paasch2021] Paasch, C., Meyer, R., Cheshire, S., and O. Shapira, "Responsiveness under Working Conditions", Work in Progress, Internet-Draft, draft-cpaasch-ippm-responsiveness-01, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01>.
[Paasch2021] Paasch、C.、Meyer、R.、Cheshire、S。、およびO. Shapira、「労働条件下での応答性」、作業中の作業、インターネットドラフト、ドラフト-CPAASCH-IPPM-Responsivension-01、25 10月25日2021、<https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsivesinging-01>。
[Pardue2021] Pardue, L. and S. Tellakula, "Lower-layer performance is not indicative of upper-layer success", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Lower-layer-performance-is-not-indicative-of-upper-layer-success-20210906-00-1.pdf>.
[Pardue2021] Pardue、L。and S. Tellakula、「低層層のパフォーマンスは上層層の成功を示すものではありません」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/lower-layer-performance-is-not-disicative-of-upper-layer-success-20210906-00-1.pdf>。
[Reed2021] Reed, D.P. and L. Perigo, "Measuring ISP Performance in Broadband America: A Study of Latency Under Load", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Camera_Ready_-Measuring-ISP-Performance-in-Broadband-America.pdf>.
[Reed2021]リード、D.P。およびL. Perigo、「ブロードバンドアメリカでのISPパフォーマンスの測定：荷重下のレイテンシの研究」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/camera_ready_-measuring-isp-performance-in-broadband-america.pdf>。
[SamKnows] "SamKnows", <https://www.samknows.com/>.
[Samknows]「Samknows」、<https://www.samknows.com/>。
[Schlinker2019] Schlinker, B., Cunha, I., Chiu, Y., Sundaresan, S., and E. Katz-Basset, "Internet Performance from Facebook's Edge", February 2019, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Performance-from-Facebooks-Edge.pdf>.
[Schlinker2019] Schlinker、B.、Cunha、I.、Chiu、Y.、Sundaresan、S。、およびE. Katz-Basset、「Facebook's Edgeからのインターネットパフォーマンス」、2019年2月、<https：//www.iab。org/wp-content/iab-uploads/2021/09/Internet-Performance-From-FaceBooks-Edge.pdf>。
[Scuba] Abraham, L. et al., "Scuba: Diving into Data at Facebook", <https://research.facebook.com/publications/scuba-diving-into-data-at-facebook/>.
[スキューバ] Abraham、L。et al。、「Scuba：Facebookでデータに潜る」、<https://research.facebook.com/publications/scuba-diving-into-data-at-facebook/>。
[Sengupta2021] Sengupta, S., Kim, H., and J. Rexford, "Fine-Grained RTT Monitoring Inside the Network", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ Camera_Ready__Fine-Grained_RTT_Monitoring_Inside_the_Network.pdf>.
[Sengupta2021] Sengupta、S.、Kim、H。、およびJ. Rexford、「ネットワーク内での細かいRTTモニタリング」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/CAMERY_READY__FINE-GRAINED_RTT_MONITRING_INSIDE_THE_NETWORK.PDF>。
[Sivaraman2021] Sivaraman, V., Madanapalli, S., and H. Kumar, "Measuring Network Experience Meaningfully, Accurately, and Scalably", February 2021, <https://www.iab.org/wp-content/ IAB-uploads/2021/09/CanopusPositionPaperCameraReady.pdf>.
[Sivaraman2021] Sivaraman、V.、Madanapalli、S。、およびH. Kumar、「ネットワークの経験を有意に、正確に、そして拡張的に測定」、2021年2月、<https://www.iab.org/wp-content/ iab-アップロード/2021/09/canopuspositionpapercameraready.pdf>。
[Speedtest] Ookla, "Speedtest", <https://www.speedtest.net>.
[SpeedTest] Ookla、 "SpeedTest"、<https://www.speedtest.net>。
[Stein2021] Stein, Y., "The Futility of QoS", August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/QoS-futility.pdf>.
[Stein2021] Stein、Y。、「Qosの無益さ」、2021年8月、<https://www.iab.org/wp-content/iab-uploads/2021/09/qos-futility.pdf>。
[Welzl2021] Welzl, M., "A Case for Long-Term Statistics", February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/ iab-longtermstats_cameraready.docx-1.pdf>.
[Welzl2021] Welzl、M。、「長期統計のケース」、2021年2月、<https://www.iab.org/wp-content/iab-uploads/2021/09/iab-longtermstats_cameraready.docx-1.pdf>。
[WORKSHOP] IAB, "IAB Workshop: Measuring Network Quality for End-Users, 2021", September 2021, <https://www.iab.org/activities/workshops/network-quality>.
[ワークショップ] IAB、「IABワークショップ：エンドユーザーのネットワーク品質の測定、2021」、2021年9月、<https://www.iab.org/activities/workshops/network-quality>。
[Zhang2021] Zhang, M., Goel, V., and L. Xu, "User-Perceived Latency to Measure CCAs", September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/User_Perceived_Latency-1.pdf>.
[Zhang2021] Zhang、M.、Goel、V.、およびL. Xu、「CCASを測定するためのユーザー認識レイテンシ」、2021年9月、<https://www.iab.org/wp-content/iab-uploads/2021/09/user_perceived_latency-1.pdf>。
The program committee consisted of:
プログラム委員会は次のとおりです。
Jari Arkko Olivier Bonaventure Vint Cerf Stuart Cheshire Sam Crowford Nick Feamster Jim Gettys Toke Hoiland-Jorgensen Geoff Huston Cullen Jennings Katarzyna Kosek-Szott Mirja Kühlewind Jason Livingood Matt Mathis Randall Meyer Kathleen Nichols Christoph Paasch Tommy Pauly Greg White Keith Winstein
Jari Arkko Olivier Bonaventure Vint Cerf Stuart Cheshire Sam Crowford Nick Feamster Jim Gettys Toke Hoiland-Jorgensen Geoff Huston Cullen Jennings Katarzyna Kosek-Szott MirjaKühlewindJasonLivingoood MatisランドランドGre
The workshop chairs consisted of:
ワークショップの椅子は次のとおりです。
Wes Hardaker Evgeny Khorov Omer Shapira
ウェス・ハーデイカー・エヴゲニー・ホロフ・オメル・シャピラ
The following is a list of participants who attended the workshop over a remote connection:
以下は、リモート接続をめぐるワークショップに参加した参加者のリストです。
Ahmed Aldabbagh Jari Arkko Praveen Balasubramanian Olivier Bonaventure Djamel Bousaber Bob Briscoe Rich Brown Anna Brunstrom Pedro Casas Vint Cerf Stuart Cheshire Kenjiro Cho Steve Christianson John Cioffi Alexander Clemm Luis M. Contreras Sam Crawford Neil Davies Gino Dion Toerless Eckert Lars Eggert Joachim Fabini Gorry Fairhurst Nick Feamster Mat Ford Jonathan Foulkes Jim Gettys Rajat Ghai Vidhi Goel Wes Hardaker Joris Herbots Geoff Huston Toke Høiland-Jørgensen Jana Iyengar Cullen Jennings Ken Kerpez Evgeny Khorov Kalevi Kilkki Joon Kim Zhenbin Li Mikhail Liubogoshchev Jason Livingood Kyle MacMillan Sharat Madanapalli Vesna Manojlovic Robin Marx Matt Mathis Jared Mauch Kristen McIntyre Randall Meyer François Michel Greg Mirsky Cindy Morgan Al Morton Szilveszter Nadas Kathleen Nichols Lai Yi Ohlsen Christoph Paasch Lucas Pardue Tommy Pauly Levi Perigo David Reed Alvaro Retana Roberto Koen De Schepper David Schinazi Brandon Schlinker Eve Schooler Satadal Sengupta Jinous Shafiei Shapelez Omer Shapira Dan Siemon Vijay Sivaraman Karthik Sundaresan Dave Taht Rick Taylor Bjørn Ivar Teigen Nicolas Tessares Peter Thompson Balazs Varga Bren Tully Walsh Michael Welzl Greg White Russ White Keith Winstein Lisong Xu Jiankang Yao Gavin Young Mingrui Zhang
アーメド・アルダブバグ・ジャリ・アークコ・プラヴェン・バラスブラマニアン・オリビエ・ボナヴェントゥール・ジュメル・ブーザバー・ボブ・ブリスコー・リッチブラウンアンナ・ブルンストロム・ペドロ・カサス・ヴィント・セルフ・スチュアート・チェシャー・ケンジロ・チョ・ステイブ・クリスチャンソン・ジョン・シオフィ・アレクサンダー・クレムMat Ford Jonathan Foulkes Jim Gettys Rajat Ghai Vidhi Goel Wes Hardaker Joris Herbots Geoff Huston Toke Høiland-Jørgensen Jana Iyengar Cullen Jennings Ken Kerpez Evgeny Khorov Kalevi Kilkki Joon Kim Zhenbin Li Mikhail Liubogoshchev Jason Livingood Kyle MacMillan Sharat Madanapalli Vesna Manojlovic Robin Marx Matt Mathis Jared Mauchクリステン・マッキンタイア・ランドール・マイヤー・フランソワ・ミシェル・グレッグ・ミルスキー・シンディ・モーガン・モーガン・アル・モートン・シルヴェスター・ナダス・キャスリーン・ニコルLez Omer Shapira Dan Siemon Vijay Sivaraman Karthik Sundaresan Dave Taht Rick TaylorBjørnIvarTeigen Tessares Peter Thompson Balazs Varga Bren Tully Walsh Michael Welzl Greg White White White Lisong Xu Jiankan
IAB Members at the Time of Approval
承認時のIABメンバー
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャ委員会メンバーこの文書が公開されたときに承認された時点は次のとおりです。
Jari Arkko Deborah Brungard Lars Eggert Wes Hardaker Cullen Jennings Mallory Knodel Mirja Kühlewind Zhenbin Li Tommy Pauly David Schinazi Russ White Qin Wu Jiankang Yao
Jari Arkko Deborah Brungard Lars Eggert Wes Hardaker Cullen Jennings Mallory Knodel MirjaKühlewindZhenbinLi Tommy Pauly David Schinazi Russ White Qin Wu Jiankang Yao
Acknowledgments
謝辞
The authors would like to thank the workshop participants, the members of the IAB, and the program committee for creating and participating in many interesting discussions.
著者は、ワークショップの参加者、IABのメンバー、および多くの興味深い議論の作成と参加についてプログラム委員会に感謝したいと思います。
Contributors
貢献者
Thank you to the people that contributed edits to this document:
このドキュメントに編集を提供してくれた人々に感謝します。
Erik Auerswald Simon Leinen Brian Trammell
エリック・オーアーズ・サイモン・レイネン・ブライアン・トラメル
Authors' Addresses
著者のアドレス
Wes Hardaker Email: ietf@hardakers.net
Wes Hardaker Email：ietf@hardakers.net
Omer Shapira Email: omer_shapira@apple.com
Omer Shapiraメール：omer_shapira@apple.com