4 ms·

Garh. So we are to believe that the people who thought that multiplexing a single TCP connection over mobile was a good idea, that moving lockstock and barrel

Garh. So we are to believe that the people who thought that multiplexing a single TCP connection over mobile was a good idea, that moving lockstock and barrel to UDP will solve our problems? Look, its very simple: HTTP is now a file server protocol with a chatty control channel smashed in. However instead of optimising for that we have this. It basically seems like a massive ego trip: "we can't admit we were wrong about the multiplexing thing, lets just bash out a reliable UDP protocol" Look, the vast majority of file transfer protocols are TCP for a reason. Loosing chunks of files is annoying, and making a custom protocol over UDP that is both fast start reliable and fast, is actually quite difficult. Yes, UDP has the advantage that you don't have a connection, and you can just fire stuff at the destination port and it'll magically arrive. however, anyone can do that. How does HTTP3 handle noise? how does it handle spoofing? Basically, H2 was a regression because it was designed by people who didn't appear to understand real world networks, this seems like a doubling down.

vlovich123 8y ago
It seems like you're just saying things without having actually researched how QUIC works. QUIC is the next iteration of TCP. That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built, but it's a reliable in-order transport (+ guaranteed encryption, loss of packets on a stream doesn't block other unrelated streams, etc).
- KaiserPro 8y ago
  > without having actually researched how QUIC works I have evaluated QUIC, as reliable stream protocols on UDP are something I have a professional interest in. > QUIC is the next iteration of TCP Its not designed for that. > That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Thats not considering flow control, which is a whole 'nother issue. Its always a trade-off between efficiency, speed and reliability.
  - tialaramex 8y ago
    QUIC is an encrypted protocol. If an adversary injects forged packets the AEAD tag won't match in decryption and those packets will be discarded. I would suggest an evaluation in which you completely omitted to notice the central feature of the protocol doesn't reflect well on your abilities, regardless of whether you claim it's a "professional interest".
    - KaiserPro 8y ago
      encrypting the whole protocol intrinsically protects against denial of service, buffer overflows and other common mistakes how exactly? My point is this, the client is protected from a _lot_ of noise. QUIC changes this.
      - tialaramex 8y ago
        Er, no. What happened is you have no idea what you're talking about.
        KaiserPro 8y ago
        so your saying that in TCP, a connection orientated protocol, at each hop the router/firewall/kernel is _not_ doing basic validation to see if that connection is valid, and not coming from a spurious source? The client does all this when you open socket.connect()? no, no, you're not and no, it doesn't, which is part of my point. Lots more noise will be forwarded to the client directly, after all, stateful connection management is impossible. With more noise, comes a bigger attack surface.
  - vlovich123 8y ago
    > Its not designed for that. Yes, yes it is. I did 20% on Quic, I've talked with the engineers on it, I've read a lot of the paper, I've written some code. It's 100% intended to replace TCP as much as SCTP & other next-gen stream-oriented protocols are. It's written on top of UDP because they're dealing with the realities of public routing on the internet. > no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. This again leads me to question how much you've actually researched Quic. It does all that & more. Now it is easier to write a Quic client in user-space that misbehaves for flow control & distribute that (TCP would typically require root access). However, that's the reality of the Internet - middleboxes have ossified the ability to add new protocols. It's why SCTP & the like are non-starters even though IETF has tried to get them to work for so long. > Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Are spoofed packets validated at every hop? It would seem like memory & CPU load at backbones would be insane to keep track of all the connections flowing across it. I'm also curious how that would be possible because a backend route switch (i.e. new BGP route) would cause all middleboxes to drop the connection. I'm not sure even ISPs try to reject TCP connections early. As for the "protection" you lose (if there is any), you gain by your ability to hop physical networks without losing the connection (i.e. WiFi & cellular). This means there's all sorts of cool things you can do that simply weren't possible before; use both wifi & cellular at the same time to download the same file, seamless handoff of a video chat without requiring any ISP support, seamless detection & handoff of a failing internet route to a fallback connection (i.e. walking in the parking lot without having to manually switch off WiFi). The connection itself does have a connection ID in the public header in the version negotiation packet which is then mirrored in the encrypted packet header to protect against spoofing. However, the connection ID may be omitted from the public header in future packets. Anyway, I recommend reading the IETF docs on QUIC [1][2], if you have an open mind. If you just have the mentality of "UDP bad", then probably you will be wasting your own time reading it. There's lots of really smart networking experts who work on & design QUIC & lots of smart people in IETF looking over & providing feedback/criticism. I think it's safe to assume they've covered any obvious problems concerns. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-08#page-81 https://tools.ietf.org/html/draft-ietf-quic-transport-08#pag... [2] https://tools.ietf.org/id/draft-ietf-quic-manageability-01.html#rfc.section.4 https://tools.ietf.org/id/draft-ietf-quic-manageability-01.h...

vlovich123 8y ago

It seems like you're just saying things without having actually researched how QUIC works. QUIC is the next iteration of TCP. That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built, but it's a reliable in-order transport (+ guaranteed encryption, loss of packets on a stream doesn't block other unrelated streams, etc).

KaiserPro 8y ago
> without having actually researched how QUIC works I have evaluated QUIC, as reliable stream protocols on UDP are something I have a professional interest in. > QUIC is the next iteration of TCP Its not designed for that. > That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Thats not considering flow control, which is a whole 'nother issue. Its always a trade-off between efficiency, speed and reliability.
- tialaramex 8y ago
  QUIC is an encrypted protocol. If an adversary injects forged packets the AEAD tag won't match in decryption and those packets will be discarded. I would suggest an evaluation in which you completely omitted to notice the central feature of the protocol doesn't reflect well on your abilities, regardless of whether you claim it's a "professional interest".
  - KaiserPro 8y ago
    encrypting the whole protocol intrinsically protects against denial of service, buffer overflows and other common mistakes how exactly? My point is this, the client is protected from a _lot_ of noise. QUIC changes this.
    - tialaramex 8y ago
      Er, no. What happened is you have no idea what you're talking about.
      - KaiserPro 8y ago
        so your saying that in TCP, a connection orientated protocol, at each hop the router/firewall/kernel is _not_ doing basic validation to see if that connection is valid, and not coming from a spurious source? The client does all this when you open socket.connect()? no, no, you're not and no, it doesn't, which is part of my point. Lots more noise will be forwarded to the client directly, after all, stateful connection management is impossible. With more noise, comes a bigger attack surface.
- vlovich123 8y ago
  > Its not designed for that. Yes, yes it is. I did 20% on Quic, I've talked with the engineers on it, I've read a lot of the paper, I've written some code. It's 100% intended to replace TCP as much as SCTP & other next-gen stream-oriented protocols are. It's written on top of UDP because they're dealing with the realities of public routing on the internet. > no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. This again leads me to question how much you've actually researched Quic. It does all that & more. Now it is easier to write a Quic client in user-space that misbehaves for flow control & distribute that (TCP would typically require root access). However, that's the reality of the Internet - middleboxes have ossified the ability to add new protocols. It's why SCTP & the like are non-starters even though IETF has tried to get them to work for so long. > Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Are spoofed packets validated at every hop? It would seem like memory & CPU load at backbones would be insane to keep track of all the connections flowing across it. I'm also curious how that would be possible because a backend route switch (i.e. new BGP route) would cause all middleboxes to drop the connection. I'm not sure even ISPs try to reject TCP connections early. As for the "protection" you lose (if there is any), you gain by your ability to hop physical networks without losing the connection (i.e. WiFi & cellular). This means there's all sorts of cool things you can do that simply weren't possible before; use both wifi & cellular at the same time to download the same file, seamless handoff of a video chat without requiring any ISP support, seamless detection & handoff of a failing internet route to a fallback connection (i.e. walking in the parking lot without having to manually switch off WiFi). The connection itself does have a connection ID in the public header in the version negotiation packet which is then mirrored in the encrypted packet header to protect against spoofing. However, the connection ID may be omitted from the public header in future packets. Anyway, I recommend reading the IETF docs on QUIC [1][2], if you have an open mind. If you just have the mentality of "UDP bad", then probably you will be wasting your own time reading it. There's lots of really smart networking experts who work on & design QUIC & lots of smart people in IETF looking over & providing feedback/criticism. I think it's safe to assume they've covered any obvious problems concerns. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-08#page-81 https://tools.ietf.org/html/draft-ietf-quic-transport-08#pag... [2] https://tools.ietf.org/id/draft-ietf-quic-manageability-01.html#rfc.section.4 https://tools.ietf.org/id/draft-ietf-quic-manageability-01.h...