5 ms·

Another article on this site addresses TCP plus UDP mix. The tl;dr is that they should not be used at the same time because TCP retransmission will interfere wi

by exDM69 10y ago

Another article on this site addresses TCP plus UDP mix. The tl;dr is that they should not be used at the same time because TCP retransmission will interfere with UDP (and routers give TCP priority). As long as TCP happens outside of the "hot" loop, it's fine.

wtallis 10y ago
> (and routers give TCP priority). What routers? Is this something that stupid routers did in the '90s and people are still worried about, or are modern routers actually behaving this way? (And if so, why?) TCP retransmission interfering with UDP sounds like something that shouldn't be a problem on any sane network, especially if the application authors are smart and use something like LEDBAT for their TCP traffic when they're also doing latency-sensitive UDP communication.
- vvanders 10y ago
  You'd be shocked at the things home routers do. There's a reason most people don't try to implement NAT traversal and use common middleware. Since UDP isn't as common of a protocol I can certainly see some routers treating it a second class traffic when it comes to packet shaping.
  - wtallis 10y ago
    I'm well aware of how dumb home routers can be, but a general de-prioritizing of the transport protocol that DNS uses is both really dumb and pretty easy to detect. Are you aware of any router vendors that have actually shipped such a configuration? (Or for that matter, any consumer router that has shipped with any prioritization rules enabled out of the box?)
    - macintux 10y ago
      DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.
      - wtallis 10y ago
        DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.
        macintux 10y ago
        Yes, but the HTTP requests themselves dominate the overall load time, even if DNS takes a bit longer. Plus there's caching to reduce somewhat the need for the DNS requests. (Of course, I'm pulling all of this out of my nether regions without a lot of thought, and you may well be right, the sheer volume of such requests might lead to problems.)
        wtallis 10y ago
        It looks like on Windows a typical DNS retry timout is 1 second, with backoff if multiple retries are needed. If a DNS packet needed for loading a web page gets dropped, it's very likely to increase the overall page loading time. Re-ordering DNS to be delivered only when there's a lull in the large TCP packets would almost serialize the loading of resources from different domains. DNS caching is a good thing, but it certainly doesn't eliminate this problem. Web browsing still produces a lot of DNS requests, and any cache upstream of the bottleneck (ie. any cache operated by your ISP rather than in your own router) doesn't help against loss during congestion.
      - kijiki 10y ago
        That would be a disaster. Without active queue management, a single bulk upload can break DNS. When the bottleneck link (usually your cable/DSL modem) is saturated by the bulk upload, it will start dropping new packets that come in while the queue is full. When a single packet worth of space frees up, the chances are that the bulk flow will instantly take it, such that nearly all outbound DNS packets get dropped, and DNS queries time out. The solution is active queue management (CODEL is a good choice) at every bottleneck.
    - kalleboo 10y ago
      Every home network I've seen ends up using the home router itself as a forwarding DNS server as configured through DHCP. That said, I doubt home routers are de-pritoritising UDP to any extent, or it would be a big topic of discussion among gamers.
- fulafel 10y ago
  The internet is generally built on the implicit contract of "TCP-friendly flow control". If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. There is no general policy against non-TCP packets of course, as lots of important internet services are non-TCP. Just flows that don't respond to congestion. It's not a vendor specific thing, all the major router vendors provide ways of doing this. (Note: router != your home NAT box)
  - wtallis 10y ago
    > If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. I think that's only if you're being less responsive to congestion signals (drops, ECN marks), and you're using more than a fair share of bandwidth or trying to use any available bandwidth. Fixed but low rate flows (eg. VoIP) shouldn't be penalized until the link is congested with so many flows that the VoIP is trying to use more than 1/N of the bandwidth.
placebo 10y ago
There are quite a few "reliable UDP" implementations out there - I wonder if the same considerations would hold. Guess it might depend on the implementation of reliability using UDP.
jlgaddis 10y ago
I'm a network engineer and I think this is the first time I've ever heard the claim that "routers give TCP priority" (ICMP is often de-prioritized but that's on the control plane). Exactly which routers are alleged to be doing this?

by exDM69 10y ago

wtallis 10y ago

> (and routers give TCP priority). What routers? Is this something that stupid routers did in the '90s and people are still worried about, or are modern routers actually behaving this way? (And if so, why?) TCP retransmission interfering with UDP sounds like something that shouldn't be a problem on any sane network, especially if the application authors are smart and use something like LEDBAT for their TCP traffic when they're also doing latency-sensitive UDP communication.

vvanders 10y ago
You'd be shocked at the things home routers do. There's a reason most people don't try to implement NAT traversal and use common middleware. Since UDP isn't as common of a protocol I can certainly see some routers treating it a second class traffic when it comes to packet shaping.
- wtallis 10y ago
  I'm well aware of how dumb home routers can be, but a general de-prioritizing of the transport protocol that DNS uses is both really dumb and pretty easy to detect. Are you aware of any router vendors that have actually shipped such a configuration? (Or for that matter, any consumer router that has shipped with any prioritization rules enabled out of the box?)
  - macintux 10y ago
    DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.
    - wtallis 10y ago
      DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.
      - macintux 10y ago
        Yes, but the HTTP requests themselves dominate the overall load time, even if DNS takes a bit longer. Plus there's caching to reduce somewhat the need for the DNS requests. (Of course, I'm pulling all of this out of my nether regions without a lot of thought, and you may well be right, the sheer volume of such requests might lead to problems.)
        wtallis 10y ago
        It looks like on Windows a typical DNS retry timout is 1 second, with backoff if multiple retries are needed. If a DNS packet needed for loading a web page gets dropped, it's very likely to increase the overall page loading time. Re-ordering DNS to be delivered only when there's a lull in the large TCP packets would almost serialize the loading of resources from different domains. DNS caching is a good thing, but it certainly doesn't eliminate this problem. Web browsing still produces a lot of DNS requests, and any cache upstream of the bottleneck (ie. any cache operated by your ISP rather than in your own router) doesn't help against loss during congestion.
    - kijiki 10y ago
      That would be a disaster. Without active queue management, a single bulk upload can break DNS. When the bottleneck link (usually your cable/DSL modem) is saturated by the bulk upload, it will start dropping new packets that come in while the queue is full. When a single packet worth of space frees up, the chances are that the bulk flow will instantly take it, such that nearly all outbound DNS packets get dropped, and DNS queries time out. The solution is active queue management (CODEL is a good choice) at every bottleneck.
  - kalleboo 10y ago
    Every home network I've seen ends up using the home router itself as a forwarding DNS server as configured through DHCP. That said, I doubt home routers are de-pritoritising UDP to any extent, or it would be a big topic of discussion among gamers.
fulafel 10y ago
The internet is generally built on the implicit contract of "TCP-friendly flow control". If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. There is no general policy against non-TCP packets of course, as lots of important internet services are non-TCP. Just flows that don't respond to congestion. It's not a vendor specific thing, all the major router vendors provide ways of doing this. (Note: router != your home NAT box)
- wtallis 10y ago
  > If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. I think that's only if you're being less responsive to congestion signals (drops, ECN marks), and you're using more than a fair share of bandwidth or trying to use any available bandwidth. Fixed but low rate flows (eg. VoIP) shouldn't be penalized until the link is congested with so many flows that the VoIP is trying to use more than 1/N of the bandwidth.

placebo 10y ago

There are quite a few "reliable UDP" implementations out there - I wonder if the same considerations would hold. Guess it might depend on the implementation of reliability using UDP.

jlgaddis 10y ago

I'm a network engineer and I think this is the first time I've ever heard the claim that "routers give TCP priority" (ICMP is often de-prioritized but that's on the control plane). Exactly which routers are alleged to be doing this?