[HPC/net]Measuring Congestion in
[2021-07-05]
贴一下之前的笔记，一年过去了，重新思考读过的文章
2020 NDSI
时间：2020年09月12日16:57:00
一 文章概述
这篇文章针对HPC数据中心拥塞问题，提出了一种方法论，用于检测，抽取，特征化HPC数据中心的拥塞区域。设计并实现了工具Monet，适用于torus网络的拥塞检测。
二 这篇文章主要贡献
本文主要贡献是提出了Monet，一个针对数据中心的拥塞检测工具。更新了人们对Torus网络的拥塞情况的认知：1.由于Torus网络的特殊性，超算中的拥塞是具有区域性的；
2.拥塞情况出现的频率和延续时间（25%超过30分钟；平均时常1h）都很长，系统默认的拥塞算法备触发的概率只有8% (261 of 3390) ；
3.拥塞对应用时常的影响差距在
针对该超算中心的情况，本文做了以下工作：
利用系统的数据，定义了per-stall的概念来度量拥塞
选取系统，网络，应用等多方面数据，对拥塞数据进行无监督聚类
links作为节点；switch作为边；
邻近具有相似stall值的links被聚在一起
附近的region有相似的平均stall值被聚合在一起
CRs的links小于阈值的被融合进最近的region；更小的被丢弃
可视化了超算中的拥塞特征；显示了网络级别的拥塞演化过程和变化概率；展示了拥塞对应用的影响；拥塞的场景
利用拥塞特征，对系统进行拥塞诊断：识别拥塞原因；触发局部拥塞缓解算法；
本文有一个比较核心的工作就是对torus网络的拥塞进行了量化和可视化。
三 回答四个问题
1 该文章解决的核心问题？前人使用的方法为什么不能解决本文提出的问题，困难在哪？本文提出的方法为什么能够有效解决这些问题？
本文解决的核心问题是对torus网络的拥塞进行了量化和可视化。
为了理解和最小化应用程序的性能变化，人们对评估HPC系统中的性能异常非常感兴趣。诸如Darshan [65]，Beacon [87]和Kaleidoscope [54]之类的监视框架专注于I / O配置和性能异常诊断。 鉴于我们的工作重点是评估基于信用流的互连网络中的网络拥塞。 通常，拥塞研究基于对生产环境中基准应用程序性能变化的测量[25、88]和/或假设稳态利用率/拥塞行为[23、52、64、73]的模型，因此无法解决完整的真实生产环境的问题。
在应用程序或系统层(如调度器)，有一些研究致力于识别热点和控制拥塞的影响。这些方法包括(a)使用应用自身的间接度量，如消息传递率[25]，或只能从一个分配内访问的交换机的网络计数器[38,49,50,76]，未测量在分配外交换机的路由上的拥塞;（b)使用全局网络计数器数据[17,26,28,30]，然而，这些工作仅仅这些都只给出了时间上拥塞的典型例子，或者在系统上执行单个应用程序。
相比之下，这项工作是第一个描述长期高速互连网络拥塞的大规模生产系统，其中网络资源是由不同作业分配的节点共享，使用全局计数器。我们的工作实现的表征和诊断可用于通知应用程序级[29]或系统级CEMR（例如，使用局部限制而不是全网络限制）。 也许，与我们最接近的工作是[22]，这是对云数据中心网络进行的经验研究，重点是网络利用率和流量模式，而Beacon[87]曾在TaihuLight [43]上用于监视互连网络节点间流量带宽。 像其他论文一样，这些工作不涉及拥塞区域的产生和表征，拥塞原因的诊断，也不涉及该方法的一般实现，但是，我们确实在我们的系统中观察到了一些互补的结果（例如，热点的存在）。 -链路，并不总是使用完整的二等分带宽，评估链路中的拥塞持续性。
最后，对于数据中心网络，诸如ExpressPass [32]，DCQCN [89]，TIMELY [69]之类的工作重点在于在网络层上预防和减轻拥塞，而诸如PathDump [84]，SwitchPointer [85]之类的工作则更为重要。 ]，路径查询[72]，EverFlow [90]，NetSight [51]，LDMS [17]和TPP [53]专注于网络监控。 这些方法针对TCP / IP网络进行了调整，并且与此处介绍的工作正交。 我们的方法是对这些努力的补充，因为它可以表征拥塞区域（热点）并识别引起拥塞的事件。
前人提出的方案，针对应用理解和最小化应用程序的性能变化的工作，假设条件苛刻，不能用在真实环境；
针对应用程序的工作，要么没有考虑到非拥塞部分的特征，要么仅仅研究了单个应用，没有在真实环境中。
针对应用程序或者系统层
总的来说，本文方法是第一个在基于信用的真实环境做的拥塞特征提取，判别，可视化的工作，是对其他工作的补充。
2 该核心问题的解决带来了什么冲击？正负面都有哪些影响？
可视化了HPC系统的拥塞情况，指出环境中拥塞算法的问题。
正向影响：清晰明确
负面影响：拥塞特征识别的正确性。
3 作者如何进行验证？数学推导还是实验测试？是否完备？如果你进行验证，你会采取什么办法？如果你的方法和本文不一样，思考作者为什么不采用你想的方法？采用你想的方法，会有什么困难？如果你用文中方法，你会遇到什么困难？
本文作者的成果其实主要有两个部分：
一个是理论成果：衡量网络拥塞的度量衡
一个是实践成果：实现了Monet，一种针对BlueWater真实环境的拥塞可视化组件
其中理论成果：提出一种测量识别判断网络拥塞的方法论
实践成果部分通过实验测试进行了评估：
首先利用拥塞度量衡，利用自监督学习，聚类拥塞区域和非拥塞区域
其次利用拥塞特征，1.识别拥塞，并触发拥塞缓解算法；2.诊断拥塞的原因
拥塞识别实验：
需要的数据：
网络性能计数器 15TB：directionally aggregated network traffic (bytes and packets) and length of stalls due to credit depletion; Lustre file system read and write bytes; and RDMA bytes transmitted and received 定向聚集的网络流量（字节和数据包）和由于信用耗尽而导致的停顿时间； 光泽文件系统读写字节； 和RDMA字节的发送和接收
网络监控日志100GB：occurrences, times, and locations of link failures and CPEs链路故障和CPE的出现，时间和位置
workload data 7GB：work- load dataset contains information about 815,006 application
聚类算法：
The clustering approach requires the following parameters: (a) network graph (G), (b) congestion measures (vs for each vertex v in G), (c) neighborhood distance metric (dδ), and (d) stall similarity metric (dλ).
每条链路计算一个perstall值，根据perstall进行自聚类；邻近的聚合在一起，低于阈值的被抛弃；
算法是在以下几个假设下工作的:(a)链路的延迟分布在局部，(b)在一个CR内，链路的失速值变化不大
实验工具：
a modified version of the region growth segmentation al- gorithm [78] found in the open-source PointCloud Library (PCL)
整个系统实验：
1.利用拥塞特征：对拥塞进行反应
2.利用拥塞特征：诊断引起拥塞的原因
2.1 挖掘潜在导致拥塞的原因
2.2 识别极端或者异常因素
2.3 生产证据
4 找本文不完善的地方，是否还有可改进的空间？
首先介绍一下作者认为还存在的开放问题：
1.实验局限在torus网络上；可以拓展到其他网络技术和拓扑中
个人认为不完善可改进的地方：
1.实验数据和环境是独一份的，torus的拓扑是立方体结构的，所以可以呈现非常直观的小郭；交换机上的stall数据，我的环境中拿不到，如果能拿到交换机上的数据，还是可以对超算环境的做一个相似的实验；
- 拥塞原因诊断这部分大多是方法论，没有实际的实验
