Hi Jonathan,
> On Nov 30, 2019, at 02:39, Jonathan Morton <chromati...@gmail.com> wrote:
>
>> 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.
Question: How feasible would it be for any SCE aware transport protocol to
evaluate AccECN? This might make sense if not viewed from a technical but from
a ietf politics perspective?
I personally believe, that if the ECN feedback woukd e really important it
should be packeged into TCP data as the payload has some delivery guarantees,
while ACKs are effectively best effort (tangent: and this is why I consider ACK
filtering/compression as abominations which should be counted against any
guarantee the contract with the traffic-carrier entails, not that this helps
end customers).
>
>
> 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.
I fear that they will come up with something that in reality will a) by
opt-out, that is they will assume L4S-style feedback until reluctantly
convinced that the bottleneck marker is rfc3160-compliant and hence wib)
trigger too late c) trigger to rarely to be actually helpful in reality, but
might show a good enough effort to push L4S past issue #16.
>
> This point has always been the main difference between L4S and SCE.
> ll
>
> 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.
"Funny" story, looking at figure 6 of Høiland-Jørgensen T, Hurtig P,
Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential
setting. Computer Networks 89:90–106. shows clearly that a) single queue Pie
(the AQM L4S inflicts upon at least the standard compliant traffic) causes
worse RTT dependence than pfifo_fast and that fq_codel actually does (mostly)
better, so by avoiding FQ like the devil, the L4S team shoots their own foot.
Best Regards
Sebastian
>
> 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
>
> _______________________________________________
> Ecn-sane mailing list
> ecn-s...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
