[ih] ARPANET pioneer Jack Haverty says the internet was never finished

[Jack Haverty]

One of the points I tried to make in the talk that started this 
discussion was that the Internet architecture moved mechanisms from the 
"switching" to the "host" parts of the overall system, which has 
significant impact on how you "operate" and optimize the pieces. Not 
enough time to explain that very well though.

One of the results of that architecture is the necessity to look at the 
whole picture to understand what is going on.   My "glitch on the 
transpacific line" example required looking at both the 
hosts/applications as well as the routers to understand why service had 
slowed dramatically.

So, how can you be sure that CDNs necessarily "reduce overall work" by 
placing CDN servers near a user community?

Another experiment I did involved the Internet pathways involving my 
location, one in Reno nevada, and one in Los Angeles.  Reno is about 50 
miles or so East of me.  LA is hundreds of miles south and west of me.

So a CDN builder might assume that it would be useful to place a CDN 
cache in Reno as a close-by city.   But experimenting with traceroute 
indicated that packets from me to Reno actually went west, not east, 
travelled to LA, bounced around a few nodes in SoCal, and eventually 
came back north and east to Reno.

So for me, a CDN in LA, hundreds of miles away, would be actually much 
closer than one in Reno, 50 miles away.   It would be especially 
inefficient if the ultimate source of the content was in the LA area.

Conclusion - you have to look at the whole system to understand what is 
going on.

Jack


On 3/5/22 09:37, touch--- via Internet-history wrote:
> Hi, Miles,
>
>> On Mar 5, 2022, at 7:09 AM, Miles Fidelman via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> Joe Touch via Internet-history wrote:
>>>>> ...
>>>> By that view YouTube, Zoom, podcasts, and CDNs are all "prohibitive".
>>> They copy at the source at the app layer, not in L2 anywhere.
>>>
>>> it’s not the BW, but the local serial copy operation and it’s state that are prohibitive.
>>>
>> No more prohibitive than doing it as an overlay.  If anything, it's more complex and resource intensive as an overlay.  (Granted that we're talking multiple overlays - but the cost here is interoperability.)
> I should have been more specific:
>
> CDNs move the work to L7. That doesn’t reduce the overall work for edge distribution, but it does avoid serial local copy inside (cheap) L2 devices that don’t always have the capacity to do so.
>
> (CDNs *do* reduce *overall* work by caching content closer to users, thus reducing overall network traffic vs. repeated use of multicast trees rooted a the original content source, but that’s a separate issue).
>
> Joe