Timestamp Negotiation Cannot Eliminate Overshoot: A Physical Fact About Dynamic C

Abstract

A recent proposal suggests that by using high-precision timestamp negotiation at both ends to directly measure the one-way propagation delay, it is possible to eliminate the “overshoot–drain” cycle in congestion control. This paper argues, from the perspectives of physics and information theory, that such an idea is infeasible. The core argument is: Timestamping addresses the estimation problem of the propagation delay $T_{prop}$, whereas congestion control must track the bottleneck service rate $C$—these are two different physical dimensions, and the latter cannot be derived from any refinement of the former. $C$ is inherently dynamic and cannot be known a priori; overshoot is the only way to identify $C$ under RTT-only observation. This physical fact holds regardless of the RTT size or the precision of time synchronization.

1. The Root of the Problem: Confusing Two Physical Quantities

An end-to-end path is determined by two independent physical quantities:

• Propagation delay $T_{prop}$: the time a signal travels through the medium, governed by distance and the speed of light.
• Bottleneck service rate $C$: the data-passing capability at the narrowest point along the path, jointly determined by link bandwidth, scheduling policy, and competing traffic.

The two originate from completely orthogonal physical aspects:

Physical Quantity	Determining Factors	Variation over Time	Knowable a Priori?
$T_{prop}$	Path length, refractive index of medium	Jumps only when routing changes	Can be measured via one-way timestamps
$C$	Link bandwidth, number of competing flows, wireless channel quality	Continuously, dynamically changing	Cannot be known a priori

Timestamp negotiation can at best accurately measure the first quantity. The second quantity, $C$, is an unknown, time-varying system parameter from the sender’s perspective.

2. Two Intuitive Counterexamples

Example 1: Long-RTT, High-Bandwidth Path

Consider a trans-Pacific fiber, RTT = 500 ms, link bandwidth = 100 Gbps, with very few competing flows. Using timestamp measurement, the sender knows precisely that $T_{prop}=250$ ms (one way), and then believes it “knows all the information about the path.”

Yet it still does not know that $C=100$ Gbps. It must inject data into the pipe and observe whether queuing appears before it can determine how much load the path can actually sustain. Whether the RTT is 500 ms or 5 ms does not change the logic that one must overshoot to discover $C$.

Example 2: New Flow Causes $C$ to Shrink

A sender is running stably, with its sending rate $r\approx C_1$. At this moment, a flow on another server, passing through the same egress port of the same switch, joins the competition. For the original sender, its available bandwidth drops instantaneously from $C_1$ to $C_2<C_1$.

No change in timestamps can forewarn this event. Only when the original sender continues sending at $r>C_2$ and observes queuing delay beginning to grow can it realize that “the wall has moved closer.” A timestamp-based scheme is completely blind to this.

3. Three Sources of Dynamic $C$

The temporal variation of $C$ arises from three levels:

1. Physical-layer dynamics: Changes in wireless channel quality (Wi-Fi signal fading, cellular handover) can cause $C$ to vary by ±50% on the order of seconds. These changes occur without any routing change; $T_{prop}$ remains completely unchanged.
2. Competing-traffic dynamics: Other flows starting or stopping on the same egress port make $C$ fluctuate on RTT timescales. This is the typical case of “the wall moving closer to or farther from the sender.”
3. Routing/topology dynamics: ECMP hash changes, BGP convergence, or congestion at a data-center egress can cause $C$ to jump, while any change in $T_{prop}$, if present, is delayed and asynchronous.

The combination of these three factors makes $C$ fundamentally impossible to know a priori. Any scheme claiming to “eliminate overshoot” must explain how it can track a continuously changing $C$ in real time without ever creating a queue.

4. The Essence of Overshoot: Necessary Excitation for Physical Identification

From a control-theoretic perspective, overshoot is not an engineering compromise, but a necessary excitation for identifying a time-varying system parameter.

Suppose a sender wishes to identify the current $C(t)$. Its observation equation is:

$$z_k=T_{prop}+\frac{q_k}{C(t)}+T_{noise}$$

where $q_k$ is determined by the accumulation of $r(t)-C(t)$. If $r(t)$ never exceeds $C(t)$, then $q_k=0$ and the observation equation degenerates to:

$$z_k=T_{prop}+T_{noise}$$

In this case, $C(t)$ does not appear in the observation at all, making the system unidentifiable with respect to $C(t)$. The sending rate must satisfy $r(t)>C(t)$ for at least a brief period for $C(t)$ to enter the observation equation.

Therefore, overshoot is the only way to identify dynamic $C$ under RTT-only observation, irrespective of the RTT magnitude. Even with nanosecond-accurate timestamp synchronization at both ends, as long as $r(t)\le C(t)$, $C(t)$ remains invisible to the sender.

5. KCC’s Direction: Not to Eliminate Overshoot, But to Control It Precisely

KCC’s directional gating does not attempt to eliminate overshoot. Instead, it:

1. Strips $T_{noise}$ from the observation through directional gating.
2. Applies a precise differential brake on the clean $T_{queue}$ signal.
3. Compresses the amplitude and duration of overshoot to the minimum physically permitted by the hardware.

This strategy is information-theoretically optimal—it acknowledges that overshoot is ineliminable, but reduces its cost to the absolute minimum through more accurate state estimation.

6. Conclusion

The core argument can be summarized in one sentence: Timestamps solve the question of “how long the light has traveled,” whereas congestion control needs to know “how thick the pipe is at this moment.” How long the light traveled does not change with competing flows, but the pipe’s thickness changes with every millisecond of traffic contention. No timestamp synchronization precision can replace the physical act of “touching the wall.”

Hence, the idea of “eliminating overshoot through timestamp negotiation” does not hold at the information-theory level. The correct evolution direction for KCC is not to eliminate overshoot, but to retain this physically necessary step while pushing the unavoidable overshoot to an extremely small boundary through more precise perception of $T_{queue}$.