I have a TV service that uses ADSL technology. It means that my TV is basically streaming everything over the internet.
I was told today that this would require at least 1MB/s uplink to be able to work. Is that correct?
Note, I'm not talking about the bandwidth down, which would by much higher. This is up, in other words, my TV provider's set-top box needs at least 1MB/s upload capacity in order stream down a 2-3MB/s stream (I'm guessing on that).
What is it sending? ACKs?
It depends on the streaming protocol, but it could be sending acks, retransmission requests, client quality reports, playback commands (play/pause/rewind), and requests to change the stream bitrate to better fit the network conditions.
None of these would get anywhere near a sustained 1Mbps data rate, so they are probably asking for more than they really need, in hopes that with the extra headroom, other traffic won’t be enough to trigger congestion and bufferbloat that can interfere with the smooth playback and operation of the streaming service.
Without knowing the exact model of your Set-Top Box and the protocol it's using to interface with your TV provider, it's impossible to know what, exactly, it's using that bandwidth for. However, we can make some educated guesses based on the services you receive.
First, any digital video protocol is going to have, as you surmised, some form of "ACK"s to indicate successful receipt of data. Digital video isn't a one-way protocol; to keep packets in order and keep the video stream in sync (to ensure that the video player isn't playing video too fast or too slow), both sides frequently send timing data to one another. Dropped packets are handled based on some algorithm to determine whether there's time to re-send the packet, or just cut the video and keep going. It might also be willing to attempt to decode and play incomplete data and accept any corruption that may occur as a result (this is why sometimes digital TV over the air has this problem).
Additional things any subscriber-based TV service also should provide would include:
1 Mbit/s might sound like a lot, but the nominal overhead of a regular HTTP request (which this service may or may not use) is around 2%. Their estimate of 1 Mbit/s is probably based on:
The overhead of the video protocol might actually be a lot higher than 2%. Encryption (in both directions) might add a few percent. Maybe the size of each data packet is very small, which would increase the overall overhead because you'd have more total packets, and each one has metadata associated with it. All of that involves a little bit of upstream, and eventually that adds up.
Overall, there's no way to know for sure why they think they need 1 Mbit/s upstream for your TV STB, but it's probably just a guess, or based on testing that indicated that certain operations require a little burst of upstream and it has to be a certain speed to get decent performance (for example, the initial handshake to authenticate your STB might require a burst every time the box has to renegotiate the encryption layer with the provider central office).
I doubt they are using a steady 1 Mbit/s while just normally streaming video, though. The quality and bitrate of the video would have to be extremely high for any reasonably-efficient video streaming protocol to demand that much upstream on an ongoing basis.
Ack packets on ethernet are minimally 64 bytes in size, 'loaded' downstream packets on typical PPPoA DSL deployments are usually 1492 bytes in size.
RFC1122 specifies "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment".
Therefore your minimum ack bandwidth ratio is 64/(1492*2) = 2.15%, or 22,490 bytes of acknowledgements required per 1MB received, or as a bitrate approximately 110kbps (0.1Mbps) up per 5Mbps down.
For some reason I'm thinking they want your upstream bandwidth.
If their 'streams' were delivered as uniquely identified blocks of data, it would be trivial to have the devices cache all downloaded blocks and act as distributed storage. For live streams it is difficult because there is only one origin point for data blocks, but by giving each stream-viewing client a random 'block offset' starting point (equivalent to a broadcast delay of 0-30s) client demands can be spread across a range of blocks and clients can be leveraged to redistribute blocks to other clients. Block availability can be intelligently managed by the control server with new blocks being pushed initially to the clients with the highest upload bandwidth and those clients being instructed in turn to push data to another tier of clients.
If the devices have moderate local storage (64GB) then VoD / PVR services for recently-shown content would be trivial to implement at almost zero bandwidth cost to the provider. Individual devices would be instructed to retain or delete stream blocks as necessary to maintain sufficient block availability across the distributed storage network according to forecast/measured demand. Playback is achieved simply by requesting the relevant blocks and performing some local caching, with a central server available to guarantee availability if required.