Using stop-and-wait to improve TCP throughput in fast optical switching (FOS) networks over short physical distances

Abstract

Due to lack of optical RAM buffers in fast optical switches (FOS), statistical multiplexing technologies using FOS like Optical Burst Switching (OBS) or Optical Packet Switching (OPS) are expected to have higher data losses than conventional electronic networks. Consequently, applications transferring data by means of TCP can suffer from a lower throughput. In this paper, we show that this low-throughput problem is mainly an artifact caused by the conventional TCP congestion control algorithms, and can be remedied by using a simple yet effective stop-and-wait congestion control algorithm instead, as long as the propagation delay between TCP source and TCP destination is small compared to the transmission time of an optical packet. We show that such a condition holds for a wide range of scenarios, including fat-tree-based data center networks. We also show that the throughput achieved in a FOS network using stop-andwait can be the same as, or higher than that in an equivalent, conventional electronic network.

Optical vs. electronic packet switching: myth and advantage in 5G time-critical applications

“…These conventional algorithms are unsuitable for OPS, as they have been designed in EPS, and are thus implicitly optimized for environments with low losses (e.g., 1% or lower). Therefore, in OPS we will use TCP SAW [6], a congestion control algorithm explicitly optimized to work with higher loss levels -see Fig. 2.…”

Performance of Fixed-Length, Variable-Capacity Packets in Optical Packet-Switching Networks

“…The receiver sends an ACK packet to the sender for each data packet it receives, and the sender sends one packet at a time. This corresponds to stop-and-wait as implemented by TCP versions designed for OPS networks [11], which leads to considerable application throughput advantages over conventional alternatives. If c is the bit rate for the packet payloads, and considering the processing times at the end systems to be negligible, then the flow completion time (FCT) of a given flow transmitting a file of size s bytes will be ⌈ 8s γc ⌉ · γ γρ δ, where ⌈ 8s γc ⌉ is the number of data packets composing the file.…”

“…As the OPS switches we consider do not have buffers, their packet losses are in general much higher than in conventional networks. To ensure high application throughput in these conditions, we use TCP SAW [11], a TCP version that overcomes these high losses by leveraging the lowdelay that is also characteristic of bufferless networks and that allows data sources to react to losses faster than in networks with buffers-we depict an example of the operation of SAW in Fig. 8.…”

Throughput analysis of distant-adaptive, fixed-length, variable-capacity packets in OPS networks

“…As an illustration, Fig. 4 compares two congestion control algorithms in the 12-node ring with the HL traffic matrix: Sack (RFC 2018), an algorithm commonly found in operating systems, and SAW [6], an algorithm especially designed for bufferless OPS networks, and whose behavior is depicted in Fig. 5.…”

“…To make a fair comparison among the two OPS networks, we assume that applications use TCP SAW in the FL-VC case and TCP Sack in the ideal-OPS one, since each TCP version optimizes throughput in their respective scenarios [6]. The file size distribution is the constant one described above.…”