<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<blockquote type="cite"
cite="mid:796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net">
<p>However, like you, I just sigh when I see the behemoth detnet
is building.</p>
</blockquote>
Does it? Well, so far the circumference seems justififiable for what
they want to achieve, at least according to what I can tell from
these rather still abstract concepts.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net">
<blockquote type="cite"
cite="mid:796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net">
<p>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.</p>
</blockquote>
<p>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. <br>
</p>
<p> </p>
</blockquote>
Certainly, all you said is valid - as I stated, I mostly wanted to
share the digest/the existance of the inititiative without
judging/reproaching/peaching ...<br>
<br>
<blockquote type="cite"
cite="mid:796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net">
<p>I prefer the direction that Mohamad Alizadeh's HULL pointed in:
<br>
<a moz-do-not-send="true"
href="https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf">Less
is More: Trading a little Bandwidth for Ultra-Low Latency in
the Data Center</a><br>
</p>
<p>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). <br>
</p>
<p>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 complexity.</p>
</blockquote>
Well, if it's already for specific HW, then I'd prefer to see RDMA
in place right away with getting rid of IRQs and other TCP/IP
specific rust along the way, at least for DC realms :) Although,
this HULL might has a spin for it from economics perspective. <br>
<br>
<blockquote type="cite"
cite="mid:796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net"><b>For
public Internet, not just for DCs?</b> You might have seen the
work we've done (<a moz-do-not-send="true"
href="https://riteproject.eu/dctth/">L4S</a>) 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. <br>
<br>
<br>
</blockquote>
Thanks for sharing, that sounds thrilling - especially the achieved
latencies and the non-spec. HW needs. All the best with it, again,
maybe more an economical quarrel to overcome then again.<br>
<br>
<pre class="moz-signature" cols="72">--
Besten Gruß
Matthias Tafelmeier
</pre>
</body>
</html>