Add p2p overlays & wordsmithing

overlay.rst

@@ -56,3 +56,4 @@ available to applications.
 .. include:: overlay/design.rst
 .. include:: overlay/cdn.rst
 .. include:: overlay/conference.rst
+.. include:: overlay/p2p.rst

overlay/cdn.rst

@@ -40,8 +40,7 @@ There’s not a lot anyone except you or your local service provider can
 do about the first-mile problem, but it is possible to use content
 replication to address the remaining problems.  Content distribution
 networks are the systems that manage the process of replicating
-content and delivering it to clients, which has a few more moving
-parts than first meet the eye. Akamai was one of the first operators
+content and delivering it to clients. Akamai was one of the first operators
 of a CDN and today there are a number of large CDN operators with
 global footprints.
 
@@ -51,12 +50,12 @@ of *backend servers*. Thus, rather than having millions of users wait
 forever to contact when a big news story breaks—such a situation is
 known as a *flash crowd*—it is possible to spread this load across
 many servers. Moreover, rather than having to traverse multiple ISPs
-to reach ``www.cnn.com``, if these surrogate servers happen to be
+to reach a popular site, if these surrogate servers happen to be
 spread across all the backbone ISPs, then it should be possible to
 reach one without having to cross a peering point. Clearly,
 maintaining thousands of surrogate servers all over the Internet is
-too expensive for any one site that wants to provide better access to
-its web pages. Commercial CDNs provide this service for many sites,
+too expensive for most sites that wants to provide better access to
+their web pages. Commercial CDNs provide this service for many sites,
 thereby amortizing the cost across many customers.
 
 Although we call them surrogate servers, in fact, they can just as
@@ -68,9 +67,12 @@ also the case that only static pages, as opposed to dynamic content, are
 distributed across the surrogates. Clients have to go to the backend
 server for any content that either changes frequently (e.g., sports
 scores and stock quotes) or is produced as the result of some
-computation (e.g., a database query).
+computation (e.g., a database query).\ [#]_
 
-.. TODO -- need to check - can't code run in modern CDN nodes?
+.. [#] CDN operators sometimes offer a complementary service that
+       allows their customers to dynamically generate certain content
+       at the surrogates, but that raises its own set of technical issues.
+       We focus here on static content.
 
 .. _fig-cdn:
 .. figure:: overlay/figures/f09-30-9780123850591.png
@@ -155,25 +157,26 @@ rather than transparent, proxy).
 
 .. sidebar:: Are CDNs Overlays?
 
-   Many of the early overlays built on top of the Internet use some
+   *Many of the early overlays built on top of the Internet use some
    sort of tunneling to create virtual point-to-point links, and
    created a virtual topology between the overlay nodes to offer some
    function not yet implemented in the Internet, such as multicast of
    IPv6 support. CDNs don't quite conform to this model, since they
-   don't generally build tunnels between the CDN nodes. We would
-   argue, however, that they have enough in common with other types of
-   overlay to qualify. They offer functionality not natively provided
-   by the Internet—caching—while using the Internet to interconnect
-   the nodes in the CDN. A redirector makes an application-level
-   routing decision, much like other types of overlay nodes.  Rather
-   than forward a packet based on an address and its knowledge of the
-   network topology, it forwards HTTP requests based on a URL and its
-   knowledge of the location and load of a set of servers.  The
-   complete collection of redirectors and surrogate servers that make
-   up a CDN are effectively an application-specific network that
-   leverages the underlying connectivity of the Internet bring
-   additional functionality to the Internet: efficient delivery of
-   content to clients.
+   don't generally build tunnels between the CDN nodes.*
+
+   *We would argue, however, that they have enough in common with
+   other types of overlay to qualify. They offer functionality not
+   natively provided by the Internet—caching—while using the Internet
+   to interconnect the nodes in the CDN. A redirector makes an
+   application-level routing decision, much like other types of
+   overlay nodes.  Rather than forward a packet based on an address
+   and its knowledge of the network topology, it forwards HTTP
+   requests based on a URL and its knowledge of the location and load
+   of a set of servers.  The complete collection of redirectors and
+   surrogate servers that make up a CDN are effectively an
+   application-specific network that leverages the underlying
+   connectivity of the Internet bring additional functionality to the
+   Internet: efficient delivery of content to clients.*
 
 
 |Overlay|.2.2 Policies
@@ -203,13 +206,13 @@ output.
 
 So what makes for a good hashing scheme? The classic *modulo* hashing
 scheme—which hashes each URL modulo the number of servers—is not
-suitable for this environment. This is because should the number of
-servers change, the modulo calculation will result in a diminishing
-fraction of the pages keeping their same server assignments. While we do
-not expect frequent changes in the set of servers, the fact that the
-addition of new servers into the set will cause massive reassignment is
-undesirable. An alternative is to use the a *consistent hashing*
-algorithm.
+suitable for this environment. This is for a simple reason: should the
+number of servers change, the modulo calculation will result in a
+diminishing fraction of the pages keeping their same server
+assignments. While we do not expect frequent changes in the set of
+servers, the fact that the addition of new servers into the set will
+cause massive reassignment is undesirable. An alternative is to use
+a *consistent hashing* algorithm.
 
 
 .. _fig-unitcircle:
@@ -301,13 +304,14 @@ measurement as the “server load” parameter in the preceding
 algorithm. This strategy tends to prefer nearby/lightly loaded servers
 over distant/heavily loaded servers. A second approach is to factor
 proximity into the decision at an earlier stage by limiting the
-candidate set of servers considered by the above algorithms (*S*) to
-only those that are nearby. The harder problem is deciding which of
-the potentially many servers are suitably close. One approach would be
-to select only those servers that are available on the same ISP as the
-client. A slightly more sophisticated approach would be to look at the
-map of autonomous systems produced by BGP and select only those
-servers within some number of hops from the client as candidate
-servers.  Finding the right balance between network proximity and
-server load has been the subject of considerable research and we
-assume that the CDN operators continue to fine-tune their algorithms.
+candidate set of servers considered by the above algorithms (set *S*
+in the pseudocode) to only those that are nearby. The harder problem
+is deciding which of the potentially many servers are suitably
+close. One approach would be to select only those servers that are
+available on the same ISP as the client. A slightly more sophisticated
+approach would be to look at the map of autonomous systems produced by
+BGP and select only those servers within some number of hops from the
+client as candidate servers.  Finding the right balance between
+network proximity and server load has been the subject of considerable
+research and we assume that the CDN operators continue to fine-tune
+their algorithms.

overlay/conference.rst

@@ -15,17 +15,55 @@ terms of the overlay is that rather than being a generic IP multicast
 overlay, each video conferencing application has its own
 application-specific overlay.
 
+.. sidebar:: IP Multicast: A Case Study
+
+    *We have mentioned IP Multicast and the MBone multiple times in
+    this chapter. That they are primarily of historical interest makes
+    for an an interesting case study of how the Internet has evolved.
+    IP Multicast is the core feature, and as explained in
+    Section |Overlay|.1, a block of the IPv4 address space was set aside for
+    multicast addresses. The idea was that you could assign one of
+    these address to a multicast group, users could request to join
+    that group (technically, they added their host to the group), and
+    then any IP packet set to that multicast address would be
+    delivered to every host in the group.*
+
+    *The data plane part of multicast IP is easily solved: switch
+    forwarding pipelines are able to send an incoming packets to multiple
+    outgoing queues.  What proved hard is the control plane part of
+    the problem, that is, propagating "join requests" to those routers
+    that needed to know about any particular multicast address. This
+    is a effectively a routing problem, and when you take both scale
+    and AS autonomy into account, the resulting protocol turned out to
+    be as complex as BGP, if not more so.*
+
+    *The MBone was an overlay used to gain experience with multicast,
+    with the goal of eventually pushing the solution down into
+    commercial routers so it could be widely deployed. IP Multicast
+    was never widely deployed in the Internet (with one main
+    exception), but this wasn't a problem that could be overcome, even
+    by limiting the solution to an overlay.  A general-purpose
+    multicast mechanism just does not return enough value to offset
+    the corresponding complexity (at least for video
+    conferencing). One exception where IP Multicast pays off is when
+    delivering live TV over the last hop, from the "video head" to
+    cable set-top boxes (or Smart TVs) in homes. Last-hop multicast
+    easily beats N-way unicast, and the control overhead is
+    manageable.*
+
+.. TODO -- Could say more, but maybe this is enough of a summary.
+
 An overlay is an optimization in the sense that you can run a video
 conferencing application without one. Indeed, if there are only two
 participants in the conference, no optimization is needed. Each
 participant can just send video and audio streams to the other
 participant directly. There are still some issues to be solved,
 including what to do if one or both participants is behind a firewall
-or NAT, as we discussed in Section |Virt|.3.3. The broader issues that
-multimedia applications face are the topic of Chapter |Stream|. But
-optimizing the delivery of media to a large
-number of conference participants is a job usually performed by an
-overlay.
+or NAT, as we discussed in Section |Virt|.3.3. The real-time
+challenges that multimedia applications face are the topic of Chapter
+|Stream|, but optimizing the delivery of media to *multiple*
+conference participants—i.e., the multicast part of the solution—is
+usually performed by an overlay.
 
 Consider the simple case of a 3-party video conference. You can
 obviously treat this as 3 pair-wise connections: each participant
@@ -38,19 +76,12 @@ multicast at the IP layer, some way to replicate the traffic upstream
 from the participants is needed, and this is the role normally performed by an
 application-specific overlay.
 
-.. _fig-sfu:
-.. figure:: overlay/figures/sfu.png
-   :width: 600px
-   :align: center
-
-   Media Distribution Using Selective Forwarding Unit.
-
 The typical solution to media replication is for each participant to
 send their media to a replication device, which is likely to be
 located in some cloud datacenter and operated by the company running
 the conferencing service. One class of replication devices are
 known as "selective forwarding units" (SFUs). In :numref:`Figure %s
-<fig-sfu>` we've shown the very simple case where there is a single
+<fig-sfu>` we've shown the simplest case where there is a single
 SFU. All participants send their media to the SFU, and it sends a
 set of media streams out to all the participants. The "selective" part
 means that the SFU does not necessarily send every stream to every
@@ -60,6 +91,13 @@ participants, while other clients could receive all streams and render
 them appropriately on their screens. SFUs also forward media streams rather
 than modifying them.
 
+.. _fig-sfu:
+.. figure:: overlay/figures/sfu.png
+   :width: 600px
+   :align: center
+
+   Media Distribution Using Selective Forwarding Unit.
+
 There is an alternative approach, in which a *Multipoint Control Unit*
 (MCU) combines the incoming streams into a single outgoing stream,
 such as by tiling four videos into a 2x2 grid. This is more
@@ -69,8 +107,8 @@ Of course, a single replication device is both a bottleneck from the
 perspective of scaling, and a potential single point of failure. So
 what we typically see in practice is a complete overlay network of
 SFUs, with some SFUs capable of picking up the load from others in the
-event of a failure, and SFUs arranged in a mesh so that replication
-can be distributed amount the nodes in the mesh rather than all the
+event of a failure. The SFUs are arranged in a mesh so that replication
+can be distributed among the nodes in the mesh rather than all the
 work falling on a single node. A simple example of this using three
 SFUs in a tree structure is shown in :numref:`Figure %s
 <fig-sfu-mesh>`.
@@ -90,11 +128,3 @@ the overlay. This is how most video conferencing solutions on today's
 Internet work, using overlays to scale the performance of the
 application without any assistance beyond basic packet transport from
 the core of the Internet.
-
-.. sidebar:: IP Multicast: A Case Study
-
-    There's an opportunity to say a bit more about IP multicast,
-    including what made it hard: the routing protocol, which provided
-    a means to join a multicast group. Then link 6E section for more
-    info. Also note where it is used today: last mile into the home
-    (for live streams).