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.
Copyright held by owner/author.
Publication rights licensed to ACM. $15.00.