RE: Impacts of Encryption Everywhere (any solution?)

["McBride, Mack" <C-Mack.McBride () charter com>]

Netflix is not supposed to be cacheable by third parties for legal reasons 
that have absolutely nothing to do with routing.
Similar with most streaming services including stupid geolocation usage.
If you have sufficient eyeballs, Netflix will work with you to get a local cache
set up using their devices.  If it is just you and a half dozen neighbors they won't.

A far larger problem than the encryption is website design that doesn't cater to
low bandwidth links.  HTML5 is cool but marking a 10mbyte animation as non-cachable
and putting it on the front page of a major bank website is a misuse of resources.

Mack

-----Original Message-----
From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of William Herrin
Sent: Tuesday, June 19, 2018 9:34 AM
To: Lee Howard <lee.howard () retevia net>
Cc: nanog () nanog org
Subject: Re: Impacts of Encryption Everywhere (any solution?)

On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard <lee.howard () retevia net> wrote:
> On 06/17/2018 02:53 PM, Brad wrote:
> > While I agree there are unintended consequences every time 
> > advancements are made in relation to the security and stability of 
> > the Internet- I disagree we should be rejecting their 
> > implementations. Instead, we should innovate further.
>
>
> I look forward to your innovations.

The innovation I'd like to see is a multi-level streaming cache.
Here's the basic idea:

Define a network protocol such as "mlcache"

mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that netflix has. It's encrypted. The client 
got the decryption key for that chunk and instructions on how to load the chunks in what order in an authenticated http 
connection.

The client does not connect to data.netflix.com. Instead, it probes an anycast IP address to find the nearest cache. If 
there is no cache, then it falls back on contacting data.netflix.com directly.

If the cache probe returned a unicast IP address for a nearby cache then the client asks the cache to retrieve that 
chunk instead. If lots of folks using the cache are watching that particular video, the cache can supply the chunk 
without asking netflix for it again.

If the cache doesn't have the chunk, it contacts the next cache upstream. If there is no next cache upstream, it 
contacts data.netflix.com directly.


The cache is not application-specific. Anything willing to talk the cache protocol can use it to fetch chunks of data 
from any server.

In principle this should work for live streams too. The head end server either replies "not yet" or holds the request 
open until the next chunk of data is available. The cache requests the chunk once and supplies it to all clients once 
retrieved. Keep the chunks small enough that the caching process delays the live stream by a second or two, no 
different than the television broadcasts do.


Regards,
Bill Herrin



--
William Herrin ................ herrin () dirtside com  bill () herrin us Dirtside Systems ......... Web: 
<http://www.dirtside.com/>
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain 
confidential and/or legally privileged information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this 
message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly prohibited.