[Bloat] DETNET

Ken Birman kpb3 at cornell.edu
Wed Nov 15 16:01:56 EST 2017


If you love low latency and high speed, you will be blown away by http://www.cs.cornell.edu/derecho.pdf

The system itself is on GitHub as "Derecho-Project".  Quite useable!  In fact we are still working on some last-steps, so the version there is v0 (maybe two more months before we consider it to be release v1).  We would love to have users who are intent on breaking everything...  all open source, no weird IP or anything, no plan to commercialize it.

Ken

-----Original Message-----
From: Dave Taht [mailto:dave at taht.net] 
Sent: Wednesday, November 15, 2017 3:16 PM
To: Matthias Tafelmeier <matthias.tafelmeier at gmx.net>
Cc: Ken Birman <kpb3 at cornell.edu>; Bob Briscoe <ietf at bobbriscoe.net>; ken at cs.cornell.edu; bloat at lists.bufferbloat.net
Subject: Re: [Bloat] DETNET

Matthias Tafelmeier <matthias.tafelmeier at gmx.net> writes:

> On 11/15/2017 08:45 PM, Ken Birman wrote:
>> I'm missing context.  Can someone tell me why I'm being cc'ed on these?  
> right, I cced you so I'm liable to clarify.
>
>> Topic seems germane to me (Derecho uses RDMA on RoCE) but I'm unclear what this thread is "about"
>
> I perceived you as a strong kind of advocate for RDMA, at least that's 
> a supposition I hold ever since having read your blogs/research around it.
> It was mentioned here in context with other existing or already 
> pertaining technologies as to the purpose of improving network 
> performance in general - especially for certain domains. Therefore, I 
> thought blending/exchanging knowledge or inciting a discussion might 
> be profitable for both worlds.

I'm notorious for trying to engage other folk slightly outside our circle, thx for carrying on the grand tradition. I do admit it can be quite a lot to get blindsided by!

>
> Originally, this ML is for the Bufferbloat project, but, occassionally 
> it does get captivated ...

Well, the overarching goal here is to reduce latencies on everything (hardware, interconnects, busses, drivers, oses, stacks) to the bare minimum, on every technology we can reach, and leverage other ideas in other technologies to do so, whenever possible.

If we had a name for that, other than bufferbloat, I'd switch to it, because we are way beyond just dealing with excessive buffering after 6+ years of operation.

I will got read up on ken's RDMA stuff.

>
>>> Feel free to tinker your bayes filter if all sounds too alien.<<


More information about the Bloat mailing list