4 ms·

No need for any caching, just do proper multicast like "real" IPTV networks do. Other than that, I don't think that enough people would watch the same shows wit

by fuzzy2 5y ago

No need for any caching, just do proper multicast like "real" IPTV networks do. Other than that, I don't think that enough people would watch the same shows within a reasonable timeframe to justify the costs.

ncmncm 5y ago
Multicast would save exactly zero Hz of spectrum bandwidth, which a moment's thought would reveal to you. Allow me encourage a habit of that. Multicast routing uses, exclusively, point-to-point links. So, a packet could go up to the satellite once, but would need to be copied down to every terminal individually. But internet video is in any case not distributed by multicast UDP. Even if it were, you still would need caching for viewers not watching identically the same frames at the same time, because a multicast router does not do time-shifting: all copies of each packet are queued to send immediately.
- fuzzy2 5y ago
  Is that right. Do enlighten me then! Of course the transport link would have to cooperate and open a group-encrypted channel for every multicast group a client is subscribed to. Basically how regular satellite TV works, but with dynamically allocated bandwidth.
  - spmurrayzzz 5y ago
    You were right to point out multicast. Its a great way to do cache discovery if nothing else. Saying that its de facto not effective at saving spectrum bandwidth handwaves pretty much every last mile detail thats relevant in networks like these.
    - ncmncm 5y ago
      No, fuzz is 100% wrong. Multicast makes more-effective use of fiber, where each new fiber link branching off provides its own, private pool of bandwidth, added on to all the others. Once you get to radio spectrum transmission, each pair of endpoints competes with every other pair in range, in a strictly limited pool of bandwidth. Adding another terminal takes away capacity from all the others. A multicast stream going to your satellite and then distributed to 100 terminals by multicast burns 100x the fixed available bandwidth as each terminal gets. The only way to get any benefit from batching delivery over radio spectrum is via broadcast. For a packet network, you have the extra chore of making those broadcast packets actually useful to as many terminals as possible. In practice that requires caching of broadcast content in the terminal, so that when it is actually asked for it is already there.
      - spmurrayzzz 5y ago
        >Once you get to radio spectrum transmission, each pair of endpoints competes with every other pair in range, in a strictly limited pool of bandwidth. Adding another terminal takes away capacity from all the others. A multicast stream going to your satellite and then distributed to 100 terminals by multicast burns 100x the fixed available bandwidth as each terminal gets. Multicast is indeed problematic for wireless networks, even beyond what you describe (e.g. FEC, ACK storming, retransmits, etc). But if the phy layer is using OFDMA or similar, its entirely plausible to dedicate a subcarrier for multicast traffic. This doesn't solve the O(N) terminal problem you describe, but it mitigates the impact for concurrent transmission of unrelated unicast traffic while the multicast delivery is happening. There's a fairly large academic body of work on this specific topic re: OFDMA multicast. And though I think your note on caching is a necessary component of this (a la Open Connect), I still think there is a role that multicast can play here.
        ncmncm 5y ago
        FEC is not a problem, but the solution to a problem. FEC is "forward error correction", sending a few percent of redundant data, enough so the receiver can fix up corrupted packets on their own. (FEC was once a patent problem, but those have mostly expired.) ACK storms aren't a thing with multicast; if FEC doesn't get you what you need, you wait a random time and send a NAK up the line, and the sender re-sends the requested bit. If the bit you were about to request shows up again before you get to asking, you discard the NAK you would have sent. So, if a lot of receivers miss the same packet, only one NAK usually goes back. The Starlink transceivers are SDRs and extremely versatile. So, instead of playing games with modulation and subcarriers, it probably uses its whole band on each packet, effectively broadcasting all packets, and receivers just pick off whichever packets are meaningful to them. The ones actually intended for more than one terminal are the "broadcast" packets, differing only in how they are processed by the terminal. The actually tricky thing is that broadcast streams cannot be like the regular end-to-end packet streams, where identical images are delivered in absolutely unlike packets. You need a higher-level negotiation identifying streams of interest by name and playback position, so that the uplink terminal knows when it is sending (or will have sent) the same stuff twice. If it decides some of its traffic should be broadcast instead, it can substitute packets from an equivalent, shared stream. The receiving terminal, meanwhile, is told that the stream it was getting is ended, and it should start extracting and caching content from the substituted broadcast stream. The usual DRM nonsense will make this annoyingly more complicated: the participating broadcast receivers get a copy of a key to decrypt the broadcast traffic. Everybody else throws it away as indistinguishable from noise, like all traffic not meant for them.

by fuzzy2 5y ago

ncmncm 5y ago

Multicast would save exactly zero Hz of spectrum bandwidth, which a moment's thought would reveal to you. Allow me encourage a habit of that. Multicast routing uses, exclusively, point-to-point links. So, a packet could go up to the satellite once, but would need to be copied down to every terminal individually. But internet video is in any case not distributed by multicast UDP. Even if it were, you still would need caching for viewers not watching identically the same frames at the same time, because a multicast router does not do time-shifting: all copies of each packet are queued to send immediately.

fuzzy2 5y ago
Is that right. Do enlighten me then! Of course the transport link would have to cooperate and open a group-encrypted channel for every multicast group a client is subscribed to. Basically how regular satellite TV works, but with dynamically allocated bandwidth.
- spmurrayzzz 5y ago
  You were right to point out multicast. Its a great way to do cache discovery if nothing else. Saying that its de facto not effective at saving spectrum bandwidth handwaves pretty much every last mile detail thats relevant in networks like these.
  - ncmncm 5y ago
    No, fuzz is 100% wrong. Multicast makes more-effective use of fiber, where each new fiber link branching off provides its own, private pool of bandwidth, added on to all the others. Once you get to radio spectrum transmission, each pair of endpoints competes with every other pair in range, in a strictly limited pool of bandwidth. Adding another terminal takes away capacity from all the others. A multicast stream going to your satellite and then distributed to 100 terminals by multicast burns 100x the fixed available bandwidth as each terminal gets. The only way to get any benefit from batching delivery over radio spectrum is via broadcast. For a packet network, you have the extra chore of making those broadcast packets actually useful to as many terminals as possible. In practice that requires caching of broadcast content in the terminal, so that when it is actually asked for it is already there.
    - spmurrayzzz 5y ago
      >Once you get to radio spectrum transmission, each pair of endpoints competes with every other pair in range, in a strictly limited pool of bandwidth. Adding another terminal takes away capacity from all the others. A multicast stream going to your satellite and then distributed to 100 terminals by multicast burns 100x the fixed available bandwidth as each terminal gets. Multicast is indeed problematic for wireless networks, even beyond what you describe (e.g. FEC, ACK storming, retransmits, etc). But if the phy layer is using OFDMA or similar, its entirely plausible to dedicate a subcarrier for multicast traffic. This doesn't solve the O(N) terminal problem you describe, but it mitigates the impact for concurrent transmission of unrelated unicast traffic while the multicast delivery is happening. There's a fairly large academic body of work on this specific topic re: OFDMA multicast. And though I think your note on caching is a necessary component of this (a la Open Connect), I still think there is a role that multicast can play here.
      - ncmncm 5y ago
        FEC is not a problem, but the solution to a problem. FEC is "forward error correction", sending a few percent of redundant data, enough so the receiver can fix up corrupted packets on their own. (FEC was once a patent problem, but those have mostly expired.) ACK storms aren't a thing with multicast; if FEC doesn't get you what you need, you wait a random time and send a NAK up the line, and the sender re-sends the requested bit. If the bit you were about to request shows up again before you get to asking, you discard the NAK you would have sent. So, if a lot of receivers miss the same packet, only one NAK usually goes back. The Starlink transceivers are SDRs and extremely versatile. So, instead of playing games with modulation and subcarriers, it probably uses its whole band on each packet, effectively broadcasting all packets, and receivers just pick off whichever packets are meaningful to them. The ones actually intended for more than one terminal are the "broadcast" packets, differing only in how they are processed by the terminal. The actually tricky thing is that broadcast streams cannot be like the regular end-to-end packet streams, where identical images are delivered in absolutely unlike packets. You need a higher-level negotiation identifying streams of interest by name and playback position, so that the uplink terminal knows when it is sending (or will have sent) the same stuff twice. If it decides some of its traffic should be broadcast instead, it can substitute packets from an equivalent, shared stream. The receiving terminal, meanwhile, is told that the stream it was getting is ended, and it should start extracting and caching content from the substituted broadcast stream. The usual DRM nonsense will make this annoyingly more complicated: the participating broadcast receivers get a copy of a key to decrypt the broadcast traffic. Everybody else throws it away as indistinguishable from noise, like all traffic not meant for them.