3 ms·

ACK frequencies should be configurable, solving both bottlenecks and making UDP less relevant at the same time: https://www.ietf.org/id/draft-add-ackfreq-to-tc

by bullen 8y ago

ACK frequencies should be configurable, solving both bottlenecks and making UDP less relevant at the same time: https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt

vvanders 8y ago
UDP will always be relevant when you have head of line blocking and temporal data that expires quickly.
- bullen 8y ago
  Well, if you set the ack freq. to 0 then TCP becomes UDP. Right now it's hard coded to 2 which is just weird.
  - vvanders 8y ago
    This has nothing to do with sending. On the receiving side you can't receive newer packets when a missed packet exists with an earlier sequence ID. Ex: 4 -> 5 -> X -> 7 -> 8 -> 9 Until the client gets 6 then 7,8,9 will be held(and getting stale) until you roundtrip 6. At that point 9 may even be useless since it would be too stale and you've just added extra latency that you don't want or need. Look up how dead-reckoning is done in realtime games, this is one of many other cases where having timely data works better over UDP than TCP.
    - bullen 8y ago
      If you would be able to set ack. freq. to 0 = no ack. needed; you would not want ordering, just like UDP but over TCP. Why would you want that you might ask, because then you can choose if you want order over the same protocol precisely for games. For context I built this multiplayer platform, not that that prooves anything but I have 20 years of working with multiplayer: http://fuse.rupy.se/about.html http://fuse.rupy.se/about.html
      - vvanders 8y ago
        The reason you can't do that is because you would no longer have a stream based protocol which is one of the core requirements of TCP. Really there's no up-side to doing it that way with UDP already existing and tons of downsides in changing an existing protocol in such a fundamental way.
stiglitz 8y ago
That configuration is already possible in Windows with the “DelayedAckFrequency” parameter and in Linux with the “quickACK” setting, but it’s unrelated to congestion control, and it will neither “solve” bottlenecks nor “turn TCP into UDP.” Congestion control (the purpose of BBR) deals with the bottleneck problem. Delayed ACKs are an optimization to reduce protocol overhead. Indeed there are problems with delayed ACKs when combined with Nagle’s algorithm and an application that doesn’t send a steady stream of data, but it has nothing to do with the topic of this thread.
- bullen 8y ago
  I need to set ack frequency to never or inifiny (say 1000+) packets per ack. so these are not usable for me. TCP_QUICKACK seems to be a boolean (basically 1 or 2 packets per ack) DelayedAckFrequency goes from 10 to 600 but it's millisecs!? You don't think acks. have an impact on congestion?

by bullen 8y ago

vvanders 8y ago

UDP will always be relevant when you have head of line blocking and temporal data that expires quickly.

bullen 8y ago
Well, if you set the ack freq. to 0 then TCP becomes UDP. Right now it's hard coded to 2 which is just weird.
- vvanders 8y ago
  This has nothing to do with sending. On the receiving side you can't receive newer packets when a missed packet exists with an earlier sequence ID. Ex: 4 -> 5 -> X -> 7 -> 8 -> 9 Until the client gets 6 then 7,8,9 will be held(and getting stale) until you roundtrip 6. At that point 9 may even be useless since it would be too stale and you've just added extra latency that you don't want or need. Look up how dead-reckoning is done in realtime games, this is one of many other cases where having timely data works better over UDP than TCP.
  - bullen 8y ago
    If you would be able to set ack. freq. to 0 = no ack. needed; you would not want ordering, just like UDP but over TCP. Why would you want that you might ask, because then you can choose if you want order over the same protocol precisely for games. For context I built this multiplayer platform, not that that prooves anything but I have 20 years of working with multiplayer: http://fuse.rupy.se/about.html http://fuse.rupy.se/about.html
    - vvanders 8y ago
      The reason you can't do that is because you would no longer have a stream based protocol which is one of the core requirements of TCP. Really there's no up-side to doing it that way with UDP already existing and tons of downsides in changing an existing protocol in such a fundamental way.

stiglitz 8y ago

That configuration is already possible in Windows with the “DelayedAckFrequency” parameter and in Linux with the “quickACK” setting, but it’s unrelated to congestion control, and it will neither “solve” bottlenecks nor “turn TCP into UDP.” Congestion control (the purpose of BBR) deals with the bottleneck problem. Delayed ACKs are an optimization to reduce protocol overhead. Indeed there are problems with delayed ACKs when combined with Nagle’s algorithm and an application that doesn’t send a steady stream of data, but it has nothing to do with the topic of this thread.

bullen 8y ago
I need to set ack frequency to never or inifiny (say 1000+) packets per ack. so these are not usable for me. TCP_QUICKACK seems to be a boolean (basically 1 or 2 packets per ack) DelayedAckFrequency goes from 10 to 600 but it's millisecs!? You don't think acks. have an impact on congestion?