[Bloat] DETNET

[Matthias Tafelmeier]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171113/4ad5f45c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8ADF343B.asc
Type: application/pgp-keys
Size: 4729 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171113/4ad5f45c/attachment-0002.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171113/4ad5f45c/attachment-0002.sig>