Communications of the ACM

requests and offload these requests to the P2P network. The last remaining component will be a browser local storage model where P2P-accelerated content can be stored and distributed. Although no fewer than five different storage options exist in the browser, the IndexedDB17 implementation is the only storage API available within a service-worker context and the DOM context, where the WebRTC code can execute, which is why Edgemesh chose it as the storage base. Alternatively, the CacheStorage API may also be used within the service-worker context. 15

Implementing a Distributed Internet

We have a theoretically viable model to support peer-to-peer content delivery. We have a functional network stack to enable ad-hoc efficient peer-to-peer transfer and access to an in-browser storage medium. And so, the game is afoot!

Figure 5 is a flowchart of the Edgemesh P2P-accelerated content-delivery system. The figure shows where the service-worker framework will enable asset interception, and WebRTC (aided by a signal server) will facilitate browser-to-browser asset replication.

Returning to Mike Belshe’s research, we can start to dig into some of the key areas to be optimized. Unlike bandwidth, where adding incrementally more bandwidth above 5Mbps has negligible impact on page-load time, latency (RTT) dramatically increases page-load time. 3

WebRTC is already an efficient protocol, but the peer-selection process presents opportunities for further latency reduction. For example, if you are located in New York, providing a peer in Tokyo is likely a nonoptimal choice.

A simple optimization might be to prefer peers that reside in the same network, perhaps identified by the autonomous system (AS) 23 number of each peer. Even this simple optimization can cut the average latency by a factor of two. Figure 6 shows performance increase by intra-AS routing preference.

Another optimization is choosing which assets to replicate into a peer.

For example, if a user is currently
browsing the landing page of a site, we
can essentially precache all the imag-
es for the next pages, effectively elimi-
nating the latency altogether. This is a
current area of research for the team
at Edgemesh, but early solutions have
already shown significant promise.
Figure 7 shows the effective render
time for Edgemesh-enabled clients
(accelerated) and non-Edgemesh en-
abled clients (standard) for a single
customer domain. The average page-
load time has been reduced by almost
a factor of two.

This is most clearly seen when most of the page content can be effectively precached, as shown in the page-load time statistics of Figure 8.

Conclusion

It had been a few days since I had been outside, and a few more since I would make myself presentable. For the previous few weeks the team and I had been locked inside the office around the clock, essentially rewriting the software from scratch. We thought it would take a week, but we were now three months in. The growing pile of empty delivery bags resting atop the ad-hoc whiteboard tables we were using was making it difficult to make out exactly what the big change was. We were convinced this was the breakthrough we had been looking for (turns out it was), and that this version would be the one that cracked the problem wide open. I was head down trying to get my parts to work, and I was lost. Then I heard the knock at the door. She came in and sat down, patiently moving aside the empty pizza boxes while I babbled on about our big breakthrough and how I was stuck.

Then, just like she had nearly two de-
cades earlier, she grabbed the marker
and said:
“Honey, I think I see the issue. You
haven’t properly defined the problem.
Most times, defining the problem is
harder and more valuable than finding
the answer. So, what exactly are you try-
ing to solve?”
The world is more connected than
it ever has been before, and with our
pocket supercomputers and Internet
of Things’ future, the next generation
of the Web might just be delivered in
a peer-to-peer model. It’s a giant prob-
lem space, but the necessary tools and
technology are here today. We just need
to define the problem a little better.

References

1. Adamic, L.A., Huberman, B. A. Zipf’s law and the Internet. Glottometrics 3 (2002), 143–150; http:// www.hpl.hp.com/research/idl/papers/ranking/ adamicglottometrics.pdf.

2. Apple Inc. Safari 11.0; https://developer.apple.com/ library/content/releasenotes/General/ WhatsNewInSafari/Safari_ 11_0/ Safari_11_0.html.

3. Belshe, M. More bandwidth doesn’t matter (much), 2010; https://docs.google.com/a/chromium.org/ viewer?a=v&pid=sites&srcid= Y2hyb21pdW0ub3JnfGRldnxneDoxMzcy OWI1N2I4YzI3NzE2.

4. Berners-Lee, T. Solid; https://solid.mit.edu/.

5. BlogGeek. Me. Why was SCTP selected for WebRTC’s data channel, 2014; https://bloggeek.me/sctp-data-channel/.

6. Cheshire, S. It’s the latency, stupid, 1996–2001;
http://www.stuartcheshire.org/rants/latency.html.
7. Google Groups. WebRTC, 2016; https://groups.google.
com/forum/#!topic/discuss-Webrtc/I0GqzwfKJfQ.
8. Hart, C. WebRTC: One of 2016’s biggest technologies
no one has heard of. WebRTC World, 2017; http://
www.webrtcworld.com/topics/webrtc-world/
articles/428444-webrtc-one-2016s-biggest-
technologies-no-one-has.htm.

9. H TTP Archive; http://httparchive.org/trends.php.

10. Internet World Stats. World Internet usage and population statistics—March 31, 2017; http://www. internetworldstats.com/stats.htm.

11. Leighton, T. Improving performance on the Internet. acmqueue 6, 6 (2008); http://queue.acm.org/detail. cfm?id=1466449.

12. Levine, P. The end of cloud computing. Andreessen Horowitz; http://a16z.com/2016/12/16/the-end-of- cloud-computing/.

13. Loveless, J. Barbarians at the gateways. acmqueue 11, 8 (2013); http://queue.acm.org/detail. cfm?id=2536492.

14. Meeker, M. Internet trends 2017—code conference. KPCB; http://www.kpcb.com/internet-trends.

15. Mozilla Developer Network. CacheStorage, 2017; https://developer.mozilla.org/en-US/docs/Web/API/ CacheStorage.

16. Mozilla Developer Network. FetchAPI, 2017; https://developer.mozilla.org/en-US/docs/Web/API/ Fetch_API.

17. Mozilla Developer Network. IndexedDB API, 2017; https://developer.mozilla.org/en-US/docs/Web/ API/IndexedDB_API.

18. Mozilla Developer Network. Using service workers,
2017; https://developer.mozilla.org/en-US/docs/Web/
API/Service_Worker_API/Using_Service_Workers.
19. Real-time communication in Web browsers (rtcweb)
Charter for Working Group; http://datatracker.ietf.org/
wg/rtcweb/charter/.
20. Simple WebRTC video/voice and data channels.
Github; https://github.com/edgemesh/simple-peer.
21. WebR TC for Go. Github; https://github.com/
keroserene/go-webrtc.
22. Wikipedia. Signalling System No. 7;
https://en.wikipedia.org/wiki/Signalling_System_No._7.
23. Wikipedia. Autonomous system;
https://en.wikipedia.org/wiki/
Autonomous_system_(Internet).

24. Wolfgang Digital. E-commerce KPI benchmarks, 2016; https://www.wolfgangdigital.com/uploads/ general/ KPI_Infopgrahic_2016.jpg.

25. You Tube. WebRTC, 2016; https://youtu.be/OUfYFMGtPQ0?t=16504.

Jacob Loveless is chief executive officer at Edgemesh Corporation, the edge-network acceleration platform. Previously, he served as CEO of Lucera Financial Infrastructures and was a partner at Cantor Fitzgerald, responsible for running the firm’s global low-latency trading operations.