Suggestion: HTTP2 overlay

[dimaqq]

Would it not be cool if logical datagrams could be sent as messages over HTTP2, both client and server taking care not to fill the buffers obv. (if buffer seems full, it's better to open a new connection).

The upside is no more problems with admins and ports, plus a more modern security model and libraries.

[Kriechi]

Encapsulating Mosh in HTTP in HTTP/2 in TCP - sounds a bit weird, doesn't it?
Especially since one of the main benefits of Mosh is its UDP-based protocol.

Sorry, but I'm 👎 on this one.

[dimaqq]

@Kriechi just to clarify my concept:

• HTTP/* is much more available (wrt. firewalls, egress, load balancing, client libraries)
• datagram semantics can be implemented on top of HTTP/2 by watching transmit queue
• HTTP/1.0/1.1 are not particularly interesting, I know :)
• HTTP/2 and WebSocket however still fit into mosh paradigm, albeit with limitations

IMO it's a trade-off, where UDP-only mosh stays niche but awesome; while mosh with a choice of UDP and HTTP2 can be very popular and still provide awesome latency in best case and perhaps in the amortised worst case too.

Looking back at history of ssh it would have never became widespread if it were not over TCP.

I gut feeling is that worse if better in a sense that good but not perfect latency that's available to many users will generate more interest and those users will figure out how to improve mosh further.

[Kriechi]

So this now becomes a duplicate of #13, right?

[dimaqq]

It's related, sure. I guess it's more like the "TCP minion" suggestion in #13.

There are pros and cons, for example, public HTTP/2 requires TLS, and mosh gets half the security for free, at the expense of slower session set-up and reconnect, while user login stays custom; in the minion case, though, latency stays almost same as UDP, but there's a chance that conservative firewalls will block the traffic.

I dunno what's better, I proposed HTTP/2 for wides possible audience right now (custom client) and later (imagine one day hosting the terminal on a web page).

[Kriechi]

I'm not sure how an efficient mapping into HTTP/2 would look like.
Sending full-blown HTTP requests and responses is way too much overhead!
Can you maybe give an example how to encapsulate Mosh data in HTTP/2 semantics?

[dimaqq]

@timofonic an interesting idea, I'm afraid QUIC is still too young/obscure (browsers: chrome, opera via flags; open source servers: ???, firewalls: ???, load balancers: ???, level-4 routers: ???, virtual hosts: ???)

The core of this proposal is a widely accepted transport (thus: TCP, TLS, HTTP*) that's barely sufficient for task at hand (thus: HTTP2 streams or server push, WebSocket).

[huitema]

There are two versions of QUIC: GQuic, the version defined by Google and evolving with the Chrome browser, and the version in process of standardization by the IETF in the QUIC WG. There are 6-7 implementations of IETF QUIC, all work in progress tracking and helping the development of the standard. The next interim test between these versions is planned for early October, and it will stabilize about 80% of the spec. Expect more progress in the next 6 to 12 months.

…

-- Christian Huitema

On Aug 21, 2017, at 6:37 AM, Dima Tisnek ***@***.***> wrote: @timofonic an interesting idea, I'm afraid QUIC is still too young/obscure (browsers: chrome, opera via flags; open source servers: ???, firewalls: ???, load balancers: ???, level-4 routers: ???, virtual hosts: ???) The core of this proposal is a widely accepted transport (thus: TCP, TLS, HTTP*) that's barely sufficient for task at hand (thus: HTTP2 streams or server push, WebSocket). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cgull]

@dimaqq, I'll point out that HTTP/2 is still layered on top of TCP and the datagram semantics are still subject to TCP stream ordering and error recovery. That would break one of Mosh's primary features-- usable behavior over really bad networks.

Arguably, mosh would have never became widespread if it were not over UDP.

It would be possible to work around TCP behavior to some degree by rapidly switching to a new TCP connection when an expected message is not seen, but this use would still be somewhat vulnerable to bad networks because of the 3-way handshake needing to complete.

@timofonic, using QUIC is an interesting idea, though I'm not sure how much benefit it has for us over our existing transport. Encapsulating in, or imitating, DTLS would be a similar approach. I think DTLS is more common/widespread (client VPN usage, mostly), so middleboxes are more likely to be able to handle it. DTLS session setup has the same issues as TCP 3-way handshake though.

[ishitatsuyuki]

QUIC is the most interesting thing here, and using HTTP probably isn't a thing we are going to do soon (we need to work with TCP first).

[arekm]

@timofonic, using QUIC is an interesting idea, though I'm not sure how much benefit it has for us over our existing transport.

QUIC doesn't need multiple udp ports to work on server side AFAIK.

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1

[andersk]

@arekm The reason Mosh needs a different UDP port per session is a consequence of its strong privilege separation model, not its transport protocol. Different Mosh sessions are handled by different mosh-server processes started independently over SSH (possibly by different users), so they can't listen on the same port. This is unlike a web server (or the SSH server itself) where many sessions are started just by connecting to a single daemon that's already listening on some port. In order for Mosh to use a single port for multiple sessions, some central multiplexing daemon like #295 would be required. None of this would change if the protocol were switched to QUIC.

[varanauskas]

Would it be possible to use HTTPS/WebSockets for signalling purposes only? And keep the UDP for mosh itself?

A use case for this is not exposing a server with a dynamic IP behind cloudflare to unauthenticated users:

1. User does signalling over HTTPS/WSS: user -HTTP/WSS-> cloudflare -HTTP/WSS-> server
2. If user authenticated user gets UDP details over the same connection and connects directly user -UDP-> server

[dimaqq]

I think at this point, HTTP3 should be considered instead, as it's ultimately built on top of UDP.