5 ms·

Honestly, I am kind of disappointed at QUIC. It could have been much more... * there is no support for non-reliable streams * I am not keen on the variabilit

Honestly, I am kind of disappointed at QUIC. It could have been much more... * there is no support for non-reliable streams * I am not keen on the variability and non-alignment of the whole header (which can go from 0 to 60+ bytes). * it points too much towards just reducing the RTT for the initial connection (0RTT is a bad idea, especially if your application now needs to handle the special case of the connection being 0RTT or not). * There is no support for datagrams, just datastreams. * Perfect forward secrecy is not granted on the initial handshake (you need to explicitly do a second key exchange for that) * Forward error correction is actually cool but just using XOR is too limited. * The proof of ownership of the connection is one incredible hack And these are just the things I remember from looking at it a couple of years ago. Still, it's a nice improvement over older protocols. To those that are going to comment something like "Well, then do your own": that's exactly what I'm doing although it's going slowly as I don't have Google's budget.

bryanlarsen 9y ago
Have you tried engaging with IETF-QUIC?
- Luker88 9y ago
  I'm a nobody, the protocol is already well defined and what I need would call for something close to a rewrite, which is why I am actually doing my own. Hopefully in a one or two months I will have a stable enough implementation so people might be interested enough to contribute, then I can think about writing a proper rfc.
  - niftich 9y ago
    If you can nonetheless voice a design issue, consider putting it on the record in their own forum [1], even if your concerns won't result in substantive changes in the end. [1] https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTI...
  - woah 9y ago
    From your website it sounds like your project is much bigger than just improving QUIC. Wouldn’t it make sense to bring your expertise to improve QUIC in the short term? It seems to be relatively common to hear people talk about how nobody will listen to them because of cronyism or something, but then the thing that they are proposing is actually a one-man rewrite of everything. Maybe nobody has the time to dig into your massive, non-working project. Also, it’s kind of an implicit statement that you are not interested in working with anyone else. Maybe if you approached things in a more collaborative way, your ideas would get some traction. I’m reminded of a relevant XKCD about standards here.
    - Luker88 9y ago
      QUIC has already enough intelligent people behind it, I'll look at the github page to see if I can say something, but the main difference is probably the scope. The scope of QUIC is quite clear: it aims at putting together TCP and TLS. It already does that well enough, it won't do more. I found that limiting, the only option I have is to do something myself. I tried talking to people around (conference and privately) but what I got from it is basically: first show that it can work, then we can talk. I tried to talk about the theory and objectives behind before the code, but without an implementation it does not seem to be worth much. Google is a big company that can put people to work on something and that gets things done, wether it is a good idea or not. I can't pay anyone, I have not found people interested in even only the theory, so I'll go on, and maybe something will change when things start to work.
      - euyyn 9y ago
        I encourage you to just enter the working group and engage them via whatever medium they're using. There's nothing to lose, really, and much potential win for both them and you.
baby 9y ago
> there is no support for non-reliable streams I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. > I am not keen on the variability and non-alignment of the whole header (which can go from 0 to 60+ bytes). Agree > it points too much towards just reducing the RTT for the initial connection (0RTT is a bad idea, especially if your application now needs to handle the special case of the connection being 0RTT or not). It's annoying because you need to try decrypting with two different keys, but it simplifies the handshake for both side as the state machine is now super simple > Perfect forward secrecy is not granted on the initial handshake (you need to explicitly do a second key exchange for that) if you're talking about 0-RTT, I think replayability is a much bigger problem than forward secrecy as forward secrecy is bound to the server config rotation, so you just need to rotate frequently. > The proof of ownership of the connection is one incredible hack How is it a hack? It allows the server to be stateless and it works quite well. How would you make it better?
- Luker88 9y ago
  > I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. I found it easy to include support for unreliable streams in my protocol, I'm just not sure why they did not even try. I heard about a hack-proposal where you could just use a new stream for one packet and then forget about it, but it's not really the same, and I am not sure they did even that. > It's annoying because you need to try decrypting with two different keys, but it simplifies the handshake for both side as the state machine is now super simple The issue I have with it is that now it's the application that needs to be sure not to write too much without an additional round-trip, otherwise you could end up with an amplification attack. I remember reading that there was an additional call to be made by the application just for that. But other simplifications in the handshake are actually great, yes. > if you're talking about 0-RTT, I think replayability is a much bigger problem than forward secrecy as forward secrecy is bound to the server config rotation, so you just need to rotate frequently. Yes, see above. But if I remember correctly rotating keys also makes client unable to use the 0-RTT, so you can't do it too often. QUIC has a weaker PFS than TLS. Still secure, just weaker, and basically disabled unless you explicitely call a key rotation. I am just afraid that the implementations and servers out there will not use that. > How is it a hack? It allows the server to be stateless and it works quite well. How would you make it better? Are we talking about the same thing? I meant the entropy bit. Really dislike it. (Then again, it works, eh...). Yep, my bad, I said "ownership of connection" instead of "ownership od the IP". The ownership of the connection is derived only from the connection id and crypto keys, that's a nice simplification, yes.
JulienSchmidt 9y ago
Regarding non-reliable streams: There is https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-01 https://tools.ietf.org/html/draft-tiesel-quic-unreliable-str..., while it won't be part of the initial standard, it's likely that the working group makes sure that it can be added later.
- Luker88 9y ago
  did not see that, thanks for the link
easytiger 9y ago
> * there is no support for non-reliable streams Can you have a stream based protocol that doesn't try to be reliable? A message oriented one i understand. > * There is no support for datagrams, just datastreams. because, I guess, you can always just use UDP!
- Luker88 9y ago
  I am currently building a protocol in which each stream can be any combination of (un)reliable,(un)ordered,datagram or datastream. Yes, some combinations make little sense, but it can be done. You only need the control stream to be reliable+ordered. UDP datagram limits you to the size of the packet. The basic difference of datagram and datastream is only wether you have a way to identify the start/end of the user messages. Think like TCP, were you don't need to handle the beginning and end of your messages.
  - lann 9y ago
    Have you looked at SCTP?
    - Luker88 9y ago
      yes, nice protocol, except everything is cleartext :)
Ralith 9y ago
> There is no support for datagrams, just datastreams. Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient. > Forward error correction is actually cool but just using XOR is too limited. Pretty sure FEC was removed from the IETF draft.
- Luker88 9y ago
  > Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient. Using discrete short-lived streams could mean a little more trouble understanding which message was in response to which other message. A stream of datagrams is already a logic container. But I gues you could track that by hand, too. Maybe I just found an easier way to implement all of that on the protocol, so I don't see why QUIC could not. Maybe it's just something that I always end up doing by hand so I would just be happier if was provided. I mean, IP/UDP already has all the primitives I need, but it's not like everyone likes to reinvent the wheel. > > Forward error correction is actually cool but just using XOR is too limited. > Pretty sure FEC was removed from the IETF draft. Yes, did not know about that. A pity, my experiments with proper FEC showed wonders after a minimum packet loss rate was surpassed. Even better on high-latencies.

bryanlarsen 9y ago

Have you tried engaging with IETF-QUIC?

Luker88 9y ago
I'm a nobody, the protocol is already well defined and what I need would call for something close to a rewrite, which is why I am actually doing my own. Hopefully in a one or two months I will have a stable enough implementation so people might be interested enough to contribute, then I can think about writing a proper rfc.
- niftich 9y ago
  If you can nonetheless voice a design issue, consider putting it on the record in their own forum [1], even if your concerns won't result in substantive changes in the end. [1] https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTI...
- woah 9y ago
  From your website it sounds like your project is much bigger than just improving QUIC. Wouldn’t it make sense to bring your expertise to improve QUIC in the short term? It seems to be relatively common to hear people talk about how nobody will listen to them because of cronyism or something, but then the thing that they are proposing is actually a one-man rewrite of everything. Maybe nobody has the time to dig into your massive, non-working project. Also, it’s kind of an implicit statement that you are not interested in working with anyone else. Maybe if you approached things in a more collaborative way, your ideas would get some traction. I’m reminded of a relevant XKCD about standards here.
  - Luker88 9y ago
    QUIC has already enough intelligent people behind it, I'll look at the github page to see if I can say something, but the main difference is probably the scope. The scope of QUIC is quite clear: it aims at putting together TCP and TLS. It already does that well enough, it won't do more. I found that limiting, the only option I have is to do something myself. I tried talking to people around (conference and privately) but what I got from it is basically: first show that it can work, then we can talk. I tried to talk about the theory and objectives behind before the code, but without an implementation it does not seem to be worth much. Google is a big company that can put people to work on something and that gets things done, wether it is a good idea or not. I can't pay anyone, I have not found people interested in even only the theory, so I'll go on, and maybe something will change when things start to work.
    - euyyn 9y ago
      I encourage you to just enter the working group and engage them via whatever medium they're using. There's nothing to lose, really, and much potential win for both them and you.

baby 9y ago

> there is no support for non-reliable streams I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. > I am not keen on the variability and non-alignment of the whole header (which can go from 0 to 60+ bytes). Agree > it points too much towards just reducing the RTT for the initial connection (0RTT is a bad idea, especially if your application now needs to handle the special case of the connection being 0RTT or not). It's annoying because you need to try decrypting with two different keys, but it simplifies the handshake for both side as the state machine is now super simple > Perfect forward secrecy is not granted on the initial handshake (you need to explicitly do a second key exchange for that) if you're talking about 0-RTT, I think replayability is a much bigger problem than forward secrecy as forward secrecy is bound to the server config rotation, so you just need to rotate frequently. > The proof of ownership of the connection is one incredible hack How is it a hack? It allows the server to be stateless and it works quite well. How would you make it better?

Luker88 9y ago
> I think the point of QUIC is to provide a reliable protocol. I'm not sure if this complaint is relevant. I found it easy to include support for unreliable streams in my protocol, I'm just not sure why they did not even try. I heard about a hack-proposal where you could just use a new stream for one packet and then forget about it, but it's not really the same, and I am not sure they did even that. > It's annoying because you need to try decrypting with two different keys, but it simplifies the handshake for both side as the state machine is now super simple The issue I have with it is that now it's the application that needs to be sure not to write too much without an additional round-trip, otherwise you could end up with an amplification attack. I remember reading that there was an additional call to be made by the application just for that. But other simplifications in the handshake are actually great, yes. > if you're talking about 0-RTT, I think replayability is a much bigger problem than forward secrecy as forward secrecy is bound to the server config rotation, so you just need to rotate frequently. Yes, see above. But if I remember correctly rotating keys also makes client unable to use the 0-RTT, so you can't do it too often. QUIC has a weaker PFS than TLS. Still secure, just weaker, and basically disabled unless you explicitely call a key rotation. I am just afraid that the implementations and servers out there will not use that. > How is it a hack? It allows the server to be stateless and it works quite well. How would you make it better? Are we talking about the same thing? I meant the entropy bit. Really dislike it. (Then again, it works, eh...). Yep, my bad, I said "ownership of connection" instead of "ownership od the IP". The ownership of the connection is derived only from the connection id and crypto keys, that's a nice simplification, yes.

JulienSchmidt 9y ago

Regarding non-reliable streams: There is https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-01 https://tools.ietf.org/html/draft-tiesel-quic-unreliable-str..., while it won't be part of the initial standard, it's likely that the working group makes sure that it can be added later.

Luker88 9y ago
did not see that, thanks for the link

easytiger 9y ago

> * there is no support for non-reliable streams Can you have a stream based protocol that doesn't try to be reliable? A message oriented one i understand. > * There is no support for datagrams, just datastreams. because, I guess, you can always just use UDP!

Luker88 9y ago
I am currently building a protocol in which each stream can be any combination of (un)reliable,(un)ordered,datagram or datastream. Yes, some combinations make little sense, but it can be done. You only need the control stream to be reliable+ordered. UDP datagram limits you to the size of the packet. The basic difference of datagram and datastream is only wether you have a way to identify the start/end of the user messages. Think like TCP, were you don't need to handle the beginning and end of your messages.
- lann 9y ago
  Have you looked at SCTP?
  - Luker88 9y ago
    yes, nice protocol, except everything is cleartext :)

Ralith 9y ago

> There is no support for datagrams, just datastreams. Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient. > Forward error correction is actually cool but just using XOR is too limited. Pretty sure FEC was removed from the IETF draft.

Luker88 9y ago
> Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient. Using discrete short-lived streams could mean a little more trouble understanding which message was in response to which other message. A stream of datagrams is already a logic container. But I gues you could track that by hand, too. Maybe I just found an easier way to implement all of that on the protocol, so I don't see why QUIC could not. Maybe it's just something that I always end up doing by hand so I would just be happier if was provided. I mean, IP/UDP already has all the primitives I need, but it's not like everyone likes to reinvent the wheel. > > Forward error correction is actually cool but just using XOR is too limited. > Pretty sure FEC was removed from the IETF draft. Yes, did not know about that. A pity, my experiments with proper FEC showed wonders after a minimum packet loss rate was surpassed. Even better on high-latencies.