Doesn’t matter how the broadcaster is transmitting, we take in which ever form that is done and convert it to match our delivery.
Question on the pausing comment, I can see that being the case on nDVR setups where the local STB isn’t doing any of the storage. On a setup where there’s no nDVR the box would still be using the same multicast wouldn’t it? I think I saw a multicast vs unicast comparison on a wisp Facebook group talking about what you mention below, was there really an added benefit. Was interesting to see the numbers he had come up with in his use case. From: kscott.he...@gmail.com [mailto:kscott.he...@gmail.com] On Behalf Of K. Scott Helms Sent: Tuesday, November 21, 2017 8:59 AM To: Luke Guillory Cc: Baldur Norddahl; nanog@nanog.org Subject: Re: Broadcast television in an IP world Luke, I think I understand your example but the local broadcaster won't usually (ever?) have the rights to retransmit the Super Bowl over IP. Having said that, what you're describing is exactly what happens already (without multicast) via multiple CDNs. Multicast across the internet isn't feasible (economically) today. Multicast inside of an organization certainly is and is very common. Having said that, even popular content is surprisingly sparse (when we look at flows) and even inside of edge networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to make the math work. As soon as someone wants to pause the "big game" or flips to another channel you now have to move their flow to unicast. Even when lots of people are watching the same event the economics aren't as compelling as they might appear initially. On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory <lguill...@reservetele.com<mailto:lguill...@reservetele.com>> wrote: The comment I was originally replying to was the following. I’ve said edge resources, nothing about WAN. The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. Sent from my iPhone On Nov 21, 2017, at 8:22 AM, K. Scott Helms <kscotthe...@gmail.com<mailto:kscotthe...@gmail.com>> wrote: It's not helpful for saving resources in DOCSIS (nor any other) edge networks. The economics mean that, as bits get sold in the US and many other places, it won't be in the foreseeable future. Customers care about popular video sources. Popular content sources have CDNs with local nodes and/or direct (low cost) connections to their CDN. That's far more efficient than allowing multicast across WAN links. K. Scott Helms Luke Guillory Vice President – Technology and Innovation [cid:image001.jpg@01D362A8.269800C0]<http://www.rtconline.com> Tel: 985.536.1212<tel:(985)%20536-1212> Fax: 985.536.0300<tel:(985)%20536-0300> Email: lguill...@reservetele.com<mailto:lguill...@reservetele.com> Web: www.rtconline.com<http://www.rtconline.com> Reserve Telecommunications 100 RTC Dr<https://maps.google.com/?q=100+RTC+Dr+%0D+Reserve,+LA+70084&entry=gmail&source=g> Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory <lguill...@reservetele.com<mailto:lguill...@reservetele.com>> wrote: I’m not paying anything for local resources with regards to local edge delivery, that’s capital expenditures not MRCs. Our edge networks aren’t unlimited or free, so while it’s not costing me on the transit side there still are cost in terms of upgrades and so on. My point is that In some networks such as docsis conserving edge resources can be helped with multicast. Sent from my iPhone On Nov 21, 2017, at 4:12 AM, Baldur Norddahl <baldur.nordd...@gmail.com<mailto:baldur.nordd...@gmail.com><mailto:baldur.nordd...@gmail.com<mailto:baldur.nordd...@gmail.com>>> wrote: Den 21. nov. 2017 00.42 skrev "Luke Guillory" <lguill...@reservetele.com<mailto:lguill...@reservetele.com><mailto:lguill...@reservetele.com<mailto:lguill...@reservetele.com>>>: Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. Luke Guillory Vice President – Technology and Innovation [cid:imagef9b835.JPG@242ea556.429501f5] <http://www.rtconline.com> Tel: 985.536.1212<tel:985.536.1212> Fax: 985.536.0300<tel:985.536.0300> Email: lguill...@reservetele.com<mailto:lguill...@reservetele.com> Web: www.rtconline.com<http://www.rtconline.com> Reserve Telecommunications 100 RTC Dr<https://maps.google.com/?q=100+RTC+Dr+%0D+Reserve,+LA+70084&entry=gmail&source=g> Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
