Add a transport that uses UDP or DTLS when multiplexing streams

[Lennie]

As I wasn't at the DockerCon I haven't heard how libchan is going to be used, but if multiple streams on top of these transports is a goal I suggest adding a datagram-based transport as well.

The reason is because of head-of-line blocking.

Obviously, HTTP/2 or SPDY is already better than HTTP/1.x or something like WebSocket at dealing with multiple streams.

But at the TCP level you can still get head-of-line blocking because if packets are lost they can not be reordered.

It's similar to the TCP tunneling in TCP problem: http://sites.inka.de/~W1011/devel/tcp-tcp.html

It is also (one of ?) the reasons https://en.wikipedia.org/wiki/QUIC is being developed.

An other example WebRTC which uses DTLS ('SSL'/TLS over UDP) at the lowerlevel and SCTP as the datachannel protocol for the multiplexing.

Obviously I wouldn't suggest implementing all of WebRTC, it's a pretty big specification.

But they are just examples of current protocols that already do this.

[progrium]

Totally agreed somebody should get started on a UDP based transport like QUIC.

[Lennie]

If I'm not mistake, there is only one implementation of QUIC that isn't enabled by default and no specification yet. Or at least no standardization process yet. So probably a bit early for that. :-)

But on the WebRTC datachannel front there are people (developers are CoreOS) that have already started on some code: https://github.com/coreos/go-webrtc-datachannel https://github.com/ccding/go-stun

So there was an interrest in doing that, but they stopped.

What is interresting about WebRTC is that is can do NAT traversal.

[progrium]

Yes, super early. Excited about CoreOS's datachannel work. Basically, I'm looking for a mid-level transport layer for Duplex: https://github.com/progrium/duplex/

I had considered also doing an HTTP2 transport layer for it... but for simplicity, since it needs to be implemented in C very soon, I think we'll just do our simple transport protocol. In the hopes that we can use libchan or something similar when available in C. I would try to help port libchan to C but it's probably too early and there are already many dependencies that would make it difficult.

[progrium]

I'm also happy to contribute my generic net/rpc server reflection code so that libchan can have net/rpc style interface on top of the low level req/rep API. There is a lot of overlap in all our work, so I hope we can figure out a way to collaborate and/or design them to work together. (For example, CoreOS's datachannel could be a libchan transport)

[Lennie]

There are existing SPDY/HTTP2 implementations in C like https://github.com/tatsuhiro-t/nghttp2

[progrium]

Yeah, that's one of the big ones and luckily it's there. Anyway, can't wait for a port to C...

[jbenet]

+1 for QUIC. This would make libchan usable in all high-bandwidth realtime apps, and p2p. (Note that TCP has issues in exposed networks, where anybody can forge RSTs).

[dmcgowan]

If someone wants to participate in building a QUIC golang implementation then I think progress can be made on this issue. Otherwise I will close it for now and we can re-address when there is a finalized QUIC spec or golang implementation.

[sheerun]

What's the status of it?

[dmcgowan]

@sheerun if you know of any Go libraries implementing QUIC I would love to give it a try. Also feel free to advocate for an alternative. As it stands now most this specifications are still fluid and Go implementations are not there.