9 ms·

The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Bein

The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.

jandrese 8y ago
The rallying cry of everybody who later comes to the realization that they have re-implemented TCP.
- treve 8y ago
  Maybe re-implemented SCTP, but this time it's usable.
- Jasper_ 8y ago
  So what if we use our experiences and in-depth knowledge of a past protocol, take into account the flaws, and build something better? You say "re-implemented TCP" as if it's the only possible way to build a reliable packet protocol, and that it has no flaws, and we can't make any improvements to it. TCP isn't alien technology we don't understand. We do understand it, and its limits, and its constraints, and that means we can build a better one next time.
- RcouF1uZ4gsC 8y ago
  The problem with coming “to the realization that they have re-implemented TCP” is that it was ad-hoc. In this situation, the re-implementation was done by people very familiar with TCP, both its strengths, weaknesses, and assumptions, who very deliberately set out to “re-implement” TCP to work better with how are networks actually are configured.
mehrdadn 8y ago
How does it work with a debugger? With TCP the connection didn't die just because you paused the program. But when everything is in userspace then that can't happen anymore?
- shereadsthenews 8y ago
  We aren’t talking about raw networking; generally a QUIC implementation uses the kernel UDP stack, which buffers packets until read.
  - mehrdadn 8y ago
    No but TCP sends keep-alive packets or something in the kernel right? If you can't send anything by the timeout then the connections should drop?
    - shereadsthenews 8y ago
      Vanilla TCP does not do this. Sockets remain established forever in the absence of traffic.
      - xorcist 8y ago
        This is a core feature in TCP/IP. Only the endpoints actually involved in the connection care about what a "connection" really is. If they share a connection, it should be nobody else's business that they do.
        mehrdadn 8y ago
        This is definitely not true in this world which is filled with NATs everywhere. The intermediate routers very much care and must care about what connections exist.
    - tlb 8y ago
      Only if you set the keepalive option, such as: int yes = 1; setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof(yes)); Most servers (Xserver, imapd, sshd) set it.
  - rdtsc 8y ago
    > UDP stack, which buffers packets until read Not really. Or just up to a point only. Then it will drop them into the bit bucket without telling either the sender or receiver. With TCP the sender will "find out" eventually the receiver isn't getting the data. The point is that with streams on top of UDP all that has to happen in the application layer.
brodouevencode 8y ago
> Being in userspace is a feature. This.
merb 8y ago
well HTTP/2 makes a lot of timing assumptions as well. just that it happens in user space.
anth_anm 8y ago
Until someone writes it into the kernel at which point that won't be a feature anymore.
- detaro 8y ago
  Except you don't have to use it if you don't like the kernel option, which a normal application can't do for TCP.
  - anth_anm 8y ago
    That's true, I didn't think of it like that.
toast0 8y ago
Would we be better served by Google reimplementing TCP on top of UDP, or by fixing TCP in Android, and on their servers, and telling us how they did it? If it's better for TCP to be handled in userspace, fine -- they should build the APIs for that on the OSes they control; and agitate for it in the OSes they don't. And, maybe, just maybe, they could turn on path MTU blackhole detection, please please please please please; it's only been in the Linux kernel for all versions of Android, but not turned on.
- deleted 8y ago
  [deleted]

The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.

jandrese 8y ago

The rallying cry of everybody who later comes to the realization that they have re-implemented TCP.

treve 8y ago
Maybe re-implemented SCTP, but this time it's usable.
Jasper_ 8y ago
So what if we use our experiences and in-depth knowledge of a past protocol, take into account the flaws, and build something better? You say "re-implemented TCP" as if it's the only possible way to build a reliable packet protocol, and that it has no flaws, and we can't make any improvements to it. TCP isn't alien technology we don't understand. We do understand it, and its limits, and its constraints, and that means we can build a better one next time.
RcouF1uZ4gsC 8y ago
The problem with coming “to the realization that they have re-implemented TCP” is that it was ad-hoc. In this situation, the re-implementation was done by people very familiar with TCP, both its strengths, weaknesses, and assumptions, who very deliberately set out to “re-implement” TCP to work better with how are networks actually are configured.

mehrdadn 8y ago

How does it work with a debugger? With TCP the connection didn't die just because you paused the program. But when everything is in userspace then that can't happen anymore?

shereadsthenews 8y ago
We aren’t talking about raw networking; generally a QUIC implementation uses the kernel UDP stack, which buffers packets until read.
- mehrdadn 8y ago
  No but TCP sends keep-alive packets or something in the kernel right? If you can't send anything by the timeout then the connections should drop?
  - shereadsthenews 8y ago
    Vanilla TCP does not do this. Sockets remain established forever in the absence of traffic.
    - xorcist 8y ago
      This is a core feature in TCP/IP. Only the endpoints actually involved in the connection care about what a "connection" really is. If they share a connection, it should be nobody else's business that they do.
      - mehrdadn 8y ago
        This is definitely not true in this world which is filled with NATs everywhere. The intermediate routers very much care and must care about what connections exist.
  - tlb 8y ago
    Only if you set the keepalive option, such as: int yes = 1; setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof(yes)); Most servers (Xserver, imapd, sshd) set it.
- rdtsc 8y ago
  > UDP stack, which buffers packets until read Not really. Or just up to a point only. Then it will drop them into the bit bucket without telling either the sender or receiver. With TCP the sender will "find out" eventually the receiver isn't getting the data. The point is that with streams on top of UDP all that has to happen in the application layer.

brodouevencode 8y ago

> Being in userspace is a feature. This.

merb 8y ago

well HTTP/2 makes a lot of timing assumptions as well. just that it happens in user space.

anth_anm 8y ago

Until someone writes it into the kernel at which point that won't be a feature anymore.

detaro 8y ago
Except you don't have to use it if you don't like the kernel option, which a normal application can't do for TCP.
- anth_anm 8y ago
  That's true, I didn't think of it like that.

toast0 8y ago

Would we be better served by Google reimplementing TCP on top of UDP, or by fixing TCP in Android, and on their servers, and telling us how they did it? If it's better for TCP to be handled in userspace, fine -- they should build the APIs for that on the OSes they control; and agitate for it in the OSes they don't. And, maybe, just maybe, they could turn on path MTU blackhole detection, please please please please please; it's only been in the Linux kernel for all versions of Android, but not turned on.

deleted 8y ago
[deleted]