View source for 网络质量监控与预测工作流

= 网络质量监控与预测工作流 =

'''目标''': 理解网络质量参数(Network Quality)如何服务与Web应用并建立其被逐渐采用的路线图

下面这些场景可用于我们开展探索：
*了解现有的API有哪些可用性，它们的有效性如何，以及它们是否可以扩展？
*新的Network hintsAPI定义，确切要求或注意事项是什么？
*对于数据完整性、隐私性、信任和透明度，这些API或参数是否能作为考验它们的关键“试金石”？

== 工作方式 ==
“建议”：每月1小时（若有必要两周一次）的电话会议，会议内容构成为：20-30分钟的演讲，然后是20分钟的讨论，10分钟的时间专门用于确定所需的后续讨论和下一步行动。

== 干系参与者 ==
* 电信运营商 
* 云计算提供商
* 浏览器供应商
* 网络基础设施解决方案提供商
*（操作系统供应商？）
* 应用程序开发人员
* CDN提供商

== 场景主题 ==

===用例和需求分析阶段===
* 准备用例列表并开始收集需求
* 评估现有的API并评估可能的扩展
** 例如，Network Information API、后台获取/同步API
* 从其他领域组织（W3C、IETF等）的前期尝试中获得的经验教训
** WebRTC组
** 媒体和娱乐组
** 其它组

在描述这些用例时面临的挑战：
*哪些用例可以从网络质量信息中获益？
*现有的API有哪些，它们有多少作用？

演讲的潜在主题：
*邀请W3C成员展示用例和需求
*邀请来自不同CG/IG/WG的W3C成员介绍有关当前支持的网络相关API信息

==有助于分析的API参数==
*研究API和参数考虑及成本效益分析
**API优点
#优化目标
#信息类型
#应用程序焦点（是每个客户端还是每个应用程序）？
#准确性和效益

** 安全影响
** 隐私考虑

*体系结构分析
**设备端架构：Network Hints: WebApp直接使用或浏览器框架内实现
**系统架构：涉及的新接口和实体，部署方面

在绘制这些用例时要探索的挑战：
*客户端如何获取网络质量信息？
*客户端是否可以通过获取特定移动路径中有关网络质量的高级信息而受益？
*Web应用程序如何使用这些网络提示来提高应用程序的体验质量？

演讲的潜在主题：
  *特定参数或API的值，以及任何测试结果。
  *如有提供架构方面建议，可进行TAG审阅。

===联络互动阶段===
重点领域：
*与其他W3C组织分享发现，如Privacy IG、WebRTC WG、WebTransport CG等。
*其他标准小组的专家意见，交流意见
** ETSI、5GAA等。


===文档阶段===
*将收集和捕获的信息整合到白皮书中

===原型阶段===
*研究新API和参数考虑及效益分析
**示例参考网络API的评估
**分析扩展应用程序性能测试开发工具的可行性
**讨论互操作性方面

==讨论和问题==
===范围===
*工作流程的主要目标是研究用例，这些用例可以通过使用即时或预测值的网络质量信息来适应变化的网络条件而受益。
*第二个目标是从应用程序或网络的角度识别需求，以便监控正确的网络质量参数，并使用这些参数来提高用例的体验质量。
*工作流还讨论了过去在web浏览器中以及在移动和个人计算机膝上型设备的软件堆栈或操作系统的不同层中为此目的引入的类似现有API。

===网络质量监控在Web应用领域中适用于哪些方面？===
今天的应用程序没有任何关于通过ISP/ICP获得的网络状况直接信息。在适应不断变化的网络条件方面有价值的应用程序使用部署在端点的解决方案进行测量，在端点，它通过跟踪包响应到达率和其他类似的方法来探测网络质量。在W3C中已经有了定义和实现此类API的建议。一些网络质量度量是在应用程序层内处理的，或者是从从远程端进行类似度量的服务器收集的。这些解决方案有缺点，因此还有进一步改进的余地。

这是网络质量监控研究可以帮助lot识别新参数的地方，这些参数可以从何处获得，以及如何被运行在设备或云端的应用程序利用以提高QoE。这些也可以称为从网络到设备的“提示”。如果网络从应用程序获得“提示”，则也可能出现相反的情况，这样它就可以以平衡的方式分配资源。

===网络质量监控有何帮助？===
网络“提示”可由应用程序以各种方式使用。这些“提示”可以是即时的，也可以是预测出来的，可以让我们对未来的网络状况有一个初步的了解。有了这些信息，应用程序可以采取必要的步骤来确保用户体验不会受到不利影响，例如通过额外的高级缓冲或降低带宽利用率来保持实时操作等。这可以根据应用程序的类型而有所不同，例如视频流或在线游戏或视频会议呼叫。

===定义解决方案时应遵循的主要指导原则是什么？===
我们需要考虑超规模解决方案：
-在全球范围内广泛适用于多种网络技术
-保证数据完整性
-个人身份信息（PII）的最小暴露
-明确用户参与同意

https://www.w3.org/2019/09/17-web-networks-druta-hints.pdf

===我们应该关注什么？===
必须将重点放在向网络层提供“提示”和从网络层提供“提示”的解决方案上，以便应用程序能够告知并被告知：
*网络条件
*网络访问可用性
*技术支持（无线电等）

这样做的理由是: “hints”
*不保证可用
*可以忽略——如果没有共同利益，就没有合同义务
*可用于主动调整应用程序以适应网络条件
*能可靠传达应用特点
[[File:Principles.png|thumb|none|Principles that apply to Web & Networks investigations]]

===什么是网络链路性能预测(LPP)？===
网络“hints”可以是关于近期网络状况的。无线网络在任何给定的时间点都面临着巨大的带宽变化挑战。Intel团队在2019年福冈TPAC上提出了一个名为LPP链路性能预测的解决方案，并用一个实际例子说明了这一点。提供的PPT可参考：https://www.w3.org/2019/09/17-web-networks-lpp.pdf


[[File:2.png|thumb|none|Networks are better, but variations are larger - variations in quality between networks, and variations within networks]]

网络现在是“最大的努力”，这限制了允许的服务类型。拥有更具确定性的洞察力有助于应用程序处于控制之中。这包括当前和近期的链路性能。参数可以是多种类型，如带宽、延迟、单元负载等。
在ETSI多址边缘计算组中进行了另一个类似的研究，其中引入了一个概念呼叫预测QoS。这是在Web and Network IG会议上提出的，更多细节如下
https://www.w3.org/2020/03/20-web-networks-5Gaa-predictive-qos.pdf

MEC基础设施向应用程序提供预测QoS数据。给出了汽车行业的一个实例如下:
===我们在寻找什么样的解决方案，迄今为止已经尝试了什么？====
如果我们看看目前在W3C中所做的工作，网络信息WICG定义了一些API，这些API目前在一些浏览器中实现。这些API可以获取往返时间数据、网络带宽和类型信息。有关此API的详细信息，请访问：
https://wicg.github.io/netinfo/

定义的API为应用程序提供以下“hints”：
*连接类型（WiFi、蜂窝、BT、以太网等）
*网络信息（下行最大数据速率、数据速率、RTT等）

Google团队在Web & Network IG中介绍了API的使用、面临的挑战和需要改进的地方。更多信息请访问：
https://www.w3.org/2020/02/05-web-networks-Network-Quality-Estimation-in-Chrome.pdf

同样，如果有其他这样的api可以洞察当前和未来的网络状况、考虑什么样的参数等，我们希望进行更多的研究，这些api是我们希望孵化想法并一路寻求有效解决方案的领域。

===下一代的用例对网络性能有很强的依赖性是什么？===
在IG会议上，成员们提出了几个即将到来的用例，这些用例依赖于高效和有效地使用网络资源来提高QoE。在2019年第3季度的早期会议中，github记录了其中一些用例。
https://github.com/w3c/web-networks/issues

可以从中受益最大的用例：
*待定

===当前浏览器中NetInfo API的状态是什么？===
一些浏览器已经实现了网络信息API并被应用程序使用。下图给出了支持它的浏览器的高级图片，用绿色框标记。
[[File:Caniuse.png|thumb|none|Screenshot of network information API adoption as documented on can-I-use]] ([https://caniuse.com/#feat=netinfo source])

===可否举例说明NetInfo API是如何帮助web应用程序的吗？===
在我们的第六次兴趣小组会议上，Google团队提供了使用这个API的网页的统计数据。截至2019年12月，所有平台上超过20%的网页都使用了这个[4]。
[[File:Netinfo-usage.png|thumb|none|% of page loads that use netinfo API in Chrome in 2018-2019]]
参见[https://chromestatus.com/metrics/feature/timeline/popularity/1990最新使用报告]

===在当前浏览器中采用NetInfo API有哪些挑战？===
为了扩大此类API的范围和使用，需要解决一些挑战。他们是：
*多个浏览器平台，每个平台的api可用性不同
*算法没有所有必要的无线电状态信息来进行精确测量
*必须没有测量网络质量的开销。
*这些api必须确保保护用户的隐私。
*需要确保网络质量评估对快速变化的网络条件有足够的响应

===有哪些改进可以提高NetInfo API的可接受性？===

===网络链路性能预测如何工作？===

===对于网络链路性能预测，哪些参数是感兴趣的？===

下面的幻灯片展示了英特尔的Jonas和Jon Devlin分享的一些早期想法。这需要在利益集团内部进行更多的讨论和可行性分析。

[[File:Lpp.png|thumb|none|Network status / prediction - considerations]]

=== 测量QoS 如何在ETSI定义的移动边缘计算中工作？ ===

=== IOT方面对于新的网络hints API是否有特殊需求? ===