Re: [Bloat] DETNET

[Matthias Tafelmeier <matthias.tafelmeier@gmx.net>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2534 bytes --]



> However, like you, I just sigh when I see the behemoth detnet is building.
>
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.
 

>> 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.
>>
> 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.
>
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 ...

> I prefer the direction that Mohamad Alizadeh's HULL pointed in:
> 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 complexity.
>
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.

> *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.
>
>
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.

-- 
Besten Gruß

Matthias Tafelmeier


[-- Attachment #1.1.1.2: Type: text/html, Size: 3847 bytes --]

[-- Attachment #1.1.2: 0x8ADF343B.asc --]
[-- Type: application/pgp-keys, Size: 4806 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]