5 ms·

The problem here is that it fails to take into account why any packets might be missing. If it's due to congestion, you've just subverted the mechanism TCP use

by yarg 9y ago

The problem here is that it fails to take into account why any packets might be missing. If it's due to congestion, you've just subverted the mechanism TCP uses to relieve it - and the more people that are using the deviant implementation, the bigger the problem becomes, which impacts everyone.

jrockway 9y ago
I'm not convinced it matters in this case, lying only prevents the other end from being extra-smart. We'll stick with the VoIP example. Packets are going to be dropped independently of any information in the TCP headers. If there's too much load, some of them will disappear. If your client says "yeah I got that data" when it didn't actually get the data, it doesn't increase load any more -- if you're sending a real-time 256kbps audio stream, then you need to be able to send 256,000 bits every second regardless of whether or not the network is capable of that. By not retransmitting packets you don't care about, you're decreasing load. Of course, if you push the information all the way up the stack to the application, you can do interesting things. You can notice that packets are being dropped and switch to a codec that sounds worse but sends fewer bits per second, and maybe you'll get a better quality call going on with fewer dropouts. Now that I think about it, I'm surprised this isn't how we deal with degrading things over slow connections in general. I would much prefer to only get the "mobile friendly" version of a page if I'm actually on a mobile connection. Right now, the hueristic seems to be "if screen < desktop; send mobile page". That of course is silly because my home WiFi can happily pipe huge images into my phone faster than the web server can send them to me, while my 8 core laptop with a 4k screen tethered to my phone can't magically make 4G faster. Interesting interesting.
- jsnell 9y ago
  It's how people deal with video (adaptive bitrate streaming). It also used to be how people dealt with images in the dark days of content rewriting middleboxes. So it's not that nobody's thought about the idea: it's that it's way harder to do once it's a question of really changing behavior rather than just being more aggressive with a quality/size trade-off knob. Also, mobile friendly versions of sites are at least as much about the user interface and rendering speed as about reducing bandwidth usage.
- cryptonector 9y ago
  It matters. Suppose there is congestion, and that if the sender(s) don't slow down, it will just get worse. Well, they don't find out about the congestion if the receivers lie (and congestion is asymmetric, so that the ACKs get through just fine). That's not good. Now, one way to deal with this is to lie but only for a bit. After a while of not receiving anything, the receiver should stop sending ACKs and the sender should notice the congestion. That might help. But the underlying problem is real: lying ACks -> failure to detect congestion -> worse congestion.
  - CapacitorSet 9y ago
    Maybe the client should lie probabilistically, so that there is still a relationship between what the sender sees and the actual congestion.
    - cryptonector 9y ago
      If you really want this just use SACK and let the sender never retransmit, no?
jcoffland 9y ago
I don't think it is obvious that this would aggravate congestion. It is true that TCP's speed control mechanism automatically slows the transmission rate when it detects lost packets and the article's proposal would mask lost packets. But, as long as the receiver keeps telling the sender, and nodes along the way, to stop sending some packets, bandwidth would scale down as it should. TCP's default policy of increasing latency in order to match available bandwidth is not appropriate for video streams. What this proposal does instead is tell the sender not to slow transmission in terms of frames processed but to instead don't send all the frames which is just what you want for video. But yeah, just use UDP. I would like to see a proof of concept before I full buy in to the author's claims. It's difficult to tell what this might do to proxies or how all the various router firmwares on the Net might handle it. I could see a hop along the way having trouble with the receiver claiming it received packets it could not have. For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error.
- toast0 9y ago
  > For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error. I happen to have some experience with this case (receiving an ack of an unsent packet). Linux since 2009 will silently drop acks of unsent data [1]. FreeBSD follows the RFC and will send ack with current sequence and ack numbers to try to 'resync'. As long as this modified stack doesn't respond to that ack with another ack, it would probably be ok. There's a reviewed and accepted patch for FreeBSD to rate limit the acks it sends in this case, but it doesn't seem to have been committed [2] [1] https://github.com/torvalds/linux/commit/96e0bf4b5193d0d97d139f99e2dd128763d55521 https://github.com/torvalds/linux/commit/96e0bf4b5193d0d97d1... (although the comment says this is consistent with the RFC, it actually isn't) [2] https://reviews.freebsd.org/D11929 https://reviews.freebsd.org/D11929
- kazinator 9y ago
  > For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error. The article deals with this head on: that's the essence of the ambiguity of "I have received up to X" versus "I am not interested in bytes up to X". The second intent is consistent with not having received bytes up to X, which is consistent with them not having been sent yet at all. The anti-congestion-control situation is when the receiver is in fact interested in getting all the bytes, and so "I am not interested in bytes up to X" is of course a lie. But so is "I have received up to X".
jchw 9y ago
Not everyone is looking at packet loss to deal with flow control. Wouldn't TCP BBR be an example of the contrary, and at that, a good example, considering it appears to do better than loss-based algorithms? Loss-based algorithms seem very prone to buffer bloat.
- tptacek 9y ago
  In theory, you don't have a choice about this; everyone needs TCP-friendly flow control, whether they want it or not, or the network experiences either congestion collapse or persistent unfairness.
  - jchw 9y ago
    You mean to say everyone has to use the same congestion algorithm in order for TCP flow control to work and not collapse the Internet? Apparently not Google, since they deployed TCP BBR and use it even for connections from the Internet, including on YouTube, and things seem to be beneficial rather than detrimental. It's not the only TCP implementation that is using stats other than packet drops to drive flow control. I'm guessing it works because both sides of the TCP connection can employ their own flow control for outgoing packets and the asymmetry doesn't do anything since they only care about controlling their own side.
    - unmole 9y ago
      BBR isn't always fair to other non-BBR flows.
kazinator 9y ago
> If it's due to congestion, you've just subverted the mechanism TCP uses to relieve it Bingo; that precisely the context in which I first saw the technique of 'fake ACKS' described: as a congestion-control-defeating mechanism which provokes senders into sending faster.

by yarg 9y ago

jrockway 9y ago

I'm not convinced it matters in this case, lying only prevents the other end from being extra-smart. We'll stick with the VoIP example. Packets are going to be dropped independently of any information in the TCP headers. If there's too much load, some of them will disappear. If your client says "yeah I got that data" when it didn't actually get the data, it doesn't increase load any more -- if you're sending a real-time 256kbps audio stream, then you need to be able to send 256,000 bits every second regardless of whether or not the network is capable of that. By not retransmitting packets you don't care about, you're decreasing load. Of course, if you push the information all the way up the stack to the application, you can do interesting things. You can notice that packets are being dropped and switch to a codec that sounds worse but sends fewer bits per second, and maybe you'll get a better quality call going on with fewer dropouts. Now that I think about it, I'm surprised this isn't how we deal with degrading things over slow connections in general. I would much prefer to only get the "mobile friendly" version of a page if I'm actually on a mobile connection. Right now, the hueristic seems to be "if screen < desktop; send mobile page". That of course is silly because my home WiFi can happily pipe huge images into my phone faster than the web server can send them to me, while my 8 core laptop with a 4k screen tethered to my phone can't magically make 4G faster. Interesting interesting.

jsnell 9y ago
It's how people deal with video (adaptive bitrate streaming). It also used to be how people dealt with images in the dark days of content rewriting middleboxes. So it's not that nobody's thought about the idea: it's that it's way harder to do once it's a question of really changing behavior rather than just being more aggressive with a quality/size trade-off knob. Also, mobile friendly versions of sites are at least as much about the user interface and rendering speed as about reducing bandwidth usage.
cryptonector 9y ago
It matters. Suppose there is congestion, and that if the sender(s) don't slow down, it will just get worse. Well, they don't find out about the congestion if the receivers lie (and congestion is asymmetric, so that the ACKs get through just fine). That's not good. Now, one way to deal with this is to lie but only for a bit. After a while of not receiving anything, the receiver should stop sending ACKs and the sender should notice the congestion. That might help. But the underlying problem is real: lying ACks -> failure to detect congestion -> worse congestion.
- CapacitorSet 9y ago
  Maybe the client should lie probabilistically, so that there is still a relationship between what the sender sees and the actual congestion.
  - cryptonector 9y ago
    If you really want this just use SACK and let the sender never retransmit, no?

jcoffland 9y ago

I don't think it is obvious that this would aggravate congestion. It is true that TCP's speed control mechanism automatically slows the transmission rate when it detects lost packets and the article's proposal would mask lost packets. But, as long as the receiver keeps telling the sender, and nodes along the way, to stop sending some packets, bandwidth would scale down as it should. TCP's default policy of increasing latency in order to match available bandwidth is not appropriate for video streams. What this proposal does instead is tell the sender not to slow transmission in terms of frames processed but to instead don't send all the frames which is just what you want for video. But yeah, just use UDP. I would like to see a proof of concept before I full buy in to the author's claims. It's difficult to tell what this might do to proxies or how all the various router firmwares on the Net might handle it. I could see a hop along the way having trouble with the receiver claiming it received packets it could not have. For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error.

toast0 9y ago
> For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error. I happen to have some experience with this case (receiving an ack of an unsent packet). Linux since 2009 will silently drop acks of unsent data [1]. FreeBSD follows the RFC and will send ack with current sequence and ack numbers to try to 'resync'. As long as this modified stack doesn't respond to that ack with another ack, it would probably be ok. There's a reviewed and accepted patch for FreeBSD to rate limit the acks it sends in this case, but it doesn't seem to have been committed [2] [1] https://github.com/torvalds/linux/commit/96e0bf4b5193d0d97d139f99e2dd128763d55521 https://github.com/torvalds/linux/commit/96e0bf4b5193d0d97d1... (although the comment says this is consistent with the RFC, it actually isn't) [2] https://reviews.freebsd.org/D11929 https://reviews.freebsd.org/D11929
kazinator 9y ago
> For that matter, it's possible for the receiver to claim to have received a packet that the sender had not yet generated. The sending TCP stack may very well consider this an error. The article deals with this head on: that's the essence of the ambiguity of "I have received up to X" versus "I am not interested in bytes up to X". The second intent is consistent with not having received bytes up to X, which is consistent with them not having been sent yet at all. The anti-congestion-control situation is when the receiver is in fact interested in getting all the bytes, and so "I am not interested in bytes up to X" is of course a lie. But so is "I have received up to X".

jchw 9y ago

Not everyone is looking at packet loss to deal with flow control. Wouldn't TCP BBR be an example of the contrary, and at that, a good example, considering it appears to do better than loss-based algorithms? Loss-based algorithms seem very prone to buffer bloat.

tptacek 9y ago
In theory, you don't have a choice about this; everyone needs TCP-friendly flow control, whether they want it or not, or the network experiences either congestion collapse or persistent unfairness.
- jchw 9y ago
  You mean to say everyone has to use the same congestion algorithm in order for TCP flow control to work and not collapse the Internet? Apparently not Google, since they deployed TCP BBR and use it even for connections from the Internet, including on YouTube, and things seem to be beneficial rather than detrimental. It's not the only TCP implementation that is using stats other than packet drops to drive flow control. I'm guessing it works because both sides of the TCP connection can employ their own flow control for outgoing packets and the asymmetry doesn't do anything since they only care about controlling their own side.
  - unmole 9y ago
    BBR isn't always fair to other non-BBR flows.

kazinator 9y ago

> If it's due to congestion, you've just subverted the mechanism TCP uses to relieve it Bingo; that precisely the context in which I first saw the technique of 'fake ACKS' described: as a congestion-control-defeating mechanism which provokes senders into sending faster.