Category:2011-O&C - Revision history

Hadi sajjadpour: Added new lines between numbers ( result of copy pasting from the PDF)

2011-04-13T06:11:31Z

Added new lines between numbers ( result of copy pasting from the PDF)

Ajluczak: /* Contract Template */

2011-04-13T04:56:22Z

Contract Template

← Older revision		Revision as of 04:56, 13 April 2011
Line 124:		Line 124:
	Groth et al. provide an excellent template for a contract, in the form of a contract schema:		Groth et al. provide an excellent template for a contract, in the form of a contract schema:

	~~ANDREW TABLE 1 GOES HERE!!!~~		[[File:OC-2011_Table1.png]]

	We recognize that this template is simplistic in nature, but it provides an adequate basis for		We recognize that this template is simplistic in nature, but it provides an adequate basis for

Ajluczak: /* QUORUM Reputation */

2011-04-13T04:55:25Z

QUORUM Reputation

← Older revision		Revision as of 04:55, 13 April 2011
Line 194:		Line 194:
	The QUORUM observers report back on a contract in one of three ways:		The QUORUM observers report back on a contract in one of three ways:

	~~ANDREW TABLE 2 GOES HERE!!~~		[[File:OC-2011_Table2.png]]

	The reputation system tracks, for each contracting system on the network, a reputation		The reputation system tracks, for each contracting system on the network, a reputation

Hadi sajjadpour at 00:52, 13 April 2011

2011-04-13T00:52:05Z

Show changes

Hadi sajjadpour at 00:45, 13 April 2011

2011-04-13T00:45:01Z

← Older revision		Revision as of 00:45, 13 April 2011
Line 117:		Line 117:
	detailed below.		detailed below.

	[[File:Contract_timeline..png~~\|600px\|thumb\|center\|Figure 1- A Typical Contract Negotiation~~]]		[[File:Contract_timeline.png]]

Hadi sajjadpour at 00:44, 13 April 2011

2011-04-13T00:44:14Z

← Older revision		Revision as of 00:44, 13 April 2011
Line 117:		Line 117:
	detailed below.		detailed below.

	[[File:~~contractForm~~.png\|600px\|thumb\|center\|Figure 1- A Typical Contract Negotiation]]		[[File:Contract_timeline..png\|600px\|thumb\|center\|Figure 1- A Typical Contract Negotiation]]

Hadi sajjadpour at 00:42, 13 April 2011

2011-04-13T00:42:54Z

← Older revision		Revision as of 00:42, 13 April 2011
Line 1:		Line 1:
	Please note that the majority of our efforts are contained on the "Discussion" page.		Please note that the majority of our efforts are contained on the "Discussion" page.
	* [[DistOS-2011W Contracts and Observability Old First Page\|Old First Page]]		* [[DistOS-2011W Contracts and Observability Old First 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.

			[[File:contractForm.png\|600px\|thumb\|center\|Figure 1- A Typical Contract Negotiation]]

Hadi sajjadpour: Replaced content with "Please note that the majority of our efforts are contained on the "Discussion" page. * Old First Page"

2011-04-13T00:34:42Z

Replaced content with "Please note that the majority of our efforts are contained on the "Discussion" page. * Old First Page"

← Older revision		Revision as of 00:34, 13 April 2011
Line 1:		Line 1:
	Please note that the majority of our efforts are contained on the "Discussion" page.		Please note that the majority of our efforts are contained on the "Discussion" page.
			* [[DistOS-2011W Contracts and Observability Old First Page\|Old First Page]]


	==**Changes to be viewed (delete once acknowledged by group)**==
	(TK) - I have provided a summary of key concepts that will help with the idea of resource allocation across the network under the summary for '''Heuristics for Enforcing Service Level Agreements in a Public Computing Utility''' ''(<--Scott can you link this directly to the summary...I have no idea how to)'' We can go more in depth with the concepts that catch your eyes. The paper is beautifully written and easy to understand

	~~==Problem Outline==~~

	* How do we define 'public' action? How do we monitor 'public' action without monitoring every action?
	* How can you make sure your agent is acting according to your instructions?
	* How can we ensure that information we receive through a third-party is legitimate?
	* How do I observe the acts of other agents, particularly public acts?
	* What '''CAN''' be observed?
	* How can contracts be made between computers/agents?
	* How can we ensure that contracts are being upheld?
	* What side effects does observance have? For example if everyone can see who buys something online, would that promote or demote using such website?

	~~==Report Outline==~~

	[~~https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B0GW1IZG3sfgZjI3YmM4NDAtNWE0Ny00YWUyLTgxMTctZWRiYzA3YjdmMzk4&hl=en Final Group Project Report]~~

	[~~https://docs.google.com/present/view?id=dc5r38d8_2hfmsggfx&interval=60 Group presentation]~~

	*Abstract
	*Introduction
	**Observability on a Network
	*Automatic Contracts (System-~~to-System)~~
	**What Can be Contracted?
	**Determining When to Initiate a Contract
	**States of a Contract
	*Quantifiable Uniform Observation and Reporting of Unmanned Mediation (QUORUM)
	**System Overview
	***Roles in the QUORUM
	***Gossip and Reputation
	****QUORUM Cliques
	***Validating a Contract, or How I Learned to Stop Worrying and Love the QUORUM
	****Private Contracts
	*Alternatives/Other Approaches to QUORUM
	*The Future of QUORUM
	*Conclusion

	~~==Focus==~~

	As we've discussed these topics we've decided that the focus of our report will be on Contracts and ~~the Observation of their fulfillment. We are also under the assumption that participants are uniquely and universally identifiable.~~

	~~==Members==~~
	* Seyyed Hadi Sajjadpour
	* Tarjit Komal
	* Scott Lyons
	* Andrew Luczak

Hadi sajjadpour: /* Report Outline */

2011-04-11T21:19:37Z

Report Outline

← Older revision		Revision as of 21:19, 11 April 2011
Line 20:		Line 20:

	[https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B0GW1IZG3sfgZjI3YmM4NDAtNWE0Ny00YWUyLTgxMTctZWRiYzA3YjdmMzk4&hl=en Final Group Project Report]		[https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B0GW1IZG3sfgZjI3YmM4NDAtNWE0Ny00YWUyLTgxMTctZWRiYzA3YjdmMzk4&hl=en Final Group Project Report]

	[https://docs.google.com/present/view?id=dc5r38d8_2hfmsggfx&interval=60 Group presentation]		[https://docs.google.com/present/view?id=dc5r38d8_2hfmsggfx&interval=60 Group presentation]

Hadi sajjadpour: /* Report Outline */

2011-04-11T21:19:27Z

Report Outline

← Older revision		Revision as of 21:19, 11 April 2011
Line 19:		Line 19:
	==Report Outline==		==Report Outline==

			[https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B0GW1IZG3sfgZjI3YmM4NDAtNWE0Ny00YWUyLTgxMTctZWRiYzA3YjdmMzk4&hl=en Final Group Project Report]
	[https://docs.google.com/present/view?id=dc5r38d8_2hfmsggfx&interval=60 Group presentation]		[https://docs.google.com/present/view?id=dc5r38d8_2hfmsggfx&interval=60 Group presentation]

← Older revision		Revision as of 06:11, 13 April 2011
Line 35:		Line 35:
	1) All participants in a contract (i.e. the client and the provider), are automated systems		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).		(either a single machine, or a group of machines).

	2) All machines have a unique universal identifier which is un-spoofable.		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		3) Any conduct violations arising from a violation of contract parameters can be handled
	with perfect efficiency and judicial accuracy.		with perfect efficiency and judicial accuracy.

	4) Machines have no mobility, in either a physical or network context.		4) Machines have no mobility, in either a physical or network context.

Line 93:		Line 96:

	1) Peer (Node) Selection: Selecting a few random nodes in the network.		1) Peer (Node) Selection: Selecting a few random nodes in the network.

	2) Data Exchanged: Selecting what information to send to the selected nodes.		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		3) Data Processing: Once data has been received via gossiping, process that data and
	decide what action to take.		decide what action to take.
Line 137:		Line 142:

	1) The Client issues a Request For Proposal (RFP)		1) The Client issues a Request For Proposal (RFP)

	2) A Provider replies to Client with RFP		2) A Provider replies to Client with RFP

	3) Both parties agree to terms		3) Both parties agree to terms

Line 154:		Line 161:

	1) Contract agreement proceeds as above		1) Contract agreement proceeds as above

	2) Once the contract has been ratified by the Client and Provider, each provides a copy of		2) Once the contract has been ratified by the Client and Provider, each provides a copy of
	the contract template to its neighbors		the contract template to its neighbors

	3) Each neighbor signs the contract as a witness, and propagates the contract across the		3) Each neighbor signs the contract as a witness, and propagates the contract across the
	network as a whole.		network as a whole.