Tina H. Wong
CS294-1 Mobile Computing and Wireless Networking
Project Report
Information dissemination is becoming a hot service in the WWW. One type of dissemination that fits particularly well into personal information management (PIM) involves sending out periodic updates of information. Stock quotes, traffic reports, weather reports, news headlines, etc, are some examples of information that end-users might want to track periodically. Other examples include sensors' readings that send changes about the environment, such as sensors in an especially busy parking lot to denote the availability of parking spaces.
To provide scalability to a large community of end-users, researchers have proposed to use reliable multicast (RM) [DEE91,FLO95,HOL95,LEV96,LIN96] in information dissemination. However, using traditional protocols in this context poses several interesting challenges. First, RM protocols are designed to guarantee eventual delivery of all data, thus they work aggressively to repair all losses. In the case of periodic data in PIM, this is rather unnecessary because the community of end-users subscribing to the service have different interests in the data being disseminated. For example, for a stock-quote service, one user might only be interested in technology stocks, where as another in the most active ones. Also, updates of the data make the previous values obsolete. As an example, consider a traffic report service in which a user received the road conditions at 1:30pm, lost one at 1:40pm, but got the most recent report at 1:50pm. It is unnecessary to repair for the lost report because the user would already have the most recent update on the traffic.
The second challenge in utilizing traditional RM protocols in this context is that they are designed for wired networks. End-users who are on wireless links might have limited or unavailable uplink bandwidth on which to send repair requests on losses. For example, satellite-based networks such as DirecPC [DIR98] are known to have ample downlink bandwidth to the receivers not but vice-versa. Furthermore, some wireless access technologies such as CDMA require their clients to compete for the uplink bandwidth. Thus, ARQ style of loss recovery which requires receivers to send NACKs or requests-for-loss might not be effective in these situations.
Finally, we need to consider power consumption of devices involved in providing or receiving the information. Sensors such as the ones we mentioned earlier most usually run on batteries. Also, PIM is particularly useful to "on-the-go" users who carry PDAs or laptops that have that same constraints. According to [STE95], wireless network interfaces (NIs) take up as much power as an idle PDA. In particular, sending data consumes more power than receiving, and the difference is significant when sending large amounts of data, which reduces the life of the battery. Again, traditional style of loss recovery which requires sender to repair losses could cause devices such as sensors to run low on battery life. Similarly, receivers that need to ask for lost data increase their transmission time and thereby decrease battery life.
In this project, we exploit these characteristics of data, applications, and devices to alleviate the problems of traditional RM protocols mentioned above. In order words, we follow the invaluable concept of Application Level Framing (ALF) proposed by Clark and Tennenhouse [CLA90] which says that one should take into account of an application's semantics in the design of that application's protocol. Also, the notion of selective reliability has been proposed by SRM [FLO95] which says the application should have the flexibility in dealing with data losses and delivery order. We push these two concepts to the extreme in this project and detail the results in this paper. We call our tunable quasi-reliable approach Knob.
This paper is organized as follows. Section 2 describes the Knob protocol. Section 3 talks about the methodology we used to measure the performance of Knob. Section 4 is about the results of the experiments. Section 5 goes over the future work for this project. And we summarizes the paper in section 6.
Knob is tunable because the protocol provides advice to allow receivers to decide whether to repair a data loss. It is quasi-reliable because the protocol does not guaranteed eventual delivery of all the data but only the ones useful to the receivers. There are two basic ideas behind Knob, and they can be further divided into sender-based and receiver-based approaches. In the following subsections, we give the details of the two approaches.
The basic idea behind the sender-based algorithm is that a sender tries to reduce the chances that a receiver will need to repair a data loss by using different type of mechanisms to send the data. Figure 1 shows the architecture of this approach. Data originated from the sender are intercepted by an agent. This agent examines the size of the data, periodicity of the data, and receivers' profiles in this data to choose a mechanism for transmission. By size of the data, we mean the number of packets it takes to send the data, which can also be described as bytes divide by the maximum transfer unit (MTU). From figure 1, we see that there can be three possibilities: the data can fit into 1 packet; the data needs to be fragmented into multiple packets; and the data is small such that multiple of them share a packet. By periodicity of the data, we mean the frequency of which it is being sent or updated. For example, in the stock market, some symbols are being traded very often, thus their values are also updated more frequently than others. In general, data that are more popular than others are disseminated more often. By receivers' profiles, we mean receivers' interests in the data being disseminated. For example, in figure 1, 86% of the receivers are interested in the stock IBM, 95% in CMPQ, and so on.
Figure 1 Sender-based Mechanism
The basic algorithm to determine the type of transmission mechanism is as follows. A piece of data needs to be sent with some kind of parity if its periodicity is low, i.e. it is being disseminated infrequently, and interests is high, i.e. a lot of receivers are interested in this data. The level of parity to be included with the data is directly correspondent to these two factors. Also, the size of the data can tell us the type of parity to use. For example, it makes sense for data that can fit into one packet to use duplication as a forward correction mechanism. For data that need to be fragmented into multiple packets, something like Reed-Solomon code that takes k original packets and derives h parity packets in which any k out of the h+k packets are sufficient to reproduce the original data is a good choice. For now, the mechanisms are heuristically determined. After some measurement studies, we believe the mechanisms can be fine tuned to yield good results.
While size and periodicity of the data are inherent in the sender's side of the dissemination, receivers' profiles are dynamic and the sender needs to find out about them. Each receiver periodically send its profile, which is just a list of data names that the receiver is interested in. To avoid implosion at the sender, we limit the bandwidth of these profile messages to a fixed percentage of the total bandwidth allocated to the multicast session. This is accomplished by adjusting the interval between the profile messages at each receiver according to the size of the receiver community. This scaling mechanism is known as the announce/listen protocol which is employed protocols such as SRM [FLO95], SAP [HAN96], and RTCP [SCH96].
Our approach of collecting receivers' profiles is modeled after the SCUBA protocol proposed by Amir et al [AMI97]. The basic idea behind SCUBA is that it is impractical to maintain a globally consistent view of every receiver's interests, so only an approximation is calculated with a sample of the profiles. Amir et al prove that the convergence time and thus the accuracy of this sampling mechanism is independent to the size of the multicast session. This means that it is scalable to arbitrary large community of receivers in our case.
Before diving into the details of the receiver-based algorithm, we first talk about how a receiver detects a piece of data has been lost. Each data packet is numbered with an increasing sequence number, and a discontinuity in the sequence number denotes a loss. For ARQ, this is enough information to generate a repair-for-loss. However, this mechanism is inflexible for the application-based retransmissions we are doing. First, upon seeing a gap in the packet sequence number series, a receiver needs to decide whether it is interested in the lost data. However, if the data is composed of just one packet, or if a series of packets that composed of the data are lost, then the receiver cannot find out the what has been lost by simply looking at the packet level sequence numbers. Second, since the data are periodic in nature, a loss can potentially become a tail loss and cannot detected by the receiver if there are no new data are the loss.
These and other problems of using monolithic sequence numbers in transport protocols to drive application-based retransmissions have been addressed by the SNAP protocol in Raman and McCanne [RAM98]. In this project, we use SNAP to solve the two problems mentioned above. The basic idea behind SNAP is for the sender to periodically send control messages that denote the current status of information to the receivers. The control messages are called namespace message because they contain in them the status of each of the data names (or application data units, adus) in the dissemination, which are the sequence numbers associated with the adus. This is different from the packet level sequence numbers. For example, in a stock dissemination service, IBM quotes can have a adu sequence number of 302 because it is being updated and/or disseminated very frequently, while a lesser known stock AALA can have one of only 10. To provide scalability, these namespace messages are transmitted using an announce/listen protocol which is outlined above. Thus, a loss in these messages would be recovered by the nature of its periodic refresh, and the receivers can continue its normal operation even in face of such loss.
Figure 2 Receiver-based Mechanism
Figure 2 shows the architecture for the receiver-based mechanism. A receiver only repairs a data loss if that piece of data is "worthwhile". We define the data that is lost as "worthwhile" if it fits all of the following three criteria. First, the receiver is interested in the data. This information can be obtained from the application through its user interface. Second, the loss is a tail loss, i.e. the receiver has not received anything with a higher adu sequence number than the one that was lost. A receiver detect there is a loss in the data it is interested in by comparing the adu level sequence number in the namespace messages to its own. To continue from the last example, if the receiver is interested in IBM but only has up to adu sequence number 301, then a loss has occurred for adu IBM. Third, Knob extends SNAPs by including the estimated mean update times of the adus and their corresponding deviations in the namespace messages. The lost data is "worthwhile" to be repaired if it is being disseminated less frequently than a user-specified threshold. This threshold can be chosen by the application based upon the amount of uplink bandwidth available, power consumption, and the staleness of the data.
We conducted experiments to study the performance of the receiver-based portion of the Knob protocol. Figure 3 shows the setup of the experiments. The big picture is that data are being generated in the live network, intercepted by a simulated network which adds delay, introduces drops, and queueing, etc, and then piped back out to the live network to be received by the receivers.
Figure 3 Setup of emulation experiment
We implemented in the Knob protocol as an extension to the Berkeley's SRMv2 toolkit. SRMv2 also includes the SNAP protocol we mentioned above. We also implemented a simple information dissemination application with the Berkeley's MASH toolkit. This application is driven by a data generator that follows a distribution supplied by a distribution generator. In other words, the information being generated follows a particular distribution that determines the periodicity of the data. In our case, we use the Zipf's distribution [KNU81] which means the nth most common item in a data set occurs with a frequency inversely proportional to n. We use this methodology because studies [NIE97] have shown that users access patterns in life follow the Zipf's distribution, such as the check-out pattern of library books, web page access, and so on. Thus, for our experiments, a small subset of the data is being disseminated very frequently when compared to the rest of the data.
Data from the sender are intercepted by a tap agent which is the interface between the live network and the ns [NS98] network simulator. ns serves as a emulation engine which intercepts live network traffic and manipulates them as if they are going through a real network topology. In our experiments, we set up the topology to model a sender on a high bandwidth low latency wired network, and multiple receivers on a low bandwidth high latency wireless network. We model the wireless link as a metricom modem, thus the bandwidth of 20kb/s and latency of 400 ms. To make the topology more realistic, and to stress the performance of the Knob protocol, we also introduce an error model into the emulation that drop packets based on a specified probability.
There are three performance criteria we looked at in the experiments: goodput, which is measured in terms of ratio between original data bytes and the total bytes transmitted by both the sender and receivers, tells us how well Knob is at reducing network bandwidth usage; bytes sent, which is measured both at the sender's and receiver's side, tells us whether Knob can be used at decreasing power consumption; and average latency, which is the time it takes for updates to reach receivers, lets us know how much Knob increases the wait time incurred at the receivers.
For each of the criteria, we looked at four parameters in the experiments. First, we varied receivers' interests in the data, which is the average percentage of data each receiver is interested in, from 10% to 90%. For example, a dissemination service can be sending out 100 different types of data, in which a receiver is only interested in N%. We generated the receivers' interests so that they collectively follow a Zipf distribution. Second, we varied receivers' thresholds in the data, which is the average amount of staleness a receiver can withstand, from 2 seconds to 30 seconds. Third, we varied the loss probability of packets, from 0.1% to 1%. We also varied the session size, which means the number of receivers plus the one sender, from 2 to 10. It is more interesting if we could scale this parameter larger number, however, the unstableness of ns prevented us from increasing the session size to more than 10.
In the experiments, we compare the Knob protocol with ARQ-based reliable multicast protocol SRM. This implementation of SRM guarantee eventual delivery of all data. In order words, it repairs all data losses ever detected by the receiver.
Figure 4 shows a summary of the parameters used in the emulation. The bold numbers in the variable parameters section denote the ones used in the experiments which those parameters were not varied.
Figure 4 Summary of parameters in emulation.
This section details the results of the experiments.
Figure 5 Results of goodput measurements
Figure 5 shows the results in terms of goodput. The y-axis shows the goodput as a ratio from 0 to 1. The x-axis of each graph represents the four parameters we mentioned in the previous section. As we stressed each each of the parameter, the goodput of Knob are always better than ARQ for an average of about 20%.
Figure 6 Results of bytes sent measurements (sender)
Figure 6 shows the results in terms of bytes sent from the sender. For each parameter, Knob reduces the amount of bytes sent from the sender by about 50KB. This is mainly because of Knob reduces the chances a sender would need to do retransmissions on lost data. In terms of power consumption, this is an useful result when the sender is a sensor-type device which most often runs on a battery and could take advantage of power conserving mechanisms.
Figure 7 Results of bytes sent measurements (receiver)
Figure 7 shows the results in terms of bytes sent from the receiver. We can also see that Knob decreases the amount of bytes sent from the receiver. However, the effect in this case is not as useful when compared to the sender's case, because the reduction is on the order of hundreds of bytes, not kilobytes. We learned that from [STE95] sending packets costs more than receiving only when the NI is sending large amounts of data.
Figure 8 Results of latency measurements
Figure 8 shows the results in terms of average latency seen by the receivers. The results here are rather inconclusive. We expected that Knob would increase the delay seen by receivers. However, as we can see from the graphs, sometimes Knob performs better than ARQ. Also, the delay are "spikey" at certain places which do not conform to intuition. For example, we would expect to see the average latency to increase with loss probability. But it is not the case from these results. We suspect that this has something to do with the amount of time we ran the experiments, and we might see more logical results if we re-run the emulation with a longer duration. In general, this also applies to the other experiments.
We plan to implement the sender-based algorithm as an extension to SRMv2 and measure its behavior in an emulation experiment. The current algorithm uses heuristics to determine the type of transmission mechanism to use. As we get results from the experiments, we expect to be able to fine-tune the algorithm accordingly.
The experiments in this project uses a data generator driven by a distribution to create data in the dissemination. Although this is a simple approach for the study, using a real data set can yield more interesting results, and further prove or disprove our thinking. Thus, we plan to do a measurement study on a real information dissemination application such as PointCast or Stockedge. In this way, we can gain more understanding on application and data characteristics that already have a firm consumer based in the Internet community.
In this paper, we present the motivation for a tunable quasi-reliable information dissemination protocol. We describe Knob which is such a protocol and its receiver- and sender-based algorithms. Then, we talk about the methodology we used to study the behavior and performance of Knob. The results show that Knob provides better goodput when compared to a traditional ARQ mechanism. Also, Knob reduces the amount of bytes sent by the sender and receiver. However, the measurements to determine average latency to receive updated data is inconclusive. We suspect this is due to the methodology of our experiments instead of Knob. For future work, we plan to re-run the emulations for a longer duration in order to get more dependable results.
Acknowledgments We thank Professor Joseph, Professor Katz, and Professor Badrinath for their invaluable comments on this project.
Bibliography
[AMI97] Amir, E., McCanne, S., and Katz, R. Receiver-driven Bandwidth Adaptation for Light-weight Sessions. In Proceedings of ACM Multimedia, Seattle, WA, Nov 1997.
[CLA90] Clark, D., and Tennenhouse, D. Architectural Considerations for a New Generation of Protocols. In Proceedings of SIGCOMM '90, Philadelphia, PA, Sept 1990.
[DEE91] Deering, S.E. Multicast Routing in a Datagram Internetwork. PhD thesis, Stanford University, Dec 1991.
[DIR98] DirecPC. http://www.hughes.com/
[FLO95] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and Zhang, L. A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. In Proceedings of SIGCOMM '95, Boston, MA, Sept 1995.
[HAN96] Handley, M. SAP: Session Announcement Protocol. Internet Draft, Nov 19 1996.
[HOL95] Holbrook, H., Singhal, S., and Cheriton, D. Log-Based Receiver-Reliable Multicast for Distributed Interactive Simulation. In Proceedings of SIGCOMM '95, Boston, MA, Sept 1995.
[KNU81] Knuth, D. The Art of Computer Programming, volume 3. Addison-Wesley, Reading MA, 2nd edition, 1981.
[LEV96] Levine, B., Lavo, D.B., and Garcia-Luna-Aceves, J.J. The Case for Concurrent Reliable Multicasting Using Shared Ack Trees. In Proceedings for ACM Multimedia, Boston, MA, Nov 1996.
[LIN96] Lin, J.C., and Paul, S. RMTP: A Reliable Multicast Transport Protocol. In Proceedings IEEE Infocom '96, San Francisco, CA Mar 1996.
[NIE97] Nielson, J. Zipf Curves and Website Popularity. http://www.useit.com/alertbox/zipf.html. useit.com Apr 1997.
[NW98] UCB/LBNL/VINT Network Simulator - ns (version 2). http://www-mash/ns/ns.html
[RAM98] Raman, S., and McCanne, S. Scalable Data Naming for Application Level Framing in Reliable Multicast. Accepted to ACM Multimedia, Bristol, England, Nov, 1998.
[SCH96] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. RTP: A Transport Protocol for Real-Time Applications. Internet Engineering Task Force, Audio-Video Transport Working Group, Nov, 1996.
[STE95] Stemm, M., and Katz, R. Measuring and Reducing Energy Consumption of Network Interfaces in Hand-Held devices. IEICE (Institute of Electronics, Information and Communication Engineers) Transactions on Communications, special Issue on Mobile Computing.