> I don't see what you gain by going after the Prague requirements. They're > internal requirements for a TCP that would fulfill the L4S goals if > classified into the L4S side of a DualQ AQM: 'Packet Identification' means > that the L4S AQM can identify L4S supporting flows. This seems like a > distraction from your main pitch to me. It would seem better to compare > against the actual goals of L4S (AFAICT, low latency at the 99th percentile, > in the presence of Reno-compatible flows, with some fairness requirement > which I increasingly don't understand).
We're certainly not treating the Prague Requirements as our only goals. We just looked over them and realised we do sufficiently well on them already to compare favourably against L4S. They are failing on their own merits. Like it or not, we are somewhat in competition with them in IETF space, so this sort of comparison should help to bolster our standing. A brief summary of the Prague Requirements: 1: Packet Identifier. We ID ourselves as RFC-3168 compliant using ECT(0), because we are. L4S has to identify itself more specifically to the network, because it is *not* RFC-3168 compliant. It additionally relies on AQMs in the network understanding this distinction, which at present none do. We would much prefer that they use a DSCP for this purpose, but at present they use ECT(1). 2: Accurate ECN Feedback. We use a spare bit in the header of TCP acks to feed back SCE marks, and the existing ECE/CWR mechanism from RFC-3168 unchanged for CE marks. The SCE feedback is "accurate" but not "reliable", because it can tolerate large errors (as much as 100% relative) without departing the control loop. The scheme is very simple and straightforward to implement at the receiver, and interpret at the sender. L4S uses AccECN to give CE mark feedback that is both "accurate" and "reliable". It is a somewhat complex specification which takes over three TCP header bits, including the two used for RFC-3168 feedback. 3: TCP-friendly response to packet loss. Both SCE and L4S do this without difficulty. 4: TCP-friendly response to RFC-3168 CE marking. SCE does this by design, retaining the existing feedback mechanism for CE marks and implementing an RFC-8511 (ABE) compliant response in each of the TCP algorithms presented so far. We can do this easily because CE and SCE information from the network is unambiguous. L4S presently does not do this, largely because CE marks from RFC-3168 AQMs are not easily distinguished vice CE marks from an L4S AQM. They seem to be working on some sort of solution, but it has not yet been demonstrated to work, and their paper describing it leaves a lot of open questions (including tuning constants). That we saw no demonstration of it at IETF-106 (indeed they even skipped over their planned talk on it in a side session dedicated to L4S) suggests to me that they found flaws that were difficult to overcome at short notice, and possibly even managed to look bad next to our demonstration of jitter tolerance at the Hackathon. This point has always been the main difference between L4S and SCE. 5: Reduced RTT dependence This is a mathematically interesting requirement which, at present, neither L4S nor SCE meets. Fundamentally, any two flows following the same congestion-signal response which makes average cwnd dependent solely on marking probability, and which share the same bottleneck queue and AQM and therefore experience the same marking probability, will converge to the same average cwnd and their relative throughputs will therefore be inversely proportional to their RTTs. This adequately describes both the pure AIMD response of Reno, and the so-called 1/p response of DCTCP (which TCP Prague apes slavishly). The steady-state cwnd formula for CUBIC, however, is a function of both p(CE) and RTT, such that its throughput should be proportional to the reciprocal quartic root of RTT, rather than linearly reciprocal. This assumes that CUBIC is not in its Reno compatibility regime, of course. So CUBIC is the standard to beat, or at least match, for this requirement. As I mentioned, I have an idea for how to do this. I've seen no evidence that the L4S team have any equivalent ideas; again, they're failing their own requirements. 6: Scale down to fractional effective cwnd. We technically achieve this with our preferred choice of pacing parameters, reducing send rate to 80% of a segment per RTT at the min-cwnd of 2 segments. We could easily do better with different pacing ratios. L4S have apparently implemented a packet size adjustment. We haven't tried it out yet, but we'll take their word for it for the moment. There's no inherent technical reason why we couldn't do the same. 7: Reordering tolerance on time basis (ie. RACK). Both SCE and L4S inherit this capability from the Linux TCP stack, so it's not a problem. FreeBSD also has a RACK compliant TCP stack which is being stabilised. Other criteria which we are actively considering are listed in, for example, RFC-5033. That makes a fun read if you're a masochist; I wonder about Pete sometimes. :-) - Jonathan Morton _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
