[Bloat] DETNET

[Matthias Tafelmeier]

>
> - RDMA didn’t work well on Ethernet until recently, but this was fixed
> by a technique called DCQCN (Mellanox), or its cousin TIMELY (Google).
>  Microsoft recently had a SIGCOMM paper on running RDMA+DCQCN side by
> side with TCP/IP support their Azure platform, using a single data
> center network, 100Gb.  They found it very feasible, although
> configuration of the system requires some sophistication.  Azure
> supports Linux, Mesos, Windows, you name it. 
Yes, here's the DCQCN paper:
https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p523.pdf
Really besoothing read for any TCP cc interested person, actually.
TIMELY is quite impressive, either. Wasn't ware of that, thanks for
sharing. THought Google was refraining to use RDMA since of it
effectively not getting rid of the TAIL-LOSS scenarios, but obviously
only for the WAN use case.

> The one thing they didn’t try was heavy virtualization.  [...]
>
That should have been covered by now, though not by Microsoft, I saw
recent work being done by a certain virtualization vendor exploiting
RDMA for it's 'all the rage' storage stack. Therefore, it shouldn't be a
real stumbling block.

>
> .  It can also discover that you lack RDMA hardware and in that case,
> will automatically use TCP. 
But hold on, that's still useless, isn't it, since it does get
capricious/shaky rather quickly? Does this still hold?


> We are doing some testing of pure LibFabrics performance now, both in
> data centers and in WAN networks (after all, you can get 100Gbps over
> substantial distances these days...

> Cornell has it from Ithaca to New York City where we have a hospital
> and our new Tech campus).  We think this could let us run Derecho over
> a WAN with no hardware RDMA at all.
>
Interesting, are you planning to cast this WAN evaluations into a paper
or other pieces of intelligence? Never thought it'd make it out of the
data centre, actually. There is hardly any read in this direction.


-- 
Besten Gruß

Matthias Tafelmeier

-------------- 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/20171120/68b550b0/attachment.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/20171120/68b550b0/attachment.sig>