1. 16
  1.  

  2. 8

    I’m really excited about Quinn, as it addresses a number of issues I’m trying to mitigate in a replication system I’m designing and implementing in rust:

    • a phone switching networks frequently as it’s synchronizing a database
    • HOL blocking while sending a mixture of metadata, blocks, and large blobs
    • kernel TCP bottlenecks
    1. 1

      If you’re worried about kernel TCP bottlenecks then you haven’t experienced the UDP bottlenecks. Kernel TCP can do a lot to improve performance.

      1. 1

        https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf

        ¯_(ツ)_/¯

        I’m curious about your experiences though, what are you specifically thinking of when you say that?

    2. 4

      Hmm, I’m not sure about QUIC. Witch TCP, every process used the in-kernel implementation of TCP. Now, every programming language has to make their own implementation of the transport layer protocol. What could possibly go wrong?

      1. 7

        The kernel could implement most of QUIC in the networking stack.

        TCP is showing it’s age a bit and I think QUIC is worth the pain of switching over, even if it means hitting a few roadbumps on the way.

        1. 6

          In practice, modern languages already face significant fragmentation if you want to interact with modern distributed systems :/ It’s not like the kernel handles HTTP, gRPC, thrift or any of the other things whose varying support across languages tends to impose significant constraints on the engineers who can interact with the systems that speak them.

          But at least Rust is easy to embed :]

          1. 4

            IIRC, a network driver installed TCP/IP on Windows long ago. Maybe Windows 12, Linux 5, and macOS 10.17 will have QUIC built-in?

            1. 1

              Yes, so there will be a transition period where application layer software will have the QUIC stack built-in.

              1. 3

                But! Keeping it in the application layer has been described as a benefit. As with many recent protocol things (TLS1.3) a big goal is preventing ossification, and not putting it in the kernel goes towards that.

            2. 3

              Maybe QUIC is something that can be implemented in the kernel networking stack in the future, once it is seen as viable protocol when enough applications are using it.

              1. 3

                That is true, and it seems this already has been done by some researchers.[1] However, as the kernel currently does not support is, languages will probably still implement it for legacy clients to take advantage of speed improvements to servers that support QUIC. I hope this mess of different implementations will be avoided.

                [1] https://dl.acm.org/citation.cfm?id=3242106