Minutes of the Multicast WWW BOF
Reported by: Scott Michel <scottm@aero.org> and
Bernard Aboba <bernarda@microsoft.com>
A mailing list has been established for discussion of WWW-Multicast issues:www-multicast-request@w3.org. The archive of the mailing list is assessable via:
http://lists.w3.org/Archives/Public/www-multicast.
Agenda Bashing (no bash mode triggered)
III. Existing uses of multicast technology to support the WWW
IV. Potential areas of standardization
VI. Unreliable transport requirements
Strawman problem statement: The major problem to be addressed with WWW-Multicast is overloading of Web servers and networks due to "flash crowds."
Release of Internet Explorer 3.0. This was a large (10 MB) file. Result: 30K download within the first hour, generating network outages throughout the Pacific Northwest. This occurred despite distribution of the file to more than 20 locations worldwide, and multiple DS-3 connectivity. Discovery of life on Mars. After the discovery, there was a dramatic increase in demand for pictures from the NASA site. This resulted in outages within the NASA network, again, despite DS-3 level connectivity.
What do these incidents have in common?
They are events of global interest. They represented increases in demand of more than an order of magnitude above baseline. The effects were felt well beyond the site itself, causing losses of connectivity within the region that lasted for considerable periods of time. They represent file transfers of substantial size, causing network connections to stack up, and negating any attempt at randomization. They occurred at sites that are among the best connected on the Internet, despite programs in place for caching and distributing load.
Thought experiment: it is easy to understand why caching was not effective in the above scenarios. Compare the load of multicasting a large file continuously to 30K listeners with having 30K requests go to a few dozen caches.
Part 2 of the Problem Statement: May the problem be made worse by "push technology"?
Some Fortune 500 companies have banned the use of "push technology" after discovering that it consumed 30 percent or more of LAN bandwidth. In many of these cases, proxy servers were already in place, but only addressed the WAN portion of the problem. Automated software upgrades have also been known to degrade LAN performance for several days.
What do these incidents have in common?
The incidents often involved distribution of resources of wide interest within the enterprise, although by no means "earth shaking" events such as discovery of life on other planets. The effects occurred despite use of proxies and mechanisms for distributing load. Mechanisms used to attempt to smooth load (such as randomization) were not effective, due to the size of the files.
At this point, members of the audience were asked why they had come to the BOF.
· To eliminate redundant packets on the net, via use of multicast for data distribution
· Concern over Internet congestion created by HTTP. While HTTP 1.1 may improve things (pipelining, persistent connections, etc.), it is not clear that this is a complete solution.
· Use of satellite for data distribution, in circumstances with no or a small uplink. In such cases, reliable multicast protocols utilizing ARQ are not an option, since they can swamp the uplink.
· Multicasting of frequently updated Web pages.
Concern over multicast distribution. Is this really A Good Thing? What will the architecture look like? What will infrastructure support look like and what impact will there be?
Members of the audience were then asked to describe possible applications for the technology. These included:
· Distribution of resources to client browser caches prior to users requesting them (prefetch).
· Distribution of resources to proxy caches.
· Distribution of frequently updated pages (stock tickers).
· One-way Web browsing (over satellite or cable links with little or no upchannel).
· Change notification for frequently changing pages.
· Web crawlers (rather than having n crawlers, multicast the result of a single crawl).
· Multicast distribution of mailing lists and USENET.
III. Existing Uses of Multicast Technology to Support the WWW
Existing uses of Multicast-WWW were discussed. These have typically centered on the collaborative Web browsing problem, rather than the "load reduction" issues identified above. Previous work included:
Hopwise reliable multicast
http://www-atp.llnl.gov/papers/HRM/HRM.html
Chris Bornmann, Univ. of Oregon
http://www.cs.uoregon.edu/~chrisbo/mhttpd/Overview.html
Mr. Dauphin, dauphin@sig.enst.fr
http://sig.enst.fr/~dauphin/mMosaic/index.html
Peter Parnes, Lulea University of Technology
http://www.cdt.luth.se/~peppar/docs/
http://www.cc.gatech.edu/computing/Telecomm/
http://www.ncsa.uiuc.edu/SDG/Software/Xmosaic/CCI/webcast.html
Existing work can be described in the following matrix:
Applications Unreliable Transport Reliable Transport
Having tried group web browsers using both unreliable and reliable transport, the subjective assessment is that the experience was not much different, at least for browsing of small files. It should also be noted that without pipelining or persistent connections, such applications will defeat the congestion control put into reliable multicast protocols.
Prefetch applications have used unreliable multicast, since it is not clear whether the file will ever generate a cache hit. Therefore, reliability doesn't make sense in this application.
However, cache filling applications make more sense for reliable transport, in situations where there is an outstanding cache hit. In this case, you know you want the file, so you are more likely to want reliability.
File transfer applications have almost exclusively used reliable transport. However, for satellite or cable links, reliability is often provided via Forward Error Correction (FEC), not ARQ-style reliability provided by existing reliable multicast protocols. ARQ-style reliability is not acceptable in these applications, since it has the potential to swamp the upchannel.
Some existing work has provided for multicasting of frequently updated page elements. However, it is not clear that Multicast-WWW is the best way of accomplishing this.
In the general case, Multicast-WWW involves a requester, a sender, and receivers, as well as a session announcer. The requester is the machine that requests that the resource be multicast; the sender is the machine that multicasts the resources; and the receiver is the machine that receives the multicast resources. While the requester could announce the session, there are good reasons for this to be handled by the sender. This guarantees that the scope of the announcement will be identical to the scope of the resource transmission.
It should be noted that not all Multicast-WWW applications have a requester; in collaborative Web browsing applications, resources are typically sent without a request, and in these implementations it is also common for senders to act as receivers. Prefetch applications may also not have a requester, instead providing the sender with a schedule of resources to be multicast.
Given this usage model, Multicast-WWW tends to more resemble the RTSP model than a conventional HTTP client/server interaction. In RTSP, there can be a third party requesting a multicast transmission to a group.
IV. Potential Areas for Standardization
Currently, this is handled via SAP/SDP. However, SDP does not support announcing a schedule of resources that will be multicast on a group. Therefore, extensions may be required. There may also be work necessary to converge unicast channel announcement mechanisms (such as CDF) with SAP/SDP.
Q: Do you always want to multicast channel announcements?
A: Probably not. It only makes sense to multicast resources (and announcements) that are likely to be popular. No sense using precious routing table space to announce your grandmother's Web page via multicast. Making it easy for lots of unpopular pages to be multicast could exhaust the multicast address space, and generate lots of unnecessary load on the multicast routing system.
Q: How do you decide if a popular page should be announced and multicast?
A: This can be accomplished via measurements of popularity, either by the sending server, or by a proxy cache.
Request for multicast transmission
Currently, HTTP does not include a mechanism for requesting that a resource be multicast, although RTSP (which has HTTP-like syntax) does. The item to be multicast may already reside on the server, in which case a GET would be utilized, or it may be submitted to the server (a PUT).
Items that would need to be included in the request include:
· The URL of the item to be multicast
· Transport mechanism (reliable/unreliable)
Response to the request for multicast transmission
Currently HTTP does not include a mechanism for responding to a request to multicast a resource. A number of new error conditions or other circumstances could arise that would require addition of new response codes to HTTP.
Currently, Reliable Multicast is being investigated by the IRTF, but it appears that a number of the applications of Multicast-WWW would use unreliable transport, even if reliable transport were available. These include:
Prefetch applications, where use of reliable transport does not make sense
Satellite applications with little or no upchannel (preventing use of ARQ-based reliable multicast)
Applications requiring time-sensitive data (stock tickers)
Q: Are HTTP Request/Response mechanisms separable from underlying transport issues?
A. In general, no. For example, HTTP v1.0 negated TCP congestion avoidance by opening a new connection for each request. This was fixed in HTTP v1.1 via inclusion of pipelining and persistent connections. The same issues apply to Multicast-WWW, since the effectiveness of congestion avoidance in a reliable transport mechanism could be compromised by inappropriate application-layer protocols. For example, you wouldn't want to use a new group for every file transfer, or creating a new stream for each file in a large sequence of files. Doing these things would compromise congestion-avoidance.
Q: If this is so, how is it possible to proceed on standardization of request/response without first resolving underlying transport concerns?
A. You'd want to make sure that application layer request/response mechanisms support the concepts of pipelining and persistent connections, and that these mechanisms are used for retrieving large sequences of small files.
Q: Is there another way of framing the problem so that it doesn't rely on reliable or unreliable multicast, thereby avoiding the interactions?
A: Request/response issues are probably not separable from multicast due to differences in the sender/receiver model, related security issues (i.e., denial of service spam) and the necessity of specifying multicast parameters.
V. MAFP: Multicast Attribute Framing Protocol (Ross Finlayson)
Many multicast-based applications are pushing or sharing attribute data, e.g., stock ticker feeds, active maps, multimedia session descriptions (currently done via SDP.) These could use a common "on the wire" data format for representing attribute data, value/attribute pairs. AVPs are commonly used in a number of protocols, including RADIUS, and L2TP. Adoption of the AVP paradigm with multicast could result in a more general session announcement mechanism than what SDP currently provides. For example, SAP/SDP currently has major scalability problems that could be addressed by the use of hierarchy. MAFP is independent of transport, since it is intended to be a presentation layer protocol. While complete HTML documents might be represented as MAFP attributes, it is more likely that MAPF may be used to represent fragments of documents.
Benefits of this approach include: development speed, ease of debugging, making it possible to produce flexible, general purpose multicast applications.
Issues include firewall and security problems. To be effective, MAFP must be able to travel through firewalls (groups addresses/ports must be clearly visible to the firewalls).
See the strawman design in "draft-finlayson-mafp-00.txt", or http://www.lvn.com/mafp.
Q: Why not use existing protocols?
A: MAFP is intended to sit on top of any transport: UDP, TCP, multicast/unreliable, or multicast/reliable.
This is a protocol that is optimized for rapid change-type applications.
Q: In cases where application data is already well structured (i.e., stock data), won't MAFP incur a lot more overhead, due to needing to send attribute/value pairs?
A: yes
It was noted that most people at the BOF were concerned with issues relating to overloading the Web, cache filling (prefetch, or post-hit), or one-way Web browsing (such as satellite applications). There appears to be less interest in group web browsing or stock tickers (e.g., rapid change applications.)
Consensus is that overloading is the most serious problem not addressed by existing efforts (such as caching protocols). Work on caching protocols has just started, so that it is not yet clear to what extent protocols such as ICP can be used for multicast cache filling (prefetch or post-hit). If possible, it would be desirable to have only a single multicast cache-filling protocol.
Based on the reported overloading incidents (Internet or Intranet), it would appear that most of the overloading problems can be addressed via reliable multicast file transfers (software release or upgrade case). The NASA Life on Mars case may be best addressed through some other mechanism, such as by unreliable multicasting of redundantly encoded images. Post-hit cache filling may also be an application for reliable multicast, although of a different flavor (pseudo-reliability).
It is noted that although it is generally thought that the IRTF is slow, that in this case, they may generate conclusions relevant to post-hit cache filling application sooner than might be expected. However, another audience member commented that IRTF work is focused on ARQ-based reliable multicast protocols that could not be used for satellite transmission, or may not be needed in pre-fetch applications.
One audience member commented that cache filling isn't important, because there's a potential for a lot of clutter from "one-use-only" pages. Another commented that pre-fetch is not a good idea for filling of proxy caches, since the pages might not be hit; this is why it is typically utilized for filling of browser caches in "push applications."
One audience member asserted that caching and ICP is the solution to flash crowds. However, it is noted that major congestion incidents had occurred even in cases where caching was employed. The problem is the peak to baseline ratio; when this varies by several orders of magnitude, caching is ineffective, since no one wants to pay to deploy caches that will not be used most of the time. The bottom line is that caches reduce traffic in proportion to the number of caches deployed, while multicast reduces traffic in proportion to the number of receivers. As a result, multicast is a more effective solution for flash crowds, while caching is more effective for average pages where multicast cannot be justified. So caching is not the solution to the flash crowd problem, although it may lower the baseline level of congestion.
VII. Vote on Working Group Formation
Consensus is that a new Working Group should not be formed at this time.