CS 519 Final Project Report

Internet Phone

Date: Dec. 17, 98

Name of Group : G1

Team members: Jing Deng, Rung-Hung Gau

Task: Accounting (#5)

Our team is one of ten teams in a big group in which there are totally twenty students. The goal of the group is to build software infrastructure and applications for Internet Phone. Our team is composed of two students whose tasks range from writing software for billing and accounting purposes to research on Internet pricing policy.

The first part of our work is to write Java codes to support billing and accounting for Internet Phone. Although the usage of Internet backbone is current free, we believe that charges for Internet usage will become popular in the near future. While other teams in our group cooperate to allow people use Internet to make a phone call, we are responsible for keeping track of Internet usage of users and charging them according to our pricing policy. Whenever signaling server informs our program that a call is initiated, our program contacts the directory service server to obtain the identity of users associated with the call and then stores relevant information in our database. On the other hand, our program calculates the duration and due amount for the call when the signaling server notifies us a specific call is terminated. Technologies that we use include Access and Java. We choose the popular Access to be our database to store information about Internet usage of users. We use Java as our programming language and benefit from many advanced features of Java, such as JDBC, RMI, and Security. JDBC is a Java interface, which gives programmers potentials to control database. To actually control Access by Java, we need to set up the JDBC/ODBC Bridge that comes with Windows 95/NT. Since we have many teams in our group, we need a common programming interface so that codes from different teams can cooperate smoothly and easily. We prefer RMI to sockets mainly due to it is easier to program using RMI. To protect customers and to avoid disputations, we need to authenticate important messages, especially those related to charges, before we write them into our database. We use the Digital Signature Algorithm provided by Java security package to authenticate messages.

The second part of our task is to do research on Internet pricing policy. A lot of important questions have to be answered before companies can charge customers for their Internet usage. This is an active research area and we find some helpful papers [6] [7] [8] [9] [10] in this arena. MacKie-Mason and Varian [5] provide answers to many FAQ for people who are interested but not familiar with Internet pricing. They [6] also propose a new scheme, called smart market, to perform Internet pricing. The concept of smart market is very interesting and promising from economic point of view but has some technical difficulties for implementation. We borrow some ideas from smart market and propose a new scheme that is more feasible and economically efficient. We achieve this mainly by integrating resource reservation and usage-based pricing.

We divide our project into four components, database, interface to other teams, security, billing, and pricing. We choose MS-Access in Windows 95/NT as our database and use the JDBC/ODBC Bridge so that we can use our Java codes to manipulate the database. When we handed in report 2, our Java codes could perform various database operations, such as query, read and write, using SQL.

We next moved to implement the interface to other teams. We had a group meeting just after handing in report 2 and decided to use RMI to provide interfaces to other teams. Our program has to interact with programs of signaling team and directory team. We currently assume all calls can be classified into four categories. A call can be made from a phone to a phone or host. It can also be made from a host to a phone or host. We provide four corresponding classes in the package InternetPhoneEntry to maintain information about an Internet Phone call. We need signaling team to inform us whenever a call is initiated or terminated. We show the interfaces to signaling team in a Java interface, Accounting, and a Java class, AccountingImpl, which actually implements the above interface. We have two more Java classes to demonstrate our program. The class AccountingServer provides an RMI interface to the AccountingClient class, which mimics a simplified version of codes of signaling team. The AccountingClient class can obtain a stub from the AccountingServer and can perform remote method invoke to update our database.

In order to obtain the identity of a customer, our program has to call program of directory team. We basically need two types of services from directory team. We like to know the identity of a customer, a caller or callee, given a phone number or a socket address. We also write a simplified program for directory service, named DirectoryServer, based on the codes provided by directory team. We test our program by running three classes, AccountingClient, AccountingServer, and DirectoryServer. First, the AccountingClient invokes a remote method, InformAccountingCallInit, in AccountingServer when a call is initiated. The method InformAccountingCallInit in turn invokes a remote method, GetNameByAddress, in DirectoryServer, to obtain the identity of a customer and updates the database accordingly. The AccountingClient also calls the AccountingServer when the above call is terminated. Then, the AccoutingServer runs a billing algorithm and updates the database.

After finishing the RMI stuff, we work on security issues. We focus on authentication due to the nature of our project. We adopt DSA, Digital Signature Algorithm, in Java to discern the signaling team and to make sure that the message is not distorted. DSA uses public keys and private keys to verify a user and is very similar to the well-known RSA algorithm. We create three object classes that are required for DSA and put them in a package, called DSAInstance. The security package of Java provides three relevant interfaces for DSA, DSAParams, DSAPublicKey, and DSAPrivateKey. We want to store public keys and private keys in files so that we can distribute them. However, we can not directly save these keys. We figure out that this is due to that DSAPublicKey and DSAPrivateKey are only Java interfaces instead of Java classes. We create three classes corresponding to three interfaces mentioned above. Since both interface DSAPublicKey and DSAPrivateKey are serializable, we are able to save keys in files using object streams in Java.

We also create a class, AuthenticationByDSA, to allow other teams apply DSA easily. The class provides several methods so that programmer can get a private key or public key from a file. The class also allows a programmer get a digital signature and verify a digital signature easily by two class methods. We design another class, DSAKeysGenerator, to generate several private keys and public keys and to save these keys in files. We use a class, SignatureTest2, to test our programs. The testing program first reads a private key from a file and uses the private key to sign a message. Then, it reads public keys from files and tries to verify the signature. Our testing program uses private key 5 to create a digital signature and it is able to show that the message is indeed signed by private key 5 instead of any other private keys. This justifies the correctness of our program.

We decide to adopt a two-phase billing algorithm for its flexibility. In the first phase, we calculate the charge for each call when a call is terminated and write the charge in the database. In the second phase, we decide who should pay how much for a call according to our policy. For example, we can calculate the cost for a multi-party conference in the first phase while leaving the amount each participant should pay undetermined. In the second phase, corresponding to the bill creation date, we calculate the due amount for each participant. This scheme is flexible since the service provider only decides the charge for an Internet Phone call, for example a multi-party conference. Participants of a call can decide how to share the charge and inform the service provider. Currently, we decide to use the popular scheme in which the caller pays all the charge in order to test our program. The cost is 9 cents per minute 24 hours a day, 7 days a week. We choose the rate to be a little below the regular long distance call in order to compete with long distance phone companies.

We find some papers [5] [6] [7] [8] [9] [10] about pricing the Internet. MacKei-Mason and Varian [5] provide answers to some frequently asked questions about Internet pricing. They argue that usage-based pricing is necessary for congestion control in Internet and propose "smart market" to implement usage-based pricing in their paper [6]. P. Jones [7] concludes that the problem of sharing network resources in Internet is still not well understood. Mills, Hirsh and Ruth [8] discuss architecture for Internet accounting. Instead of focusing on economic issues, they concentrate on technical aspects of Internet accounting. Gupta, Stahl and Whinston [9] use simulations to show that pricing can improve Internet efficiency compared to free-access policy.

MacKie and Varian claim that pricing in Internet is necessary according to the following reasons. First, the traffic of Internet can be expected to grow steadily and quickly based on past statistics and network congestion can not be avoided without introducing new control and management mechanisms in Internet. Many priority-based mechanisms have been proposed to achieve efficient utilization of network resources during congestion period. However, those priority-based mechanisms require cooperation among all users and users who do not cooperate tend to benefit. They argue that priority-based mechanism can not work without using pricing to enforce cooperation. Once pricing is adopted, priority can be based on the money a user is willing to pay. Therefore, we do not need a centralized scheme to set priority for each packet. They suggest using "smart market" to perform per packet pricing.

Although their idea looks attractive and promising from economic point of view, we think some technical issues have to be resolved before "smart market" can be implemented. First, we think the overhead to perform per packet pricing tends to be very high. We expect the throughput of network to decrease significantly due to the huge amount of packets. They propose sampling method to reduce the overhead. However, we doubt that a sampling method is reasonable in a connectionless network. Second, we do not think that per packet quality is sufficient for all applications. It is clear that some applications, such as voice and video, require constant quality of service. Giving higher priority to a packet does not ensure that all packets from an application will be given higher priority since network is dynamic. In smart market, the price is relative, not absolute. A voice application may be interrupted because some users are willing to pay more in the near future. They admit that their pricing mechanism does not ensure absolute quality of service. We conclude that the pricing mechanism must be complemented by some reservation mechanism to provide absolute quality of service.

Another technical issue of the "smart market" is how and who should know a packet is successfully delivered in order to charge a user. In smart market, a bid value is set in each packet. Each user, whose packet is admitted, pays the amount equal to the bid of the rejected packet with highest bid. This implies that we need divide time into slots to compare bids to perform admission control. It also implies we need centralized control to compare bids of packets from scattered networks. Without resource reservation, a packet is not guaranteed to be delivered successfully even it has been admitted. This is frustrating since a user who pays only gets a higher chance, instead of a warranty, to deliver his/her packets. On the other hand, we need much more overhead if we charge a user only a packet is delivered successfully since we have to trace each packet.

Based on previous arguments, we can infer that resource reservation is necessary to support an efficient Internet pricing policy. We design an algorithm, P-RSVP (Pricing-based ReSerVation Protocol), which integrates resource reservation and usage-based pricing. In P-RSVP, we classify applications into three types: best effort applications, constant bit rate applications, and variable bit rate applications. The classification is mainly based on the network resources reserved for each application instead of the source traffic pattern. We do not charge a best effort application since we do not reserve network resources or provide any guarantee of quality of service for a best effort application. We treat an application as a best effort application if it is sufficient to deliver packets without any resource reservation. For example, a specific voice call can be regarded as a best effort application if a customer is willing to take chance without paying any money for resource reservation. The voice call may be dropped if another customer is willing to pay to grasp the network resource the voice call is holding. We view an application as a constant bit rate application if we have to reserve constant bandwidth for the application. On the other hand, we regard an application as a variable bit rate application if we can reserve time-variant, but deterministic, bandwidth during the active period of the application.

There are two options for charging a constant bit rate or variable bit rate application. A network service provider can decide in advance the price for each type of bandwidth reservation, A customer decides if he/she is willing to accept the offers from the service provider. This scheme imposes the burden of pricing on service providers. Since customers may have various demands, to satisfy all customers by price listing is very likely to be a complicated, if not impossible, task. The dynamic feature of the network can only make the task harder. We borrow the idea of "smart market" and propose a new pricing scheme. Instead of competing for network resource for each packet, our scheme allows applications to compete only during initialization period. A customer specifies the amount he/she is willing to pay for an application, called bid price, and the requirement of network resource for an application, which includes total required bandwidth obtained by integral bandwidth requirement over time. We define the normalized bid price for an application to be the bid price divided by the total required bandwidth. Applications with various normalized bid prices compete for network resources according to "smart market".

We take several concerns about P-RSVP into consideration. The first concern is if we have covered all possible applications in P-RSVP. In P-RSVP, we reserve time-variant, but deterministic, bandwidth for a variable bit rate application. Clearly, not all applications have deterministic source traffic pattern. We borrow this idea from MPEG, which is a popular standard for video conference. In MPEG, the source usually sends only the difference between the current frame and the previous frame to reduce the amount of network traffic. However, the source also periodically sends a complete frame to avoid error propagation. Therefore, we can treat the amount of network traffic for each MPEG application as a regenerative process [11] under some mild assumptions. The stochastic process regenerates itself whenever the source sends a complete frame, which is called stopping time. P-RSVP can benefit from the fact that the stopping times are deterministic. We can reserve bandwidth for a complete frame periodically and reserve less, but constant, bandwidth during other time. A customer does not lose complete frames and can predict the quality of service from regenerative theory while a service provider can reserve deterministic bandwidth and charge customers according to the corresponding reserved bandwidth. For other source traffic patterns without regenerative property, we can treat it as a constant bit rate application with rate equivalent to peak rate or average rate of the original source traffic and reserve constant bandwidth for the application.

Our second concern is if P-RSVP still keeps the economic optimality that "smart market" promises. "Smart market" reaches economic optimality only for per packet basis and assumes that packets are all independent. Therefore, their definition of optimality is not suitable for our situation. Nevertheless, we think P-RSVP is economically efficient especially in the case that applications require only one point-to-point link. In that case, P-RSVP is as efficient as any other scheme without knowledge about the future because we adopt "smart market" to allocate network resources. People may claim one customer will have unfair privilege if he/she has some knowledge about the future usage of the network. For example, a customer can benefit by starting an long application five minutes before busy period in which a lot of customers will compete for network resources and the price will tend to be much higher. We believe this is very unlikely to happen because that other customers can apply exactly the same strategy if they share the same information and eventually nobody wins. An unfair situation occurs only when a customer has some private information, which is unlikely to happen and no markets can deal with it if it happens.

We claim that P-RSVP is economically efficient when each application requires only one point-to-point link based on previous arguments. Due to the rapid drop of cost of optical fiber, we believe that the Internet backbone is apt to evolve into a fully connected network as core of telephone networks. Even before the scenario happens, P-RSVP is still applicable to current Internet. Note that P-RSVP requires only bid price and total required bandwidth to run "smart market" algorithm. Therefore, P-RSVP is a sub-optimal solution when applications require two or more links. However, P-RSVP is much easier to implement than a scheme that tries to find a global optimal solution especially in a dynamic network.

Our goals of designing P-RSVP are to take advantage of "smart market" and to avoid implementation overhead of it. Instead of enforcing each packet competing network resources in "smart market", P-RSVP allows applications competing network resources during initialization period. Unlike in "smart market", P-RSVP allows an application keep allocated network resources till the application terminates. In P-RSVP, a customer knows the quality of service he/she pays for and a service provider does not have to trace packets of applications. P-RSVP is economically efficient due to adoption of "smart market".

This is the first project-oriented course that we take in Cornell. We learned Java programming and how to cooperate with other software developers. We also have a chance to read some papers from economists, which are very different from the papers from engineers in style and viewpoint. We enjoy the experience of dealing with a problem from engineering and economic point of view.

First, we had a chance to learn Java. Before this course, we only had experience about C/C++. We felt that Java programming is very similar to C++ programming in many aspects. Nevertheless, we did something that we never did using other programming languages. We learned JDBC, which is really fantastic to us. It was the first time we felt that Java is so powerful and exceptional. Probably it was due to the fact that we did not have any experience in database programming before. However, we were really impressed by that Java could provide a universal access method to various databases. We also learned how to improve performance of database access by avoiding preparing the same SQL statement many times. We learned how to make a method atomic to assure the correctness of database operations when several threads try to write the same record in a database.

We also learned socket programming in Java although we did not use sockets in our program eventually. Instead, we use RMI for communication among codes from various teams. Besides, we learned how to support security in Java, especially authentication. It took us less than an hour to create a public key and private key, to obtain a digital signature using a private key, and to verify a digital signature using a public key. However, we could not save these keys in a file in the beginning although both a private key and a public key are serializable in Java. We solved the problem by noticing that a private key, DSAPrivateKey in Java security package, is a Java Interface instead of a Java Class. In order to save a private key in a file, we had to create a Java object class, which implements the Java interface. Then, we could write and read keys from files through object streams of Java.

In the planning phase of this project, we encountered a situation in which some group members seem to persuade us to adopt their favorite operating system and database without convincing reasons. This is a common problem of course projects in which there are no arbiters. Working out a solution that pleases everyone is almost impossible. Instead of being a blind supporter or enemy of a company, we should learn to meditate independently and consider each case separately. We can try to persuade others but we should be careful not to enforce people to accept our own opinions.

We also had some difficulties in coordinating our works with others and they are sometimes more serious than our own technical problems. When we were ahead of other teams, we did not have programs from other teams to test our programs. Consequently, we had to write a simplified version of their programs for our testing. We guessed this situation also happened in industry and we should reach agreements in interfaces as early as possible and designed some testing programs so that the team in trouble will not stop the progress of other teams. Of course, we should try to avoid becoming the team causing troubles.

I n the end of the semester, we encountered a strange problem when we tried to integrate our codes with codes from other teams. Codes from directory team and signaling team ran in Linux or Unix while our accounting server ran in Windows 95/NT. Everything worked well when we ran our program in a Windows 95 machine in EE department. However, the signaling program could not invoke a remote method provided by us when we ran our server program in a Windows NT machine in CS undergraduate lab or System lab. Then, we ran our program in Windows 95/NT in the dedicated machine of another group of cs519 and our program worked. We guessed it is due to access control of machines in those two labs.

We will try to get familiar with essential technologies before we start our projects. We did not have any experience in Java programming before this semester although one of us had some experience in C++. We learned Java while doing our project. For students, this methodology may be acceptable although we got frustrated and wondered if we could finish our project before due date several times. However, we would like to make sure that our team members have enough skills for a project if we were project leaders in industry in the future. We would try to minimize the risk of a project although we understand that this situation may not always be avoided.

In the beginning of this semester, some of our group members tried to convince us to substitute Window NT and Access by Linux and some free database since we were the only team, which claimed to use Windows NT. Eventually, almost all application teams have to use Window NT and some teams that assume that only our team will use NT have to write codes in a rush. It does not prove that some operating system is ubiquitous. It just tells us that the planning phase is very important and deserves more time than most people expect.

We provide two methods to signaling team as the following. The first line provides the RMI interface to signaling team. The signaling team calls the method in line 2 when a call is initiated. The signaling team calls the method in line 3 when a call is terminated. Both of the above methods are overloaded. The object passed through this method can be another type of object depending on the type of an Internet Phone call. We attach a class, AccountingClient, to show the procedures.

We need two methods from the directory team. The first line gets the RMI service from directory team. We can get the identity of a customer with a hostname by using the method in line 2. We can get the identity of a customer with a phone number by method in line 3. We can get the identity of a customer with a socket address by method in line 4.

We have learned a lot from the project although it is exhausting. We suggest that you should design similar project next year. Probably, you can reduce the total number of puzzles to give students more time to finish their project.

[1] Barry Holmes, "Programming with JAVA", Jones and Bartlett Publishers.

[2] Cay S. Horstmann, Gary Cornell, "Core Java 1.1 Volumn II- Advanced Features", Sun Microsystems Press, A Prentice Hall Title.

[3] W. Richard Stevens, "Unix Network Programming", Prentice Hall PTR.

[4] http://www.sun.com/java

[5] Jeffrey K. MacKie-Mason and Hal R. Varian, "Some FAQs about Usage-Based Pricing", University of Michigan, September 1994.

[6] Jeffrey K. MacKie-Mason and Hal R. Varian, "Pricing the Internet", University of Michigan, February 1994.

[7] P. Jones, "RFC 1346: Resource Allocation, Control, and Accounting for the Use of Network Resources", June 1992.

[8] C. Mills, D. Hirsh, G. Ruth, "RFC 1272: Internet Accounting: Background", November 1991.

[9] Alok Gupta, Dale O. Stahl, and Andrew B. Whinston, "Pricing of Services on the Internet", University of Texas at Austin.

[10] Alok Gupta, Dale O. Stahl, and Andrew B. Whinston, " An Economic Approach to Networked Computing with Priority Classes", University of Texas at Austin.

[11] Erhan Cinlar, "Introduction to Stochastic Processes, Chapter 9: Renewal Theory", Prentice Hall.