On Tue Sep 03, 2019 at 10:03:25AM +0100, James Bensley wrote: > Another problem with multicast is that it saves bandwidth across the > parts of the network where bandwidth is cheaper
That was a problem we had dating back to adsl, traffic was tunneled to a few central aggregation points across very expensive bandwidth. Due the replication happening at the aggregation points the multicast was not able save that expensive bandwidth. That architecture also prevented deploying CDNs deeper so the backhaul telco was not deprived of any income. > At the end of the day, bandwidth (for most ISPs) is most limited > and hardest to increase in the last mile There's plenty of bandwidth there (though line rate is your limit it's the same cost and limit for uni and multicast), it's only when it's aggregated upstream it becomes limited (less than the sum of all the lines paid for) and a variable cost where multicast/CDNs can help. > and even if it's multicast from the source to the > DSLAM/MSAN/OLT/access switch, it still needs to be replicated down > every access circuit that's subscribed to the multicast group, the > same as if it was unicast to each customer, so it's not saving any > bandwidth in those hard to upgrade and expensive to upgrade parts of > the network. The expensive bit that multicast would save is dslam to peering, not home tails, so if it was feasible this would be the ideal use case If you're paying BT 40quid/Mbit/s for backhaul and want to deliver a 30Mb/s UHD stream to 1000 subscribers on that dslam who pay 20quid would you like to multicast it if you could (30*40quid) or is unicast (30*40*1000quid) fine? This is a bit of non internet connectivity between you and your customer so it's entirely feasible to be engineered for multicast. > It's also possible increases the cost of a "dumb" access layer device > and CPE if they need to support multicast and increases the number of > test case for release cycles. At the CPE it's the same number of packets so the cost difference is supporting the additional protocol to enable the flow. That is another software feature not more hardware. CPE regularly add non essential features so I'd say that would not be a problem if the market desired it. > I'm obviously not a fan :) It's technology not Taylor Swift, use what is of technical and economic benefit. brandon
