[tsvwg] explanation of option 3 choice

[Tom Henderson <[e-mail]>]

I support the L4S goals to deploy scalable congestion controls and 
achieve low latency while maintaining high throughput when possible.  I 
believe that a clear input signal to the network will be needed, so I 
lean towards ECT(1) because it is the most likely to survive tunnel 
encapsulation and avoid bleaching.  However, the discussion has raised 
several performance and architectural concerns that I believe that the 
WG should address, so I believe that option 3 best aligns with my 
current view.

Selecting between L4S and SCE involves tradeoffs, but the decision seems 
to be clouded by skepticism about the viability of deploying a 
low-latency service even if we had enough bits to support two clear 
input signals and two output signals, and space to carry these different 
signals back to the sender.  How robust will the congestion controls be 
with a shallow threshold in the presence of jitter or burstiness, which 
is likely for multiple access wireless networks?  How low can the 
marking threshold be configured, and what are the tradeoffs (and how 
does the performance degrade when assumptions are violated)?  For a 
given latency threshold, what limits on RTT, burstiness, or bottleneck 
link rate may exist, and should the congestion controllers try to detect 
those conditions with heuristics?  If one were to try to design policers 
to prevent abuse, what would be the conformant flow behavior to police, 
and what if flows cannot be distinguished due to tunneling, or if 
in-network aggregation makes the flow non-conformant?

Assuming that the long-term issues inherent with a low-threshold ECN 
mark can be worked out even in the presence of enough signaling bits, 
then both the L4S and SCE proposals present further questions.  For L4S, 
aside from RFC 3168 detection, how does the lack of an overload signal 
(other than packet loss) inhibit the design of a congestion controller, 
and how does slow start to congestion avoidance transition occur?  For 
SCE, the reliance on DSCP-based classification will cause legacy/classic 
and low latency flows to end up more often in the same queue, and 
SCE-enabled flows could end up with worse performance than 
legacy/classic flows.  Can SCE results be presented that show the 
performance of competing flows (legacy/classic and SCE) in shared 
queues, but with the SCE classification disabled?

My suggestion to move forward is for the WG to better define the desired 
properties, behavior, and scope of low-latency ECN semantics assuming 
(in the long run) two inputs and two outputs, and to expand the 
evaluation framework to take into account the suggestions that others 
have made to include short flows, bidirectional traffic, asymmetry, 
jitter and network aggregation, and tunnels.  Constraints introduced by 
SCE and L4S could also be evaluated in the same framework.  If the WG 
were to reach consensus that, with enough bits, the objective design 
works well enough, but the constraints do not, then perhaps more effort 
could be devoted to finding more bits.  Jake Holland made one such 
proposal (ECT(1) to ECT(0), plus existing CE).  If low latency service 
is within reach but is blocked by some existing decapsulation rules that 
could be revised, why shouldn’t the WG try for that?  Appendix B of the 
AccECN draft hypothesizes that there may be creative ways to send both a 
low-level congestion and overload signal back to the sender.

- Tom