Please note that the majority of our efforts are contained on the "Discussion" page.

• Old First Page

This report was done by Tarjit Komal, Andrew Luczak, Scott Lyons and Seyyed Sajjadpour.

Introduction

This paper is an overview of a theoretical implementation of electronic contract negotiation systems. We begin by exploring the previous work in the field of electronic contract resolution, and we then outline the framework for QUORUM, a proposed system of electronic contract negotiation and mediation with an integrated reputation system.

Focus Of Study

The primary goal of this report is to provide some mechanism for a reliable and automated contract negotiation framework, which system will ideally be functional over a distributed system. As a secondary goal, we discuss a mechanism for observing these contracts; such a mechanism is critical for determining when a contract has been properly fulfilled, which we show is a requirement for the repeatable success of a contract negotiation system.

Background

Automated Contracts

We define an automated contract as any contract between computer systems requiring a minimum of human intervention. Some human effort may be required to define the guidelines by which the system negotiates (i.e. contract with a reliable system with longer wait times as opposed to a less-reliable system with shorter wait times), but the system should be able operate autonomously for the entire contract period.

Assumptions

In order to simplify the problem at hand, we make the following assumptions:

1) All participants in a contract (i.e. the client and the provider), are automated systems (either a single machine, or a group of machines). 2) All machines have a unique universal identifier which is un-spoofable. 3) Any conduct violations arising from a violation of contract parameters can be handled with perfect efficiency and judicial accuracy. 4) Machines have no mobility, in either a physical or network context.

We make these assumptions recognizing that the current implementation of the Internet and other large systems make such a situation impossible (particularly the second assumption wherein identifiers are un-spoofable and universal.

Related Work & Project Basis

The field of electronic contracts has been approached in several different ways, with papers describing several avenues of research; however, no paper we discovered provided a complete system of electronic contract negotiation and validation. Based on what we’ve found in research literature, Service Level Agreements (SLA) are the closest to our proposed system, and were the basis for our framework.

Using the groundwork laid by the following research groups, we look at the problem at a higher level, and focus on an arbitrary network (i.e. a WAN or LAN) that sees computers as citizens. Citizens of this network will get the chance to observe contracts and act as witnesses for other citizens. We will show how SLA-style contract parameters can be used as the benchmarks of a contract verification system, how a reputation system can increase the overall reliability of the contract system, and how a gossiping system can provide an effective propagation of system capabilities.

SLA

Verma, in his paper [1], defines SLA to be “…a formal relationship that exists between a service provider and its customer”. He also mentions some key components of SLAs such as: “a description of the nature of service to be provided”; “the expected performance level of the service, specifically its reliability and responsiveness”; and “the procedure for reporting problems with the service”. These are authentic concerns for any electronic contract. In our system, we adapt Verma’s defined components to be used by each contracted party to verify whether a contract has been fulfilled or not. Verma also discusses various approaches to guaranteeing service, including an insurance approach and an adaptive approach, which can be used by service providers.

Reputation

Groth et al., in their research [2] on the trustworthiness of contracts, propose two key indicators of a contract’s potential reliability: the history of the contracting party, and the similarity of the contract to other successful contracts. Groth et al. also lay out an effective template for contracts (based in turn upon the IST-CONTRACT project) which we use and build upon in our QUORUM system.

Gossiping

In a large network, disseminating information through broadcast updates between everyone in the network will create bandwidth, latency and denial-of-service concerns. Hence, there needs to be some other ways to disseminate information, while avoiding the above mentioned concerns. In their paper[3], Kermarrec et al. define gossiping in distributed systems to be “…the repeated probabilistic exchange of information between two members.” In other words, gossiping is the random dissemination of information, with correct timeouts and periods (depending on the size of the network). In most cases, gossiping would include exchanging lists of information with randomly selected nodes.

In principle, most gossiping algorithms follow the framework provided by Kermarrec et al.:

1) Peer (Node) Selection: Selecting a few random nodes in the network. 2) Data Exchanged: Selecting what information to send to the selected nodes. 3) Data Processing: Once data has been received via gossiping, process that data and decide what action to take.

Gossiping is a common method of dispersing information in distributed systems, and is inspired by real life gossiping. Take, for example, the students in a university department as nodes in your network. Once a new student joins the department, he establishes a friendship with a few other students (nodes) in the department (network). Subsequently, these students may or may not inform others in the department that the new student exists, disclosing the characteristics of the

new student. This gossiping continues, and at the end of a given time period each student has some information about some of the other students in the department; it is highly unlikely that any one student has information regarding every other student in the department, but every student is known by some other student in the department.

Case Study

The simplest and most common use case is that of a website suffering from a Denial of Service attack or an unexpected traffic influx. In this example and for all future reference, ForeverAlone.com is the Client and TooMuchBandwidth.net is the Provider. Some automated process or monitor on the Client would be advised of the sudden surge in traffic and would arrange to contact the Provider to request their services. A more detailed look into the request process is detailed below.