ITR: Protocol Coordination for Multistream Applications

世界上正迅速地充斥着各种各样的信息设备，诸如计算机、个人数字助理、摄像机、数字光投影仪和有线机顶盒。 这些设备不再是简单的技术孤岛，而是能够与环境中的其他设备进行通信。未来的互联网应用程序将越来越多地利用这些设备，以分布式的方式组织它们。 这些应用的例子包括分布式传感器阵列，远程沉浸，计算机支持的协作式网络（CSCW），无处不在的计算环境，以及复杂的多流，多媒体演示。在这些应用中，没有一个设备或计算资源产生或管理所有传输的数据流。相反，这些应用程序将分布在环境中的一组设备上。在C-to-C应用中，分布在设备或计算机集群上的一组进程与远程设备或计算机集群上的另一组进程通信。进程分布在两端的设备集群上，以管理数据流和控制应用程序。 不幸的是，传统的网络技术和协议不足以支持这些类型的应用。最根本的问题是，当前的传输层协议与其他业务流隔离，并且严格理解为“端到端”。“由共享公共路径的多个相关数据流使用的传输级协议没有协调机制。因此，C-to-C应用程序中的每个进程都与同一应用程序中的其他进程竞争网络资源。此外，每个传输层协议必须对当前网络条件进行独立评估（例如，延迟、拥塞等）这可能导致不一致和敌对的协议动态。 此外，由C-to-C应用程序产生的大量数据流将具有只有应用程序才知道的语义关系。 这些关系影响数据的传输方式和传输层协议的操作。 C-to-C应用程序需要全局查看其所有流的性能，以便适应动态网络条件。在不了解聚合应用性能的情况下，单独的流的独立适配是不必要的。C-to-C应用的一个关键特征是大部分通信路径在所有数据流之间共享。虽然没有两个数据流可以共享整个端到端路径，但所有数据流都共享两个集群之间的路径。此外，这种共享的公共路径很可能是网络条件变化最大的地方，也是由于外部流量而导致拥塞的原因。 利用这一特性，我们解决这个问题的一般方法是在集群应用程序中的数据流聚合点引入机制，这些机制确定沿着共享公共路径的网络条件，并提供可用网络资源的一致和协调视图。具体而言，我们工作的主要贡献是在网络级（IP）和传输级之间引入附加协议（TCP、UDP等）。我们称之为“协调协议”（CP）。 此附加协议将用于在应用程序两端的集群基础结构内的转发机制之间传递信息。 由这些机制交换的信息用于估计沿着共享路径的动态网络条件（即，拥塞、等待时间、抖动等）。 由于单个机制负责跨多流应用的所有流估计网络状况，因此C-to-C应用中涉及的所有单个传输层协议都可以获得当前网络状况的一致和协调视图。 然后，应用程序可以对拥塞、丢失和其他网络事件做出反应，并结合应用程序级知识，实现全局目标。研究人员方法的主要特点是： - 跨所有应用程序流提供一致的网络状况测量。 - 保留传输层协议的端到端语义。 - 本地部署。 - 独立于应用程序架构。 - 作为其他类型协调的框架。作为一个整体，C-to-C应用程序的所有流的聚合网络行为应该适当地响应拥塞和其他网络条件。 然而，每个单独的流如何响应只能在应用程序级别确定，因为只有应用程序才了解流是如何相关的。我们将开发的协调协议提供集群应用程序的能力，应用程序级的知识，这些流间的语义关系，并协调网络资源的使用。该协议将帮助我们探索协调机制，并使广泛的新应用程序类型成为可能，这些应用程序目前还不存在，但研究人员和工业界将其视为互联网的未来。

The world is rapidly being populated by a wide array of information appliances such as computers, personal digital assistants, video cameras, digital light projectors, and cable set-top boxes. Theseappliances are no longer simply islands of technology, but have the ability to communicate with other devices in their environment. Future Internet applications will increasingly make use of thesedevices by organizing them in a distributed fashion. Examples of these applications include distributed sensor arrays, tele-immersion, computer-supported collaborative workspaces (CSCW), ubiquitous computing environments, and complex multistream, multimedia presentations. In these applications, no one device or computational resource produces or manages all of the data streamstransmitted. Instead, these applications will be distributed over a collection of devices in an environment. These types of applications are called "cluster-to-cluster" (C-to-C) applications.In a C-to-C application, a set of processes distributed on a cluster of devices or computers communicates with another set of processes on a remote cluster of devices or computers. Processes are distributed on the device clusters at either end to manage the data streams and control the application. Unfortunately, traditional network technologies and protocols are ill-equipped to support these kinds of applications.The fundamental problem is that current transport-level protocols operate in isolation from other traffic flows and within a strict understanding of "end-to-end." The transport-level protocols used by multiple, related, data streams that share a common path have no coordination mechanism. As a result, each process in a C-to-C application competes with other processes within the same application for network resources. Also, each transport-level protocol must make independent assessments of current network conditions (e.g., delay, congestion, etc.) which can lead to inconsistent and adversarial protocol dynamics. Furthermore, the numerous data streams produced by a C-to-C application will have semantic relationships known only to the application. These relationships affect how the data should be transmitted and the operation of transport-level protocols. A C-to-C application needs a global view of performance across all of its flowsin order to make adaptations to dynamic network conditions. Independent adaptation of the separate flows uninformed of aggregate application performance is insufficient.A key characteristic of C-to-C applications is that a large portion of the communication path is shared among all data flows. Although no two data flows may share an entire end-to-end path, all data flows share the path between the two clusters. Furthermore, this shared common path is likely to be where network conditions vary the most and the source of congestion due to outside traffic. Exploiting this characteristic, our general approach to the problem is to introduce mechanisms at the points of aggregation for data streams in a cluster application that determine network conditions along the shared common path and provide a consistent and coordinated view of available network resources.Specifically, a major contribution of our work will be to introduce an additional protocol between the network level (IP) and the transport level (TCP, UDP, etc.). We call this protocol the "Coordination Protocol" (CP). This additional protocol will be used to communicate information between forwarding mechanisms within the cluster infrastructure on either end of the application. The information exchanged by these mechanisms is used to estimate the dynamic network conditions along the shared path (i.e., congestion, latency, jitter, etc.). Because a single mechanism is charged with estimating network conditions across all flows of a multistream application, all individual transport-level protocols involved in a C-to-C application receive a consistent and coordinated view of current network conditions. The application can then react to congestion, loss, and other network events in a manner that incorporates application-level knowledge and achieves global objectives.The major features of the researchers approach are: - Provides a consistent measurement of network conditions across all application flows. - Preserves end-to-end semantics of transport-level protocols. - Locally deployable. - Independence from application architecture. - Serves as a framework for other types of coordination.As a whole, the aggregate network behavior of all the flows of a C-to-C application should respond appropriately to congestion and other network conditions. How each individual stream responds,however, can only be determined at the application level because only the application has an understanding of how the streams are related. The coordination protocol we will develop provides cluster applications with the ability to apply application-level knowledge about these interstream semantic relationships and coordinate the use of network resources. The protocol will help us explore coordination mechanisms and make possible a wide range of new application typesthat do not currently exist, but are envisioned by researchers and industry as the future of the Internet.