Lying to TCP makes it a best-effort streaming protocol

It would be very good for the net if something came up that penalised middleboxes though. Maybe this could be it.

Yes indeed. If I could crash middle-boxes by sending them malformed TCP streams, I would do it all day long.

What are middleboxes? This is something that I've never heard of before.

Yes, we were surprised by just how prevalent middleboxes were that didn't like gaps in sequence spaces. This significantly influenced the design options for MPTCP.

Another problem is that TCP is a bytestream protocol. Apps that stream over TCP don't usually add packet-orientated framing and resync points, so if you lose a packet, the receiver will often need to discard quite a bit of data after the missing packet before they can start decoding again. Effectively this multiplies the effective loss rate. In the extreme, there's the potential for congestion collapse, where lots of packets are being delivered but none of the are useful, so they're all discarded at the receiver.

Edit: I should add - middleboxes often resegment the datastream, merging multiple packets, or splitting large ones. So even if the sender added a header in each segment sent, those headers may not be at the beginning of the segment when it arrives. After a loss, you may not be able to reliable find the next header again.

By the way, that web server at UCL may well be the oldest on the Internet. It's probably the only server left proudly running CERN/3.0 on Sparc hardware since 1994.

Yes, the receive side would need to have a plan to interpret the data.

One way to do this is to use a format where you can resync. For example, have special values that only occur in certain positions. You look for one of those values and can then enter a known state.

Another possibility is to be selective about what you will allow to be discarded. Suppose you have a framing structure so that you send a byte count followed by a blob of data (like video or audio data). Then you can use these anticipatory acks to express that you can live without that blob. For example, if your protocol says "and now here's 123456 bytes of video data", you can ack with a sequence number that reflects having received those 123456 bytes but no more. Obviously, this limits your ability to skip ahead and may not be as useful.

> This becomes really difficult to process, because TCP simulates a stream ...

The irony of TCP is that in almost every use case you end up creating "frames" within the stream. Turtles all the way up I guess.

> So you also need to create heuristics, on how do you discard received data, until you get to a point where you can understand the stream again, and continue processing.

This can be trivially easy for some data formats, where you know the absolute or relative offset of everything. E.g. here is a chunk of data I don't care about: 32 bit length followed by that many bytes. Read the length, then hit the llseek system call (that would be supported on sockets just for this feature) to skip the stream position that many bytes ahead. Done.

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.

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.

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.

> 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.

From that point of view, UDP streaming is also short-sighted. Practically, this is nothing more than a type of "QoS" flag, where of course things would also break down if everything started giving themselves priority 1.

So it depends more upon whether the use case is appropriate than it does about technical implementation.

That's not what's being talked about here. The idea is that you ACK packets that you believe have been sent, but have been dropped or delayed, because you've received a later packet.

That seems easy enough to work around. Send two acks, one for what you really received and one for what you are pretending you've received.

If the data has been sent but lost, the sender will accept the aggressive ack. If it hasn't been sent yet, it will accept the less aggressive ack.

For that matter, if you have some way of knowing the expected transmission rate (even approximately as long as you can resync to reality), you can blindly send a stream of periodic acks with steadily increasing sequence numbers.

not exactly:

> If it’s used that way, it makes TCP a reliable, in-order protocol.

the key here is "in-order".

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.

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