<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 11, 2021, at 13:05 , Matthew Petach <<a href="mailto:mpetach@netflight.com" class="">mpetach@netflight.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 11, 2021 at 1:01 AM Mark Tinka <<a href="mailto:mark@tinka.africa" class="">mark@tinka.africa</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, in an era where content is making a push to get as close to the <br class="">
eyeballs as possible, kit getting cheaper and faster because of merchant <br class="">
silicon, and abundance of aggregated capacity at exchange points, can we <br class="">
leverage the shorter, faster links to change the model?<br class="">
<br class="">
Mark.<br class=""></blockquote><div class=""><br class=""></div><div class="">I think it would be absolutely *stunning* for content providers </div><div class="">to turn the model on its head; use a bittorrent like model for </div><div class="">caching and serving content out of subscribers homes at </div><div class="">recalcitrant ISPs, so that data doesn't come from outside, </div><div class="">it comes out of the mesh within the eyeball network, with </div><div class="">no clear place for the ISP to stick a $$$ bill to.</div></div></div></div></blockquote><div><br class=""></div>I worked for a company that tried this model several years back.</div><div>It did not go well. Users were not happy. Eyeball ISPs were very</div><div>not happy (and started actively mitigating users who participated</div><div>through a variety of nefarious means), and content providers got</div><div>a bit hot under the collar about it (the experiment was a content</div><div>aggregator for lack of a better term).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Imagine you've got a movie; you slice it into 1,000 </div><div class="">encrypted chunks; you make part of your license </div><div class="">agreement for customers a requirement that they </div><div class="">will allow you to use up to 20GB of disk space on </div><div class="">their computer and to serve up data chunks into </div><div class="">the network in return for a slightly cheaper monthly </div><div class="">subscription cost to your service. You put 1 slice </div><div class="">of that movie on each of 1,000 customers in a </div><div class="">network; then you replicate that across the next </div><div class="">thousand customers, and again for the next </div><div class="">thousand, until you've got enough replicas of </div><div class="">each shard to handle a particular household </div><div class="">going offline. Your library is still safe from </div><div class="">piracy, no household has more than 1/1000th of a </div><div class="">movie locally, and they don't have the key to decrypt </div><div class="">it anyhow; but they've got 1/1000th of 4,0000 different </div><div class="">movies, and when someone in that ISP wants to watch the </div><div class="">movie, the chunks are being fetched from other households </div><div class="">within the eyeball network. The content provider would have </div><div class="">shard servers in region, able to serve up any missing shards that </div><div class="">can't be fetched locally within the ISP--but the idea would be that </div><div class="">as the number of subscribers within an ISP goes up, instead of the </div><div class="">ISP seeing a large, single-point-source increase in traffic, what they </div><div class="">see is an overall increase in east-west traffic among their users.</div></div></div></div></blockquote><div><br class=""></div>That’s a pretty close description of exactly what we did.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Because the "serving of shards to others" happens primarily while the </div><div class="">user is actively streaming content, you have a natural bell curve; during </div><div class="">peak streaming times, you have more nodes active to serve up shards, </div><div class="">handling the increased demand; at lower demand times, when fewer </div><div class="">people are active, and there's fewer home-nodes to serve shards, the </div><div class="">content network's shard servers can pick up the slack...but that'll generally </div><div class="">only happen during lower traffic times, when the traffic won't be competing </div><div class="">and potentially causing pain for the ISP.</div></div></div></div></blockquote><div><br class=""></div>It’s a beautiful theory. We expected this to be the case, too. Turns out, not</div><div>so much. There’s an awful lot of long tail out there that is poorly accounted</div><div>for in this. Yes, it does help with some of the most popular content, but there</div><div>are pitfalls there, too.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Really, it seems like a win-win scenario.</div></div></div></div></blockquote><div><br class=""></div>We thought so too, until we learned otherwise. Today, with more symmetrical</div><div>connections and larger uplinks, it might be more feasible. Back then (Around</div><div>2005), it was a good idea on paper.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">I'm confident we'll see a content network come out with a model like this </div><div class="">within the next 5 years, at which point the notion of blackmailing content </div><div class="">networks for additional $$$s will be a moot point, because the content will </div><div class="">be distributed and embedded within every major eyeball network already,</div><div class="">whether they like it or not, on their customer's devices.</div></div></div></div></blockquote><div><br class=""></div>You’d be surprised at the number of different ways eyeball providers have</div><div>to denature such an effort. I’m sorry to rain on your parade, but it’s not a new</div><div>idea. I was brought in as the operations guy once the software engineers</div><div>realized that they needed someone who could, you know, keep stuff running</div><div>and not just write code and test it in production. This model resulted in a</div><div>frank and uncomfortable conversation between me and the developer of</div><div>what was internally being called the “overlay network” code. We went through</div><div>a number of different scenarios where he had made incorrect assumptions</div><div>about how the internet worked, especially at the eyeball end and there</div><div>were a dozen or so that we simply couldn’t find ways to work around.</div><div><br class=""></div><div>Networks are a bit different now and some content providers have people</div><div>far more clever than I working on things like this, so who knows… It might</div><div>succeed by 2026, but when we tried it in 2005, we couldn’t make it work</div><div>well enough to avoid annoying anyone involved.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Let's check back in 2026, and see if someone's become fantastically </div><div class="">successful doing this or not. ;)</div></div></div></div></blockquote><div><br class=""></div></div>I’ll look forward to it.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div></body></html>