uplink bandwidth requirements to stream HD down?

Question

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?

Answer 1

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.

Answer 2

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:

• Some form of authentication to establish that you are a registered, paying customer, and to specifically identify you (the subscriber) as opposed to others. The service isn't anonymous, because you probably have a "package" of subscribed channels, and you can only get those channels you are paying for.
• Some form of tracking which channels you watch and when. This may be an infrequent signal, such as "when the user switches the channel, tell the provider what channel we're now watching". Whether the provider chooses to use this data for marketing purposes is up to them, but it has to be provided to them regardless, so they know which channel's video stream to send to you!
• Some form of activity tracking that notifies the provider when you press buttons on your remote. This is becoming more common as a way of improving the user interface: they will harvest data on the most difficult tasks to accomplish, and try to make them easier in future updates. They may eliminate options that are seldom used.
• Signal quality data: your STB might tell the provider if there are frequent interruptions in the signal, which could automatically alert technicians to investigate to determine if something is wrong on their end. Or, they may be able to offer a lower-quality stream that will be more reliable (graceful downgrade from 1080p to 720p, for example).
• Diagnostic data: your STB might occasionally upload data about its uptime, available resources such as storage space and RAM, and logs from any software crashes.

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:

• Having enough bandwidth available for things like debug logs (which can be several megabytes in size) to upload fast enough that whatever process is sending them doesn't time out. Maybe it only allows 60 or 90 seconds for the process to complete before giving up.
• A degraded signal in your line might mean that a provisioned 1 Mbit/s would actually deliver around half that, or less, and the ISP may not be motivated to improve that. Ideally your TV would still work even under such degraded conditions, so even if they only strictly need 512 Kbit/s, asking for 1 Mbit/s gives them a margin of error.
• Normal operation during TV streaming may consume significantly less bandwidth, but 1 Mbit/s could be a "worst case", like if you're playing with your remote a lot, switching channels frequently, viewing the TV guide, etc. -- they want to make sure that your connection can handle all that without the upstream being too congested and timing out.
• If the ADSL line is shared with anything else (especially computers, which tend to upload for a lot more reasons than TV STBs), you'll want plenty of capacity on the subscriber line for upstream. 1 Mbit/s is a very low speed relative to most things these days.

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.

Answer 3

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.