<p>Choosing the right Transmission Control Protocol (TCP) congestion control algorithm matters more in shared cloud environments than is often appreciated, yet head-to-head comparisons across heterogeneous, concurrently running workloads remain rare in the literature. We evaluated three widely used variants Cubic, Reno, and Bottleneck Bandwidth and Round-trip propagation time (BBR) under four workload types: synthetic throughput testing with iperf3, real-time stream processing using Apache Kafka and Apache Flink, distributed I/O, and compute-intensive sorting via Hadoop TeraSort. All experiments ran inside a dumbbell network topology built on four Amazon Web Services (AWS) m7i-flex.large Elastic Compute Cloud (EC2) instances, with a dedicated forwarding node and static routing forcing every flow through that single contention point. Across every metric we measured throughput, end-to-end latency, retransmission count, and job completion time the three variants behaved quite differently depending on the workload. The results give concrete, workload-specific guidance for operators choosing a congestion control policy in multitenant cloud deployments.</p>

错误:搜索内容不能为空,请输入英文关键词
错误:关键词超出字数限制,请精简
高级检索

Performance evaluation of TCP congestion control variants across application workloads in cloud based networks

  • Aravinda Swamy D.,
  • Ananya Hegde,
  • Anantha Chary C. M.,
  • Nalina V.,
  • Anitha H. M.

摘要

Choosing the right Transmission Control Protocol (TCP) congestion control algorithm matters more in shared cloud environments than is often appreciated, yet head-to-head comparisons across heterogeneous, concurrently running workloads remain rare in the literature. We evaluated three widely used variants Cubic, Reno, and Bottleneck Bandwidth and Round-trip propagation time (BBR) under four workload types: synthetic throughput testing with iperf3, real-time stream processing using Apache Kafka and Apache Flink, distributed I/O, and compute-intensive sorting via Hadoop TeraSort. All experiments ran inside a dumbbell network topology built on four Amazon Web Services (AWS) m7i-flex.large Elastic Compute Cloud (EC2) instances, with a dedicated forwarding node and static routing forcing every flow through that single contention point. Across every metric we measured throughput, end-to-end latency, retransmission count, and job completion time the three variants behaved quite differently depending on the workload. The results give concrete, workload-specific guidance for operators choosing a congestion control policy in multitenant cloud deployments.