(too old to reply)
Ingemar Johansson S
2017-11-14 02:38:52 UTC

I am too, interested to see how DETNET and HULL compare to one another.
The 3GPP submissions below tried to motivate the addition of extra ECN support in NR (a.k.a 5G) to make L4S easier to implement. Unfortunately it did not gain traction, mainly because the standardization schedule for NR is heavily bloated. Still there is a possibility that it can be brought up on the table later on.


Motivation to improved ECN handling in NR (see especially section 7)

Stage 3 details on how to implement ECN support on the RLC layer
Date: Mon, 13 Nov 2017 03:58:26 +0800
Subject: Re: [Bloat] DETNET
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Matthias, Dave,
The sort of industrial control applications that detnet is targeting require far
lower queuing delay and jitter than fq_CoDel can give. They have thrown
around numbers like 250us jitter and 1E-9 to 1E-12 packet loss probability.
However, like you, I just sigh when I see the behemoth detnet is building.
Nonetheless, it's important to have a debate about where to go to next.
Personally I don't think fq_CoDel alone has legs to get (that) much better.
Less is More: Trading a little Bandwidth for Ultra-Low Latency in the Data
Center <https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf>
In HULL you have i) a virtual queue that models what the queue would be if
the link were slightly slower, then marks with ECN based on that.
ii)  a much more well-behaved TCP (HULL uses DCTCP with hardware pacing
in the NICs).
I would love to be able to demonstrate that HULL can achieve the same
extremely low latency and loss targets as detnet, but with a fraction of the
*Queuing latency?* This keeps the real FIFO queue in the low hundreds to
tens of microseconds.
*Loss prob?* Mohammad doesn't recall seeing a loss during the entire
period of the experiments, but he doubted their measurement
infrastructure was sufficiently accurate (or went on long enough) to be sure
they were able to detect one loss per 10^12 packets.
For their research prototype, HULL used a dongle they built, plugged into
each output port to constrict the link in order to shift the AQM out of the
box. However, Broadcom mid-range chipsets already contain vertual queue
How to Build a Virtual Queue from Two Leaky Buckets (and why one is not
enough) <http://bobbriscoe.net/pubs.html#vq2lb> ).
*For public Internet, not just for DCs?* You might have seen the work we've
done (L4S <https://riteproject.eu/dctth/>) to get queuing delay over regular
public Internet and broadband down to about mean 500us; 90%-ile 1ms, by
making DCTCP deployable alongside existing Internet traffic (unlike HULL,
pacing at the source is in Linux, not hardware).
My personal roadmap for that is to introduce virtual queues at some future
stage, to get down to the sort of delays that detnet wants, but over the
public Internet with just FIFOs.
Radio links are harder, of course, but a lot of us are working on that too.
Perceived that as shareworthy/entertaining ..
without wanting to belittle it.
Hope springs eternal that they might want to look over the relevant
codel and fq_codel RFCS at some point or another.
Not sure, appears like juxtaposing classical mechanics to nanoscale
Besten Gruß
Matthias Tafelmeier
Bloat mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
Subject: Digest Footer
Bloat mailing list
End of Bloat Digest, Vol 82, Issue 11