In the recent years, end-to-end feedback-based variants of TCP as well as VCP have emerged as practical alternatives of congestion control by requiring the use of only one or two ECN bits in the IP header. However, all such schemes suffer from a relatively low speed of convergence and exhibit a biased fairness behavior in moderate bandwidth high delay networks due to utilizing an insufficient amount of congestion feedback. In this paper, we propose a novel distributed ECN-based congestion control protocol to which we refer as Multi Packet Congestion Control Protocol (MPCP). In contrast to other alternatives, MPCP is able to relay a more precise congestion feedback yet preserve the utilization of the two ECN bits. MPCP distributes (extracts) congestion related information into (from) a series of n packets, thus allowing for a 2n-bit quantization of congestion measures with each packet carrying two of 2n bits in its ECN bits. We describe the design, implementation, and performance evaluation of MPCP through both simulations and experimental studies.
How many bits are enough? The answer is there is no answer. One bit is way better than no bit, but worse than more bits, which can convey more detailed information about congestion in the network (like in XCP). Alas, we have only two ECN bits in a single packet. What can we do? Use many packets, the authors say.
The authors are not the first to come up with the idea of distributing congestion information among many packets, see their references  and . The fact that using more bits, we get better bandwidth utilization and faster convergence, is by no means surprising either. But the reviewers found this particular implementation quite cute and neat. These cute and neat parts are about how exactly to do encoding and decoding, manage packet ordering, handle out of order packets, and so on. One could expect that all these details may be difficult to solve, but the authors have a simple and attractive solution. The paper is written well and easy to follow.
At the end, the authors go back to the first question above. Although their approach works for any number of packets, they discuss why using just two packets appears practically optimal.