4 ms·

> what would you want for an unreliable stream Video?

baby 9y ago
That's application specific, not protocol specific. Or maybe I didn't understand your comment? Could you be more specific about what DTLS doesn't provide for streaming that QUIC could have provided?
- Luker88 9y ago
  As far as I know, neither DTLS nor QUIC provide datagrm transport (as in: managing the beginning/end of user messages, regardless of size), I am not sure if DTLS does unordered delivery (probably not if it simulates a stream), and my favourite is that none can handle transmission of data in a "reliable multicast" fashion. By reliable-multicast I mean something like having a main multicast stream plus a unicast that delivers only the lost data. DTLS multicast also kind of sucks because all clients share the same keys for the MAC, meaning that the clients could spoof the server data towards other clients. Also, I am afraid the Forward Error correction of QUIC is a bit too basic to be really useful, which is why I developed a second library with more flexible FEC than just implementing raid-4 over the network. I am designing my protocol with that transport in mind, because I did not want to limit the user in what he could do. You can do all of this on the application, you can use even multiple stacks, but the upper layers are usually less efficient, more error prone, and we cause a global "reinvent the wheel" movement without even realizing it.
  - baby 9y ago
    > I am not sure if DTLS does unordered delivery That's an interesting point, indeed the RFC[1] seems to support your claim: > DTLS implementations maintain (at least notionally) a > next_receive_seq counter. This counter is initially set to zero. > When a message is received, if its sequence number matches > next_receive_seq, next_receive_seq is incremented and the message is > processed. If the sequence number is less than next_receive_seq, the > message MUST be discarded. If the sequence number is greater than > next_receive_seq, the implementation SHOULD queue the message but MAY > discard it. (This is a simple space/bandwidth tradeoff). [1]: https://tools.ietf.org/html/rfc6347 https://tools.ietf.org/html/rfc6347 > DTLS multicast I'm not seeing mentions of that in the RFC > Forward Error correction of QUIC I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?)
    - Luker88 9y ago
      >> DTLS multicast > I'm not seeing mentions of that in the RFC My bad, still a draft: https://datatracker.ietf.org/doc/draft-lucas-dtls-multicast/ https://datatracker.ietf.org/doc/draft-lucas-dtls-multicast/ > I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?) Nope, basically it should be: send X packets (X>=2), then the xor of those packets. Lose one, everything can be recovered Googoling again I see that they later disabled it 'cause it did not give the expected results on youtube: https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit# https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8... Which is not that surprising considering that network errors are more often in bursts, and they could recover only one error. I still think proper FEC can be useful, especially in networks with high packet loss (at 5% and up my experiments gave me a huge advantage over any control flow algorithm of TCP, even more on high-latency networks)

baby 9y ago

That's application specific, not protocol specific. Or maybe I didn't understand your comment? Could you be more specific about what DTLS doesn't provide for streaming that QUIC could have provided?

Luker88 9y ago
As far as I know, neither DTLS nor QUIC provide datagrm transport (as in: managing the beginning/end of user messages, regardless of size), I am not sure if DTLS does unordered delivery (probably not if it simulates a stream), and my favourite is that none can handle transmission of data in a "reliable multicast" fashion. By reliable-multicast I mean something like having a main multicast stream plus a unicast that delivers only the lost data. DTLS multicast also kind of sucks because all clients share the same keys for the MAC, meaning that the clients could spoof the server data towards other clients. Also, I am afraid the Forward Error correction of QUIC is a bit too basic to be really useful, which is why I developed a second library with more flexible FEC than just implementing raid-4 over the network. I am designing my protocol with that transport in mind, because I did not want to limit the user in what he could do. You can do all of this on the application, you can use even multiple stacks, but the upper layers are usually less efficient, more error prone, and we cause a global "reinvent the wheel" movement without even realizing it.
- baby 9y ago
  > I am not sure if DTLS does unordered delivery That's an interesting point, indeed the RFC[1] seems to support your claim: > DTLS implementations maintain (at least notionally) a > next_receive_seq counter. This counter is initially set to zero. > When a message is received, if its sequence number matches > next_receive_seq, next_receive_seq is incremented and the message is > processed. If the sequence number is less than next_receive_seq, the > message MUST be discarded. If the sequence number is greater than > next_receive_seq, the implementation SHOULD queue the message but MAY > discard it. (This is a simple space/bandwidth tradeoff). [1]: https://tools.ietf.org/html/rfc6347 https://tools.ietf.org/html/rfc6347 > DTLS multicast I'm not seeing mentions of that in the RFC > Forward Error correction of QUIC I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?)
  - Luker88 9y ago
    >> DTLS multicast > I'm not seeing mentions of that in the RFC My bad, still a draft: https://datatracker.ietf.org/doc/draft-lucas-dtls-multicast/ https://datatracker.ietf.org/doc/draft-lucas-dtls-multicast/ > I'm looking at the QUIC spec and I don't see anything about that, there doesn't seem to be any error correction done in QUIC (perhaps at the UDP level with the checksum you mean?) Nope, basically it should be: send X packets (X>=2), then the xor of those packets. Lose one, everything can be recovered Googoling again I see that they later disabled it 'cause it did not give the expected results on youtube: https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit# https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8... Which is not that surprising considering that network errors are more often in bursts, and they could recover only one error. I still think proper FEC can be useful, especially in networks with high packet loss (at 5% and up my experiments gave me a huge advantage over any control flow algorithm of TCP, even more on high-latency networks)