10 ms·

So, UDP.

by makira 9y ago

So, UDP.

funkaster 9y ago
not exactly: > If it’s used that way, it makes TCP a reliable, in-order protocol. the key here is "in-order".
- Dylan16807 9y ago
  It's absolutely trivial to put a sequence number in UDP packets. The question is whether you want the other mechanisms of TCP: handshaking, (limited) retransmission, flow control...
  - digi_owl 9y ago
    Never mind that most sensible streaming formats will include data in packets that allows the receiver to rebuild missing packets (up to a threshold).
    - isostatic 9y ago
      A typical rtp stream will have smpte fec on top, allowing burst lost of say 20 packets, or random loss theoretically upto 5% In the last 10 years of streaming rtp over the Internet the vast majority of failures is bursty. Reordering is more rare than you'd expect. Looking at one sample from India to Europe over a period of 6 weeks, my 30mbit rtp stream was fine 99.998% with fec. The rest of the time that's why I dual stream, either timeshift (send the same packet again 100ms later - as I said most outages are time based), or dual path (although if the packets traverse the same router en route there are issues), or even both.
mordero 9y ago
I don't think that is quite true. I believe with UDP there is no promise of packets being received in order. I think this article is saying that you still get the benefits of processing the packets in the order received, but you don't have to worry about the latency of waiting for the re-transmission of any packets.
- vvanders 9y ago
  It's so trivial to add ordering to UDP, it's really the right protocol to use here. Subverting TCP leads to all sorts of problems around congestion(which you can no longer filter on because which TCP streams are being non-compliant?) that it just should not be done.
  - marcosdumay 9y ago
    > It's so trivial to add ordering to UDP Specially when compared with creating and using a user space IP protocol like was done here, or adding a new one into the kernel.
  - JoeAltmaier 9y ago
    TCP layer also gives you pacing, congestion control and flow control. Which UDP, you'd have to do yourself?
    - JoeAltmaier 9y ago
      And its not totally trivial to reorder UDP. Say you receive packets 1,2,3,5. How long to you wait for '4'? Maybe it was dropped; maybe its coming. Then you get 6,7. Is 4 still out there? You've got 3 packets in your pocket, waiting for 4. That adds up too. TCP gives you some idea of what packets you SHOULD have received, so you can respond better. UDP doesn't have any windowing etc so you have no idea.
      - vvanders 9y ago
        I guess I don't really see the big issue with that. It's not like windowing and congestion control is some kind of black magic. It's spelled out pretty cleanly in the TCP RFC and pretty straight-forward to reimplement. Generally if you're hitting cases where TCP is causing you grief and you need to reach for UDP you've already got enough context to understand your congestion problems/etc. We've been doing this in game-dev for decades, ditto the voip space so it's not like you don't have a wealth of knowledge to draw from if you're really stumped.
andreasvc 9y ago
No. UDP is connectionless, which makes it harder to use with NAT.
- xxpor 9y ago
  Not sure why you say that, UDP conntracking has been around for a long time.
  - trav4225 9y ago
    I suspect that what andreasvc meant is that the default "NAT" configuration of most consumer-grade gear is such that it will block UDP (unless some other mechanism such as UPnP is used)...
    - noselasd 9y ago
      But it doesn't. Consumer gear NATs UDP pretty much as nice as it does TCP.
      - trav4225 9y ago
        Hmm, perhaps you are right... I switched from consumer gear to more "enterprise-y" gear a few years back, so my data points may be a bit outdated.
        testvox 9y ago
        I've been using normal consumer routers for NATed home connects since 2004 or so and I've never had an issue with outgoing UDP. It's required for basically every video game after all.
    - lmns 9y ago
      That's true for TCP as well. Almost all consumer-grade routers block all incoming connection attempts, not just UDP. From a stateful firewall's point of view both UDP and TCP have state.

So, UDP.

by makira 9y ago

So, UDP.

funkaster 9y ago

not exactly: > If it’s used that way, it makes TCP a reliable, in-order protocol. the key here is "in-order".

Dylan16807 9y ago
It's absolutely trivial to put a sequence number in UDP packets. The question is whether you want the other mechanisms of TCP: handshaking, (limited) retransmission, flow control...
- digi_owl 9y ago
  Never mind that most sensible streaming formats will include data in packets that allows the receiver to rebuild missing packets (up to a threshold).
  - isostatic 9y ago
    A typical rtp stream will have smpte fec on top, allowing burst lost of say 20 packets, or random loss theoretically upto 5% In the last 10 years of streaming rtp over the Internet the vast majority of failures is bursty. Reordering is more rare than you'd expect. Looking at one sample from India to Europe over a period of 6 weeks, my 30mbit rtp stream was fine 99.998% with fec. The rest of the time that's why I dual stream, either timeshift (send the same packet again 100ms later - as I said most outages are time based), or dual path (although if the packets traverse the same router en route there are issues), or even both.

mordero 9y ago

I don't think that is quite true. I believe with UDP there is no promise of packets being received in order. I think this article is saying that you still get the benefits of processing the packets in the order received, but you don't have to worry about the latency of waiting for the re-transmission of any packets.

vvanders 9y ago
It's so trivial to add ordering to UDP, it's really the right protocol to use here. Subverting TCP leads to all sorts of problems around congestion(which you can no longer filter on because which TCP streams are being non-compliant?) that it just should not be done.
- marcosdumay 9y ago
  > It's so trivial to add ordering to UDP Specially when compared with creating and using a user space IP protocol like was done here, or adding a new one into the kernel.
- JoeAltmaier 9y ago
  TCP layer also gives you pacing, congestion control and flow control. Which UDP, you'd have to do yourself?
  - JoeAltmaier 9y ago
    And its not totally trivial to reorder UDP. Say you receive packets 1,2,3,5. How long to you wait for '4'? Maybe it was dropped; maybe its coming. Then you get 6,7. Is 4 still out there? You've got 3 packets in your pocket, waiting for 4. That adds up too. TCP gives you some idea of what packets you SHOULD have received, so you can respond better. UDP doesn't have any windowing etc so you have no idea.
    - vvanders 9y ago
      I guess I don't really see the big issue with that. It's not like windowing and congestion control is some kind of black magic. It's spelled out pretty cleanly in the TCP RFC and pretty straight-forward to reimplement. Generally if you're hitting cases where TCP is causing you grief and you need to reach for UDP you've already got enough context to understand your congestion problems/etc. We've been doing this in game-dev for decades, ditto the voip space so it's not like you don't have a wealth of knowledge to draw from if you're really stumped.

andreasvc 9y ago

No. UDP is connectionless, which makes it harder to use with NAT.

xxpor 9y ago
Not sure why you say that, UDP conntracking has been around for a long time.
- trav4225 9y ago
  I suspect that what andreasvc meant is that the default "NAT" configuration of most consumer-grade gear is such that it will block UDP (unless some other mechanism such as UPnP is used)...
  - noselasd 9y ago
    But it doesn't. Consumer gear NATs UDP pretty much as nice as it does TCP.
    - trav4225 9y ago
      Hmm, perhaps you are right... I switched from consumer gear to more "enterprise-y" gear a few years back, so my data points may be a bit outdated.
      - testvox 9y ago
        I've been using normal consumer routers for NATed home connects since 2004 or so and I've never had an issue with outgoing UDP. It's required for basically every video game after all.
  - lmns 9y ago
    That's true for TCP as well. Almost all consumer-grade routers block all incoming connection attempts, not just UDP. From a stateful firewall's point of view both UDP and TCP have state.