Soma-notes - User contributions [en]

Category:2011-O&C

2011-04-13T04:56:22Z

Ajluczak: /* Contract Template */

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]]

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:Contract_timeline.png]]

= Contracts =

== Contract Template ==
Groth et al. provide an excellent template for a contract, in the form of a contract schema:

[[File:OC-2011_Table1.png]]

We recognize that this template is simplistic in nature, but it provides an adequate basis for
discussion of electronic contracts; any implementation of such a template would need a more
detailed structure and syntax. It is worth noting, however, that the IST CONTRACT group, upon
whose work Groth et al. based their template, explored the idea of structuring a contract in an XML-
style wrapper, which seems a logical progression from the above template.

== Contract Formation ==

The formation of a contract has three general steps:

1) The Client issues a Request For Proposal (RFP)
2) A Provider replies to Client with RFP
3) Both parties agree to terms

Once these three steps have been followed, the contract is set and, assuming the activating
condition is met, the normative conditions are put into force.

There exists a problem, however, in enforcing the formation of a contract: some mechanism
for verifying the origins of the contract is necessary to prevent the forging of contracts for the
purposes of self-promotion. This becomes particularly critical when a reputation system is in effect;
the ability to forge a completed contract would be an incredible advantage for a service provider

wishing to boost its reputation (a key component of the QUORUM system, which we discuss in a
later section of this paper).

We propose the following procedure for forming a contract:

1) Contract agreement proceeds as above
2) Once the contract has been ratified by the Client and Provider, each provides a copy of
the contract template to its neighbors
3) Each neighbor signs the contract as a witness, and propagates the contract across the
network as a whole.

This system will produce a group of multiple contracts, each signed by a different witness,
but all possessing the same contract identifier (since all copies share the same origin). These
contracts can later be collected into a single copy, with a list of all witnesses. Contracts can then be
verified based on the presence or absence of certain systems from the witness list. This observation
system is built upon a gossiping network protocol, which we describe in more detail later in this
paper.

== Contract Publication ==

In order to mitigate fraudulent reputation growth, the proposed witnessing mechanism
requires that the contract be propagated through the network. While only a minimum level of detail
needs to be shared in order to witness a contract, we recognize the need for a private option, where
two systems may forge a contract without any details becoming public knowledge. The QUORUM
system provides such an option, though any contract created in private cannot affect reputation; a
contract must be witnessed to affect reputation, and a contract must be published to be witnessed.

= QUORUM =

QUORUM, or Quantifiable Uniform Observation and Reporting of Unmanned Mediation, is
our proposed system for electronic contract negotiation and observation on a distributed system.
Ideally, QUORUM runs on every machine in the network, acting as a distributed cloud of
autonomous observers. In addition to the observers, QUORUM is also comprised of a reputation
system, which is built from the history of contracts on the network.

The observers of QUORUM have a single responsibility. When a contract is published, each
observer attempts to verify that the normative conditions are being or can be satisfied. Once the
expiration condition is reached, each observer reports back to reputation system according to what
they believe the final state of the contract is. These observers must operate upon some metric
which is appropriate to the contract; metrics for the observers may be a simple binary condition
(e.g. has system A provided a piece of information to system B) or a more detailed requirement.

== QUORUM Reputation ==

The QUORUM observers report back on a contract in one of three ways:

[[File:OC-2011_Table2.png]]

The reputation system tracks, for each contracting system on the network, a reputation
score based upon the published contract history of that party. Successful contracts increase
reputation score, while breached contracts decrease reputation score. Contracts that are voided by
both parties or negotiated in private (i.e. without witnesses or QUORUM observation) have a
neutral effect on reputation score (though such contracts will still appear in the contract history).
This reputation system can then be used by Clients to determine which Provider proposal to accept.

== QUORUM Gossip ==

In order to facilitate the formation of contracts, it is useful to have a regularly updated
notion of which systems have certain capabilities. For example, if a particular system is in need of
processing time, it needs to be able to quickly determine which providers can offer assistance. To
this end, QUORUM requires an inter-system communication network, and so we propose the
following gossiping system.

=== Gossiping in QUORUM ===

As QUORUM operates, there are four scenarios which involve gossiping: the entrance of a
node, the location of available services, the exchange of reputation information, and the detection of
network failure. We will address each of these separately. Various gossiping algorithms exist [4],
any of which are sufficient for the implementation of QUORUM. Given our current system, we have
derived a gossiping method that utilizes some components of existing methods, such as the
framework in [3].

Each node will have a list L of other nodes, in this list there exists the identity and known
services provided by that node. A node will update entries in L based upon the information it
receives through gossip messages.

=== Entrance ===

When a node joins a network, it will have the address of two existing nodes on the network.
After it joins the network, the two nodes will then randomly assign neighbors to the new node,
selecting them from the QUORUM via some algorithm. Depending on the size of the QUORUM, each
node will have a fixed h number of neighbors; the number of neighbors and how randomly these
neighbors are chosen is an area which needs to be investigated further.

The joining node also sends to its neighbors a list of services that it can provide. Once the
neighbouring nodes have received identified and received the services of the incoming node, they
can then use a gossiping algorithm of the QUORUM to propagate this information. In turn, the
neighbors send their lists to the joining node, making it aware of the various capabilities of the
network it has joined.

=== Search For Services ===

As we saw in the related work, it is highly unlikely (depending on the size of the QUORUM)
for a node to have knowledge of every other node in the system. A given node that is looking for a
particular service x, will first look up in his own list L (that has been updated via gossiping
messages), and if he cannot find service x with the required reputation, he will then ask around the
QUORUM to find the service he is looking for.

=== Failure Detection ===

Failure detection in distributed systems is a prominent sub-problem of distributed systems,
and has approached by several research groups (see [5-9], as referenced in [5]). Below we present
an aggregation of the above efforts, applied to the QUORUM.

Given the neighbor system of QUORUM, each neighbor can expect a gossip message from its
neighbors in a period of t seconds. If a neighbor of a node r fails to send such a message, then r will
send a heartbeat message to its neighbors (i.e. the pull model [7,8]) asking whether it is alive or not.
If r then receives a response, it knows that its neighbor is alive. If r does not receive a response
(after enough heartbeat messages to be convinced that his neighbor is dead), then it would remove
that node from the list of its neighbors, look for another neighbor, and communicate the node
failure (via gossiping messages) to the other members of the QUORUM. Given that this method
relies heavily upon the neighbors of a node, it might be prudent to implement an additional failure
detection method, such as that found in the work of Hayashibara et al.[9].

= Future Work And Conclusion =

Moving forward with QUORUM, one main objective would be to attempt an actual
implementation of the system according to our specifications. In our research we made several
assumptions, one of which was that computers are not mobile. There could be further research
done in examining and modifying our QUORUM to allow for system mobility.

= References =

[1] D.C Verma, Service Level Agreements on IP Networks, Proceedings of the IEEE, vol. 92, pp. 1382-
1388, September 2004.

[2] P. Groth, S. Miles, S. Modgil, N. Oren, M. Luck, G. Yolanda, Determining the Trustworthiness of
New Electronic Contracts, Engineering Societies in the Agents World X, 2009.

[3] A. Kermarrec, M. van Steen, Gossiping in Distributed Systems, SIGOPS Oper. Syst. Rev., 41(5):2-7,
2007.

[4] S. Boyd, A. Ghosh, B. Prabhakar, and D. Shah. “Randomized Gossip Algorithms.” IEEE
Transactions on Information Theory, 52(6):2508-2530, June 2006

[5] S. Sajjadpour, Failure Detection in Distributed Systems, Distributed Operating Systems course,
Carleton University, Winter 2011

[6] R. Van Renesse, Y. Minsky, M. Hayden, A gossip-style failure detection service. In proceeding of
the IFIP International Conference on Distributed Systems Platforms and Open Distributed
Processing, 1998. The version used here is from 2007.

[7] P. Felber, X. Defago, R. Guerraoui, and P. Oser. Failure detectors as first class objects. In
Proceedings of the International Symposium on Distributed Objects and Applications, 1999. The
version I used here is from 2002.

[8] N. Hayashibara, A. Cherif, T. Katayama, Failure Detectors for Large-Scale Distributed Systems, In
21st IEEE Symposium of Reliable Distributed Systems (SRDS’ 02). 2002

[9] N. Hayashibara, X. Defago, R. Yared, T. Katayama. The φ accrual failure detector. In Proceedings
of the 23rd IEEE International Symposium on Reliable Distributed Systems (SRDS’ 04), pages 55-
75, 2004

File:OC-2011 Table1.png

2011-04-13T04:56:11Z

Ajluczak:

Category:2011-O&C

2011-04-13T04:55:25Z

Ajluczak: /* QUORUM Reputation */

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]]

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:Contract_timeline.png]]

= Contracts =

== Contract Template ==
Groth et al. provide an excellent template for a contract, in the form of a contract schema:

ANDREW TABLE 1 GOES HERE!!!

We recognize that this template is simplistic in nature, but it provides an adequate basis for
discussion of electronic contracts; any implementation of such a template would need a more
detailed structure and syntax. It is worth noting, however, that the IST CONTRACT group, upon
whose work Groth et al. based their template, explored the idea of structuring a contract in an XML-
style wrapper, which seems a logical progression from the above template.

== Contract Formation ==

The formation of a contract has three general steps:

1) The Client issues a Request For Proposal (RFP)
2) A Provider replies to Client with RFP
3) Both parties agree to terms

Once these three steps have been followed, the contract is set and, assuming the activating
condition is met, the normative conditions are put into force.

There exists a problem, however, in enforcing the formation of a contract: some mechanism
for verifying the origins of the contract is necessary to prevent the forging of contracts for the
purposes of self-promotion. This becomes particularly critical when a reputation system is in effect;
the ability to forge a completed contract would be an incredible advantage for a service provider

wishing to boost its reputation (a key component of the QUORUM system, which we discuss in a
later section of this paper).

We propose the following procedure for forming a contract:

1) Contract agreement proceeds as above
2) Once the contract has been ratified by the Client and Provider, each provides a copy of
the contract template to its neighbors
3) Each neighbor signs the contract as a witness, and propagates the contract across the
network as a whole.

This system will produce a group of multiple contracts, each signed by a different witness,
but all possessing the same contract identifier (since all copies share the same origin). These
contracts can later be collected into a single copy, with a list of all witnesses. Contracts can then be
verified based on the presence or absence of certain systems from the witness list. This observation
system is built upon a gossiping network protocol, which we describe in more detail later in this
paper.

== Contract Publication ==

In order to mitigate fraudulent reputation growth, the proposed witnessing mechanism
requires that the contract be propagated through the network. While only a minimum level of detail
needs to be shared in order to witness a contract, we recognize the need for a private option, where
two systems may forge a contract without any details becoming public knowledge. The QUORUM
system provides such an option, though any contract created in private cannot affect reputation; a
contract must be witnessed to affect reputation, and a contract must be published to be witnessed.

= QUORUM =

QUORUM, or Quantifiable Uniform Observation and Reporting of Unmanned Mediation, is
our proposed system for electronic contract negotiation and observation on a distributed system.
Ideally, QUORUM runs on every machine in the network, acting as a distributed cloud of
autonomous observers. In addition to the observers, QUORUM is also comprised of a reputation
system, which is built from the history of contracts on the network.

The observers of QUORUM have a single responsibility. When a contract is published, each
observer attempts to verify that the normative conditions are being or can be satisfied. Once the
expiration condition is reached, each observer reports back to reputation system according to what
they believe the final state of the contract is. These observers must operate upon some metric
which is appropriate to the contract; metrics for the observers may be a simple binary condition
(e.g. has system A provided a piece of information to system B) or a more detailed requirement.

== QUORUM Reputation ==

The QUORUM observers report back on a contract in one of three ways:

[[File:OC-2011_Table2.png]]

The reputation system tracks, for each contracting system on the network, a reputation
score based upon the published contract history of that party. Successful contracts increase
reputation score, while breached contracts decrease reputation score. Contracts that are voided by
both parties or negotiated in private (i.e. without witnesses or QUORUM observation) have a
neutral effect on reputation score (though such contracts will still appear in the contract history).
This reputation system can then be used by Clients to determine which Provider proposal to accept.

== QUORUM Gossip ==

In order to facilitate the formation of contracts, it is useful to have a regularly updated
notion of which systems have certain capabilities. For example, if a particular system is in need of
processing time, it needs to be able to quickly determine which providers can offer assistance. To
this end, QUORUM requires an inter-system communication network, and so we propose the
following gossiping system.

=== Gossiping in QUORUM ===

As QUORUM operates, there are four scenarios which involve gossiping: the entrance of a
node, the location of available services, the exchange of reputation information, and the detection of
network failure. We will address each of these separately. Various gossiping algorithms exist [4],
any of which are sufficient for the implementation of QUORUM. Given our current system, we have
derived a gossiping method that utilizes some components of existing methods, such as the
framework in [3].

Each node will have a list L of other nodes, in this list there exists the identity and known
services provided by that node. A node will update entries in L based upon the information it
receives through gossip messages.

=== Entrance ===

When a node joins a network, it will have the address of two existing nodes on the network.
After it joins the network, the two nodes will then randomly assign neighbors to the new node,
selecting them from the QUORUM via some algorithm. Depending on the size of the QUORUM, each
node will have a fixed h number of neighbors; the number of neighbors and how randomly these
neighbors are chosen is an area which needs to be investigated further.

The joining node also sends to its neighbors a list of services that it can provide. Once the
neighbouring nodes have received identified and received the services of the incoming node, they
can then use a gossiping algorithm of the QUORUM to propagate this information. In turn, the
neighbors send their lists to the joining node, making it aware of the various capabilities of the
network it has joined.

=== Search For Services ===

As we saw in the related work, it is highly unlikely (depending on the size of the QUORUM)
for a node to have knowledge of every other node in the system. A given node that is looking for a
particular service x, will first look up in his own list L (that has been updated via gossiping
messages), and if he cannot find service x with the required reputation, he will then ask around the
QUORUM to find the service he is looking for.

=== Failure Detection ===

Failure detection in distributed systems is a prominent sub-problem of distributed systems,
and has approached by several research groups (see [5-9], as referenced in [5]). Below we present
an aggregation of the above efforts, applied to the QUORUM.

Given the neighbor system of QUORUM, each neighbor can expect a gossip message from its
neighbors in a period of t seconds. If a neighbor of a node r fails to send such a message, then r will
send a heartbeat message to its neighbors (i.e. the pull model [7,8]) asking whether it is alive or not.
If r then receives a response, it knows that its neighbor is alive. If r does not receive a response
(after enough heartbeat messages to be convinced that his neighbor is dead), then it would remove
that node from the list of its neighbors, look for another neighbor, and communicate the node
failure (via gossiping messages) to the other members of the QUORUM. Given that this method
relies heavily upon the neighbors of a node, it might be prudent to implement an additional failure
detection method, such as that found in the work of Hayashibara et al.[9].

= Future Work And Conclusion =

Moving forward with QUORUM, one main objective would be to attempt an actual
implementation of the system according to our specifications. In our research we made several
assumptions, one of which was that computers are not mobile. There could be further research
done in examining and modifying our QUORUM to allow for system mobility.

= References =

[1] D.C Verma, Service Level Agreements on IP Networks, Proceedings of the IEEE, vol. 92, pp. 1382-
1388, September 2004.

[2] P. Groth, S. Miles, S. Modgil, N. Oren, M. Luck, G. Yolanda, Determining the Trustworthiness of
New Electronic Contracts, Engineering Societies in the Agents World X, 2009.

[3] A. Kermarrec, M. van Steen, Gossiping in Distributed Systems, SIGOPS Oper. Syst. Rev., 41(5):2-7,
2007.

[4] S. Boyd, A. Ghosh, B. Prabhakar, and D. Shah. “Randomized Gossip Algorithms.” IEEE
Transactions on Information Theory, 52(6):2508-2530, June 2006

[5] S. Sajjadpour, Failure Detection in Distributed Systems, Distributed Operating Systems course,
Carleton University, Winter 2011

[6] R. Van Renesse, Y. Minsky, M. Hayden, A gossip-style failure detection service. In proceeding of
the IFIP International Conference on Distributed Systems Platforms and Open Distributed
Processing, 1998. The version used here is from 2007.

[7] P. Felber, X. Defago, R. Guerraoui, and P. Oser. Failure detectors as first class objects. In
Proceedings of the International Symposium on Distributed Objects and Applications, 1999. The
version I used here is from 2002.

[8] N. Hayashibara, A. Cherif, T. Katayama, Failure Detectors for Large-Scale Distributed Systems, In
21st IEEE Symposium of Reliable Distributed Systems (SRDS’ 02). 2002

[9] N. Hayashibara, X. Defago, R. Yared, T. Katayama. The φ accrual failure detector. In Proceedings
of the 23rd IEEE International Symposium on Reliable Distributed Systems (SRDS’ 04), pages 55-
75, 2004

File:OC-2011 Table2.png

2011-04-13T04:55:08Z

Ajluczak: uploaded a new version of "File:OC-2011 Table2.png"

File:OC-2011 Table2.png

2011-04-13T04:54:25Z

Ajluczak:

Category talk:2011-O&C

2011-03-31T17:39:34Z

Ajluczak: /* Summary */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

===== Summary =====
TJ

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

===== Summary =====
Claimed by Scott

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

===== Summary =====
TJ

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

===== Summary =====
One key concept that we should take from this paper is the way they decided how to allocate the resources. Here is a brief but excellent point to consider:
*In a public computing utility (PCU), the virtyal cluster (VC) management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the anchor points (AP) among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

'''''KEY CONCEPTS'''''

''The key features of the PCU Model are:''
*an ISP like service structure
*proposing the resource profiling scheme for resource registration
*addressing scalability by developing PCU structure made up of domains
*incorporating peering technology for inter-domain information dissemination
*SLA based service instantiation and monitoring

''The key concepts of the VCs idea in this paper are:''
*it mathematically formulates the trade-off between achieving the best QoS and reducing the system cost, making it best suitable for commercial infrastructures
*even though multiple services can occupy a single resource and the service–resource attachments can change with time, a virtualized static logical resource set exposed to the service origin (SO) hides the complexity
*being a semi-dynamic scheme, a VC can reshape itself matching the varying demand pattern, at the same time the static virtualization to the SO simplifying the service management
*the optimization based VC creation results in better resource utilization

''The key concept to anchor points:''
*By providing a representation of demand distribution in a network, the concept of anchor point enables a client-centric resource allocation for widearea services.

''The key attributes of Overload Partitions:''
*they are selected via an optimization process and they are shared among multiple services.
*Provides a cost effective, but still QoS obeying solution to handle demand spikes in the network

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

===== Summary =====

(HS) This paper starts off by talking about different components of a service level agreement. These components include:
1) A description of the nature of service to be provided
2) The expected performance level of the service, specifically its reliability and responsiveness
3) The time-frame for response and problem resolution
4) The process for monitoring and reporting the service level
5) The consequences for the service provider not meeting its obligations
6) Escape clauses and constraints.

Then they give three examples of Service level agreements on IP Networks:
1) Network Connectivity Services
2) Hosting Services
3) Integrated services

And for each of the above three, they suggest some availability, performance and reliability clauses. I think that three notions
of 'availability, reliability and performance' could be three parameters that the scheme we are designing should have for each contract.

After this they discuss three different approaches to support SLAs
1) Insurance Approach
2) Provisioning Approach
3) Adaptive Approach

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====

Imagine this as a table:

*Type
**Whether this is an obligation or permission. A prohibition is modelled as an obligation not to do something, i.e. with a negative normative condition below
*Target
**The contract party obliged, prohibited or permitted by the clause.
*Activating Condition
**The circumstances under which the clause has force, parameterized by the variables specific to each instance.
*Normative Condition
**The circumstances under which the obligation is not being violated or the permission is being taken advantage of, parameterized by the variable specific to each instance. Therefore, for an obligation, the target must maintain the normative condition so as not to be in violation of the contract.
*Expiration Condition
**The circumstances under which the clause no longer has force, parameterized by the variables specific to each instance.

This paper provides a nice, straight-forward definition of what a contract is, and provides the above schema for a contract.

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

===== Summary =====
Hadi

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Category talk:2011-O&C

2011-03-31T17:37:52Z

Ajluczak: /* Summary */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

===== Summary =====
TJ

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

===== Summary =====
Claimed by Scott

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

===== Summary =====
TJ

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

===== Summary =====
One key concept that we should take from this paper is the way they decided how to allocate the resources. Here is a brief but excellent point to consider:
*In a public computing utility (PCU), the virtyal cluster (VC) management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the anchor points (AP) among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

'''''KEY CONCEPTS'''''

''The key features of the PCU Model are:''
*an ISP like service structure
*proposing the resource profiling scheme for resource registration
*addressing scalability by developing PCU structure made up of domains
*incorporating peering technology for inter-domain information dissemination
*SLA based service instantiation and monitoring

''The key concepts of the VCs idea in this paper are:''
*it mathematically formulates the trade-off between achieving the best QoS and reducing the system cost, making it best suitable for commercial infrastructures
*even though multiple services can occupy a single resource and the service–resource attachments can change with time, a virtualized static logical resource set exposed to the service origin (SO) hides the complexity
*being a semi-dynamic scheme, a VC can reshape itself matching the varying demand pattern, at the same time the static virtualization to the SO simplifying the service management
*the optimization based VC creation results in better resource utilization

''The key concept to anchor points:''
*By providing a representation of demand distribution in a network, the concept of anchor point enables a client-centric resource allocation for widearea services.

''The key attributes of Overload Partitions:''
*they are selected via an optimization process and they are shared among multiple services.
*Provides a cost effective, but still QoS obeying solution to handle demand spikes in the network

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

===== Summary =====

(HS) This paper starts off by talking about different components of a service level agreement. These components include:
1) A description of the nature of service to be provided
2) The expected performance level of the service, specifically its reliability and responsiveness
3) The time-frame for response and problem resolution
4) The process for monitoring and reporting the service level
5) The consequences for the service provider not meeting its obligations
6) Escape clauses and constraints.

Then they give three examples of Service level agreements on IP Networks:
1) Network Connectivity Services
2) Hosting Services
3) Integrated services

And for each of the above three, they suggest some availability, performance and reliability clauses. I think that three notions
of 'availability, reliability and performance' could be three parameters that the scheme we are designing should have for each contract.

After this they discuss three different approaches to support SLAs
1) Insurance Approach
2) Provisioning Approach
3) Adaptive Approach

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====

Imagine this as a table:

*Type
**Whether this is an obligation or permission. A prohibition is modelled as an obligation not to do something, i.e. with a negative normative condition below
*Target
**The contract party obliged, prohibited or permitted by the clause.
*Activating Condition
**The circumstances under which the clause has force, parameterized by the variables specific to each instance.
*Normative Condition
**The circumstances under which the obligation is not being violated or the permission is being taken advantage of, parameterized by the variable specific to each instance. Therefore, for an obligation, the target must maintain the normative condition so as not to be in violation of the contract.
*Expiration Condition
**The circumstances under which the clause no longer has force, parameterized by the variables specific to each instance.

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

===== Summary =====
Hadi

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Category:2011-O&C

2011-03-30T00:36:41Z

Ajluczak:

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

==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==

*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

DistOS-2011W Jolicloud

2011-03-17T17:58:07Z

Ajluczak: /* The OS Behind the OS */

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.
[[Image:Jolicloud-img1.png|thumb|center|1024px|JoliCloud Application Catalog]]

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

[[Image:Jolicloud-img2.png|thumb|center|1024px|JoliCloud Application Launcher]]

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

DistOS-2011W Jolicloud

2011-03-17T17:57:52Z

Ajluczak: /* Installing Applications */

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.
[[Image:Jolicloud-img1.png|thumb|center|1024px|JoliCloud Application Catalog]]

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

[[Image:Jolicloud-img2.png|thumb|center|1024px|JoliCloud App Launcher]]

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

DistOS-2011W Jolicloud

2011-03-17T17:57:35Z

Ajluczak: /* The OS Behind the OS */

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.
[[Image:Jolicloud-img1.png|thumb|center|1024px|JoliCloud App Launcher]]

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

[[Image:Jolicloud-img2.png|thumb|center|1024px|JoliCloud App Launcher]]

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

File:Jolicloud-img2.png

2011-03-17T17:56:44Z

Ajluczak: Screenshot of Jolicloud Application Launcher

Screenshot of Jolicloud Application Launcher

DistOS-2011W Jolicloud

2011-03-17T17:56:18Z

Ajluczak: /* The OS Behind the OS */

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.
[[Image:Jolicloud-img1.png|thumb|center|1024px|JoliCloud App Launcher]]

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

[[Image:Jolicloud-img2.png]]

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

DistOS-2011W Jolicloud

2011-03-17T17:55:02Z

Ajluczak: /* Installing Applications */

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.
[[Image:Jolicloud-img1.png|thumb|center|1024px|JoliCloud App Launcher]]

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

File:Jolicloud-img1.png

2011-03-17T17:48:21Z

Ajluczak: Screenshot of JoliCloud Application Catalog

Screenshot of JoliCloud Application Catalog

DistOS-2011W Jolicloud

2011-03-17T17:46:38Z

Ajluczak:

=Introduction=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux
and Chromium. Featuring both a web browser client and a native installation option, Jolicloud is
billed as a lightweight, netbook-friendly operating system. Though the base functionality of
Jolicloud is similar to many other Linux distributions, cloud-based services are used to augment
the system’s capabilities and streamline certain web activities.

This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud
components enhance the overall system. Both the web client and installation version will be
examined, and the various features and shortcomings of the system will be discussed.
Experiences with the both the web interface and the native installation will be laid out (with a
focus on the latter), along with observations about the various features and shortcomings of
the system and its current implementation.

=Web Operating Systems=

As time progresses, the average person collects more and more computerized devices and,
more importantly, more and more devices which connect to the Internet. Due to this fact,
cloud-based services have increased in popularity, particularly those services which allow for
access to personal data from any machine (such as Dropbox), negating the need for manual
synchronization.

A web operating system is the logical extension of this to a larger scale: a collection of tools and
services, all offered over the Internet, which replicates the functionality of a desktop operating
system. In some cases, the entire operating system is replicated, complete with file system and
applications (e.g. eyeOS, a web desktop), and the entire system is independent of the local
machine used to access it; other systems, like Jolicloud, offer a portion of these services and
remain loosely tethered to the hardware they run on.

==JoliCloud==

Jolicloud’s primary role is that of an application launcher. A robust collection of hundreds of
web applications can be attached to your Jolicloud account, which then makes them accessible
through the app menu. Certain applications are native installation only, but the majority of the
applications are enabled in the web instance.

The web instance of Jolicloud consists solely of the HTML5 application launcher, which can be
run through Google’s Chrome browser. The native installation, however, runs this application
launcher on Chromium in a lightweight version of Ubuntu Linux. As the native installation
encompasses the functionality of the web instance, this report will focus on the native
installation.

===Installation Process===

For the purposes of the report, Jolicloud was installed on a Dell Vostro 3400 running Windows
7. The Jolicloud installer permits either a side-by-side installation or a standalone installation,
with either option requiring a minimum of 4GB of space.

Immediately upon initial startup, Jolicloud requires an Internet connection in order to connect
to your Jolicloud account. This permits the system to synchronize any applications you've
associated with your account.

===Installing Applications===

It’s a fairly safe bet that every user is going to want something different from an operating
system. Customization is one of Jolicloud’s strong points: there are hundreds of applications
contained in the application catalog, all of which are rated by the community and categorized
for easy browsing.

Any applications which you install or remove are immediately synchronized with your Jolicloud
account. Once you’ve installed an application, you have the opportunity to “Like” it. Jolicloud
features a social aspect which allows you to add friends to your account, see what applications
they like, and to see the overall review of an application from the entire Jolicloud community. It
also claims to integrate Facebook friends, but since I have no Facebook account I was unable to
verify this claim personally.

There are two types of applications available through the catalog: web applications and native
applications. Web applications are supported by both the web interface and the native
installation, as they are simply links to a specific web service which gets opened in a Chromium
window.

Native applications, on the other hand, are only available when using the native installation
(though they can be added to your client while using the web interface). Rather than link
directly to a web service, these applications run directly on the user’s machine, powered by the
same Linux which forms the backbone of Jolicloud.

===The OS Behind the OS===

As mentioned earlier, Jolicloud runs on top of Ubuntu 10.04. One could use Jolicloud quite
happily without once noticing any of the standard Linux features, and in fact, this seems to be
the encouraged usage behavior. Adding applications to the Jolicloud launcher bypasses any
need for the user to manage software packages. However, this assumes one important thing:
the user only wants applications offered through Jolicloud.

Though Jolicloud’s application catalog is broad and well-stocked, it lacks in several key areas.
Most notably, there are few, if any, applications which can serve as IDEs for programming (VIM
being the most notable), and in order to install any required libraries for a programming
language, one would have to install them directly, outside of Jolicloud. Any application so
installed will not appear in the Jolicloud launcher, but rather can be added to the Local Apps
section.

Herein lies the largest flaw in Jolicloud’s depiction of a web operating system: only applications
(and their settings) which are available through the Jolicloud application catalog are
synchronized with your online image. Any applications which are installed from any source
other than the catalog (i.e. APT) are not synchronized, nor is any data located in the Linux file
system (the version of Ubuntu upon which Jolicloud runs maintains portions of the GNOME
interface, as well as the Nautilus file browser).

Synchronization of files must be done through some web service such as DropBox. While this is
not a crippling flaw, it does crack the seamless web OS experience for any users who lack
experience with Linux.

=The Future of JoliCloud=

The developers of Jolicloud stand at the edge of greatness: they have developed an intuitive
web-based augmentation to the desktop operating system. However, as mentioned above, Jolicloud has several shortcomings which need to be resolved in order for the system to reach
its full potential as a web operating system.

Applications and data outside of the Jolicloud launcher are not synced across systems. While
the developers claim this is an intentional design decision, made in order to keep the focus on
the web applications and HTML5, it would be nice to see full synchronization as an option, even
if only as a partnership between Jolicloud and Dropbox to automatically provide a free account
to your Jolicloud system.

Overall, Jolicloud was nothing like expected. At the start of this experiment, I figured that
Jolicloud was a full-fledged web operating system, with complete independence from the user’s
hardware. Once I realized that my files weren’t being synchronized, the whole system seemed
like an exercise in futility; it seemed like Jolicloud was simply an alternate way of visualizing
your Internet bookmarks. But after a week or two of use, I realized, that’s exactly what Jolicloud
is, and that’s why I was still using it.

As a company, Jolicloud has recently launched their line of Jolibooks: low-cost netbooks with
Jolicloud as the default operating system.

=Conclusion=

Jolicloud is a good approximation of a web operating system. With DropBox handling files, and
Jolicloud handling the main stable of applications, everything clicks into place and the system as
a whole works; on the other hand, due to the size limitations of DropBox, free users may find
themselves (and their data files) tethered to a single machine.

With future competitors waiting to join the fray, especially Chrome OS, which looks to run using
similar technologies configured in a slightly different fashion, it’ll be interesting to see how
Jolicloud evolves to compete.

=References=
Jolicloud Developer’s Blog: http://www.jolicloud.com/blog/ (Accessed February 2011)

Jolicloud: The Future is HTML5: http://www.zdnet.co.uk/news/cloud/2010/08/02/jolicloud-thefuture-is-html-5-40089687/ (Accessed February 2011)

DistOS-2011W Observation Quorum

2011-03-15T18:02:35Z

Ajluczak: Created page with "In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contr…"

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

[[Category:2011-Observability]]

Talk:DistOS-2011W Observation Quorum

2011-03-15T18:02:30Z

Ajluczak: Blanked the page

Talk:DistOS-2011W Observation Quorum

2011-03-15T18:02:16Z

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:39:21Z

Ajluczak: /* AURIC */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

===== Summary =====
TJ

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

===== Summary =====
Claimed by Scott

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

===== Summary =====
TJ

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

===== Summary =====
TJ

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

===== Summary =====
Hadi

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

===== Summary =====
Hadi

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:35:49Z

Ajluczak: /* Dynamic Adaptation */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

===== Summary =====
Claimed by Scott

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

===== Summary =====
TJ

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

===== Summary =====
TJ

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:35:16Z

Ajluczak: /* Heuristics for Enforcing Service Level Agreements */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

===== Summary =====
Claimed by Scott

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

===== Summary =====
TJ

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:28:42Z

Ajluczak: /* Contract Monitoring */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

===== Summary =====
Andrew

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

====Consumer Privacy: Balancing Economic and Justice Considerations====

M.Culnan, R. Biles, Journal of Social Issues

http://onlinelibrary.wiley.com/doi/10.1111/1540-4560.00067/full

===== Abstract =====

Check link for abstract, couldn't copy paste! This paper talks about government regulation, industry self-regulation and technological solutions with regards to the internet.

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:27:50Z

Ajluczak: /* Monitoring Service Contracts */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===== Summary =====
Andrew

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

===== Summary =====
Claimed by Scott

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

====Consumer Privacy: Balancing Economic and Justice Considerations====

M.Culnan, R. Biles, Journal of Social Issues

http://onlinelibrary.wiley.com/doi/10.1111/1540-4560.00067/full

===== Abstract =====

Check link for abstract, couldn't copy paste! This paper talks about government regulation, industry self-regulation and technological solutions with regards to the internet.

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-15T17:27:23Z

Ajluczak: /* Trustworthiness of New Contracts */

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

==== Contract Monitoring ====

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

===== Abstract =====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

==== Monitoring Service Contracts ====

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

===== Abstract =====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

==== AURIC ====
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

===== Abstract =====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

==== Bandwidth ====
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

===== Abstract =====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

==== Dynamic Adaptation ====
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

===== Abstract =====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

==== Heuristics for Enforcing Service Level Agreements ====
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

===== Abstract =====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

==== Service Level Agreement in Cloud Computing ====
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

===== Abstract =====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

==== Service Level Agreements on IP Networks ====

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

===== Abstract =====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

==== Trustworthiness of New Contracts ====

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

===== Abstract =====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

===== Summary =====
Andrew

==== Web Privacy with P3P ====

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

====Consumer Privacy: Balancing Economic and Justice Considerations====

M.Culnan, R. Biles, Journal of Social Issues

http://onlinelibrary.wiley.com/doi/10.1111/1540-4560.00067/full

===== Abstract =====

Check link for abstract, couldn't copy paste! This paper talks about government regulation, industry self-regulation and technological solutions with regards to the internet.

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

DistOS-2011W Observability & Contracts

2011-03-12T02:39:00Z

Ajluczak:

DistOS-2011W Observability & Contracts

2011-03-12T02:35:55Z

Ajluczak:

==Problem Outline==

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

===Observability & Contracts===

* How do I observe the acts of other agents, particularly "public" acts?
* How can make contracts between computers (promises to exchange actions in present for actions in the future)?

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

Talk:DistOS-2011W Observability & Contracts

2011-03-12T02:35:18Z

Ajluczak:

==Papers==

===Observability===

* 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?
* What '''CAN''' be observed?

=== Contract Monitoring ===

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

==== Abstract ====

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

=== Monitoring Service Contracts ===

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

==== Abstract ====

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

===Contracts===

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

=== AURIC ===
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

==== Abstract ====
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

=== Bandwidth ===
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

==== Abstract ====
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

=== Dynamic Adaptation ===
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

==== Abstract ====
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

=== Heuristics for Enforcing Service Level Agreements ===
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

==== Abstract ====
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

=== Service Level Agreement in Cloud Computing ===
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

==== Abstract ====
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

=== Service Level Agreements on IP Networks ===

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

==== Abstract ====
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

=== Trustworthiness of New Contracts ===

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

==== Abstract ====

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

=== Web Privacy with P3P ===

http://www.oreilly.de/catalog/webprivp3p/

This book talks about P3P and how companies and web developers can comply with p3p.
Also check http://www.w3.org/P3P/

===Consumer Privacy: Balancing Economic and Justice Considerations===

M.Culnan, R. Biles, Journal of Social Issues

http://onlinelibrary.wiley.com/doi/10.1111/1540-4560.00067/full

==== Abstract ====

Check link for abstract, couldn't copy paste! This paper talks about government regulation, industry self-regulation and technological solutions with regards to the internet.

==Increasing Observability==

Like we discussed on Thursday, the real question when looking at observability is whether an action can be viewed, and who can view it. In the real world, you have a chance of being observed no matter what you do; the Internet, on the other hand, reduces this observability and instead offers a modicum of anonymity.

As the possibility of being observed increases, behavior adjusts to encourage the positive reputation of the actor or to conform with laws and regulations. This is the main benefit we wish to obtain by increasing the observability of digital actions. While omnipresent observation is possible on a computer network, in terms of observing contracts it might be more efficient to impose the possibility of being observed.

===A Possible System for Increasing Observability of Contracts and Actions?===

In class on Thursday, Scott brought up the idea of tracking a contract by making a minimal set of details available to all (i.e., everyone knows the parties involved in the contract, and whether the contract was fulfilled). Taking this a little further, our group considered the existence of an anonymous, distributed quorum of observers.

This quorum would, upon the creation of a contract, be given a summary of the contract (for example, Company A has agreed to cache data for Company B on a given day, while Company B will reciprocate the following day). Over the term of the contract, the individual systems in the quorum would test the contract to see if the terms had been met. At the end of the contract period, the systems would provide a "vote" declaring whether they witnessed the contract being fulfilled.

This system could also be extended to monitor general actions. Consider again this set of observers, however, now they connect at random to various websites, and take a snapshot of all connections to it. At any given time, no other user knows which system the observers will be monitoring. In other words, the observers are analogous to police patrols, albeit with no set patrol route.

Talk:DistOS-2011W Observability & Contracts

2011-03-12T02:14:15Z

Ajluczak:

Talk:DistOS-2011W Observability & Contracts

2011-03-08T18:40:17Z

Ajluczak:

==Observability==

* 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?

== Contract Monitoring ==

[http://dx.doi.org/10.1007/978-3-642-03668-2_29 Contract Monitoring in Agent-Based Systems: Case Study] from Lecture Notes in Computer Science by Jiří Hodík, Jiří Vokřínek and Michal Jakob, 2009

=== Abstract ===

Monitoring of fulfilment of obligations defined by electronic contracts in distributed domains is presented in this paper. A two-level model of contract-based systems and the types of observations needed for contract monitoring are introduced. The observations (inter-agent communication and agents’ actions) are collected and processed by the contract observation and analysis pipeline. The presented approach has been utilized in a multi-agent system for electronic contracting in a modular certification testing domain.

== Monitoring Service Contracts ==

[http://dx.doi.org/10.1007/3-540-45705-4_15 An Agent-Based Framework for Monitoring Service Contracts] from Lecture Notes in Computer Science by Helmut Kneer, Henrik Stormer, Harald Häuschen and Burkhard Stiller, 2002

=== Abstract ===

Within the past few years, the variety of real-time multimedia streaming services on the Internet has grown steadily. Performance of streaming services is very sensitive to traffic congestion and results very often in poor service quality on today’s best effort Internet. Reasons include the lack of any traffic prioritization mechanisms on the network level and its dependence on the cooperation of several Internet Service Providers and their reliable transmission of data packets. Therefore, service differentiation and its reliable delivery must be enforced on a business level through the introduction of service contracts between service providers and their customers. However, compliance with such service contracts is the crucial point that decides about successful improvement of the service delivery process. For that reason, an agent-based monitoring framework has been developed and introduced enabling the use of mobile agents to monitor compliance with contractual agreements between service providers and service customers. This framework describes the setup and the functionality of different kinds of mobile agents that allow monitoring of service contracts across domains of multiple service providers.

==Contracts==

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

Some forms of contracts exist in the form of Service Level Agreements, and there have been efforts made to automate this process:

== AURIC ==
[http://dx.doi.org/10.1007/978-3-540-75694-1_21 AURIC: A Scalable and Highly Reusable SLA Compliance Auditing Framework] from Lecture Notes in Computer Science, by Hasan and Burkhard Stiller, 2007.

=== Abstract ===
Service Level Agreements (SLA) are needed to allow business interactions to rely on Internet services. Service Level Objectives (SLO) specify the committed performance level of a service. Thus, SLA compliance auditing aims at verifying these commitments. Since SLOs for various application services and end-to-end performance definitions vary largely, automated auditing of SLA compliances poses the challenge to an auditing framework. Moreover, end-to-end performance data are potentially large for a provider with many customers. Therefore, this paper presents a scalable and highly reusable auditing framework and a prototype, termed AURIC (Auditing Framework for Internet Services), whose components can be distributed across different domains.

== Bandwidth ==
[http://dx.doi.org/10.1007/978-3-540-30189-9_19 SLA-Driven Flexible Bandwidth Reservation Negotiation Schemes for QoS Aware IP Networks] from Lecture Notes in Computer Science by Gerard Parr and Alan Marshall, 2004.

=== Abstract ===
We present a generic Service Level Agreement (SLA)-driven service provisioning architecture, which enables dynamic and flexible bandwidth reservation schemes on a per- user or a per-application basis. Various session level SLA negotiation schemes involving bandwidth allocation, service start time and service duration parameters are introduced and analysed. The results show that these negotiation schemes can be utilised for the benefits of both end user and network provide such as getting the highest individual SLA optimisation in terms of Quality of Service (QoS) and price. A prototype based on an industrial agent platform has also been built to demonstrate the negotiation scenario and this is presented and discussed.

== Dynamic Adaptation ==
[http://dx.doi.org/10.1007/978-3-540-89652-4_28 Context-Driven Autonomic Adaptation of SLA] from Lecture notes in Computer Science, by authors Caroline Herssens, Stéphane Faulkner and Ivan Jureta, 2008.

=== Abstract ===
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or resource availability changes). Changes in the context can make SLAs obsolete, making SLA revision necessary. We propose a method to autonomously monitor the services’ context, and adapt SLAs to avoid obsolescence thereof.

== Heuristics for Enforcing Service Level Agreements ==
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8674&rep=rep1&type=pdf Heuristics for Enforcing Service Level Agreements in a Public Computing Utility] A masters thesis paper by Balasubramaneyam Maniymaran.

=== Abstract ===
With the increasing popularity of consumer and research oriented wide-area applications,there arises a need for a robust and efﬁcient wide-area resource management system. Even though there exists number of systems for wide area resource management, they fail to couple the QoS management with cost management, which is the key issue in pushing such a system to be commercially successful. Further, the lack of IT skills within the companies arouses the need of decoupling service management from the underlying complex wide-area resource management. A public computing utility (PCU) addresses both these issues, and, in addition, it creates a market place for the selling idling computing resources.

This work proposes a PCU model addressing the above mentioned issues and develops heuristics to enforce QoS in that model. A new concept called virtual clusters (VCs) is introduced as semi-dynamic, service speciﬁc resource partitions of a PCU, optimizing cost, QoS, and resource utilization. This thesis describes the methodology of VC creation, analyses the formulation of a VC creation into an optimization problem, and develops solution heuristics. The concept of VC is supported by two other concepts introduced here namely anchor point (AP) and overload partition (OLP). The concept of AP is used to represent the demand distribution in a network that assists the problem formulation of the VC creation and SLA management. The concept of overload partition is used to handle the demand spikes in a VC.

In a PCU, the VC management is implemented in two phases: the ﬁrst is an off-line phase of creating a VC that selects the appropriate resources and allocates them for the particular service; and the second phase employs on-line scheduling heuristic to distribute the jobs/requests from the APs among the VC nodes to achieve load balancing. A detailed simulation study is conducted to analyze the performance of different VC conﬁgurations for different load conditions and scheduling schemes and this performance is compared with a fully dynamic resource allocation scheme called Service Grid. The results verify the novelty of the VC concept.

== Service Level Agreement in Cloud Computing ==
[http://knoesis.wright.edu/library/download/OOPSLA_cloud_wsla_v3.pdf SLAs in Cloud Computing] A paper written by Pankesh Patel, Ajith Ranabahu, Amit Sheth.

=== Abstact ===
Cloud computing that provides cheap and pay-as-you-go computing resources is rapidly gaining momentum as an alternative to traditional IT Infrastructure. As more and more consumers delegate their tasks to cloud providers, Service Level Agreements(SLA) between consumers and providers emerge as a key aspect. Due to the dynamic nature of the cloud, continuous monitoring on Quality of Service (QoS)attributes is necessary to enforce SLAs. Also numerous other factors such as trust (on the cloud provider) come into consideration, particularly for enterprise customers that may outsource its critical data. This complex nature of the cloud landscape warrants a sophisticated means of managing SLAs. This paper proposes a mechanism for managing SLAs in a cloud computing environment using the Web Service Level Agreement(WSLA) framework, developed for SLA monitoring and SLA enforcement in a Service Oriented Architecture (SOA). We use the third party support feature of WSLA to delegate monitoring and enforcement tasks to other entities in order to solve the trust issues. We also present a real world use case to validate our proposal.

== Service Level Agreements on IP Networks ==

By Dinesh C. Verma, IBM T. J Watson Research center
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1323286&tag=1

=== Abstract ===
Abstract: This paper provides an overview of service-level agreements in IP networks. It looks at the typical components of a service-level agreement, and identifies three common approaches that are used to satisfy service level agreements in IP networks. The implications of using the approaches in the context of a network service provider, a hosting service provider, and an enterprise are examined. While most providers currently offer a static insurance approach towards supporting service level agreements, the schemes that can lead to more dynamic approaches are identified.

== Trustworthiness of New Contracts ==

[http://dx.doi.org/10.1007/978-3-642-10203-5_12 Determining the Trustworthiness of New Electronic Contracts] from Lecture Notes in Computer Science by Paul Groth, Simon Miles, Sanjay Modgil, Nir Oren, Michael Luck and Yolanda Gil, 2009.

=== Abstract ===

Expressing contractual agreements electronically potentially allows agents to automatically perform functions surrounding contract use: establishment, fulfilment, renegotiation etc. For such automation to be used for real business concerns, there needs to be a high level of trust in the agent-based system. While there has been much research on simulating trust between agents, there are areas where such trust is harder to establish. In particular, contract proposals may come from parties that an agent has had no prior interaction with and, in competitive business-to-business environments, little reputation information may be available. In human practice, trust in a proposed contract is determined in part from the content of the proposal itself, and the similarity of the content to that of prior contracts, executed to varying degrees of success. In this paper, we argue that such analysis is also appropriate in automated systems, and to provide it we need systems to record salient details of prior contract use and algorithms for assessing proposals on their content. We use provenance technology to provide the former and detail algorithms for measuring contract success and similarity for the latter, applying them to an aerospace case study.

Talk:DistOS-2011W Observability & Contracts

2011-03-08T18:34:29Z

Ajluczak:

Talk:DistOS-2011W Observability & Contracts

2011-03-03T19:00:31Z

Ajluczak: /* Observability */

Talk:DistOS-2011W Observability & Contracts

2011-03-03T18:56:03Z

Ajluczak:

==Observability==

* How do we define 'public' acts?
* How can you make sure your agent is acting in your best interests?
* How can we ensure that information we receive through a third-party is legitimate?

==Contracts==

* What can or can't be contracted?
* How can you quantify abstract resources?
* How can two or more parties agree with a minimum of intervention?

DistOS-2011W Observability & Contracts

2011-03-03T18:44:36Z

Ajluczak: /* Members */

==Problem Outline==
===Observability & Contracts===

* How do I observe the acts of other agents, particularly "public" acts?
* How can make contracts between computers (promises to exchange actions in present for actions in the future)?

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

DistOS-2011W Jolicloud

2011-03-01T18:52:00Z

Ajluczak:

Andrew Luczak

The entirety of my report can be found [http://dl.dropbox.com/u/3311854/Report.pdf here]

=Abstract=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux and Chromium. This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud components enhance the overall system.

DistOS-2011W Jolicloud

2011-03-01T17:47:55Z

Ajluczak:

The entirety of my report can be found [http://dl.dropbox.com/u/3311854/Report.pdf here]

=Abstract=

Jolicloud is an open source, cloud-powered operating system developed on top of Ubuntu Linux and Chromium. This report aims to evaluate Jolicloud as an operating system, with a focus on how the cloud components enhance the overall system.

DistOS-2011W Jolicloud

2011-03-01T17:44:09Z

Ajluczak:

=Introduction=

[[Media:jolicloud.pdf]]

Describe the system(s) that you examined or compared. Why did you choose them? Be sure to specify a thesis that you argue in the rest of the document. Since this is a report the thesis may be relatively weak; however, an appropriate thesis will help the reader understand why did what you did and why you wrote what you wrote.

End with a paragraph outlining the rest of the document.

Be sure to change the titles of the following sections to match the structure of your paper. In particular, please try to make them less generic. What follows is just a suggestion; the document will be evaluated in part on the quality of writing, and good writing sometimes requires some flexibility.

=Systems/Programs in the Space=

Give an overview of the area you are examining. What systems/programs are out there?

=Evaluated Systems/Programs=

Describe the systems individually here - their key properties, etc. Use subsections to describe different implementations if you wish. Briefly explain why you made the selections you did.

=Experiences/Comparison (multiple sections)=

In multiple sections, describe what you learned.

=Discussion=

What was interesting? What was surprising? Here you can go out on tangents relating to your work

=Conclusion=

Summarize the report, point to future work.

=References=

Give references in proper form (not just URLs if possible, give dates of access).

DistOS-2011W Jolicloud

2011-03-01T16:43:37Z

Ajluczak: Created page with "=Introduction= Describe the system(s) that you examined or compared. Why did you choose them? Be sure to specify a thesis that you argue in the rest of the document. Since th…"

=Introduction=

Describe the system(s) that you examined or compared. Why did you choose them? Be sure to specify a thesis that you argue in the rest of the document. Since this is a report the thesis may be relatively weak; however, an appropriate thesis will help the reader understand why did what you did and why you wrote what you wrote.

End with a paragraph outlining the rest of the document.

Be sure to change the titles of the following sections to match the structure of your paper. In particular, please try to make them less generic. What follows is just a suggestion; the document will be evaluated in part on the quality of writing, and good writing sometimes requires some flexibility.

=Systems/Programs in the Space=

Give an overview of the area you are examining. What systems/programs are out there?

=Evaluated Systems/Programs=

Describe the systems individually here - their key properties, etc. Use subsections to describe different implementations if you wish. Briefly explain why you made the selections you did.

=Experiences/Comparison (multiple sections)=

In multiple sections, describe what you learned.

=Discussion=

What was interesting? What was surprising? Here you can go out on tangents relating to your work

=Conclusion=

Summarize the report, point to future work.

=References=

Give references in proper form (not just URLs if possible, give dates of access).

Distributed OS: Winter 2011

2011-03-01T16:43:29Z

Ajluczak: /* Implementation reports (undergrads) */

==Evaluation==

Grades in this class will be determined based on the following criteria.

Undergraduate Students:
* 20% Class participation
* 20% Wiki participation
* 10% Group project oral presentation (April 5th in class)
* 30% Group project written report (Due April 11th)
* 20% Implementation report (Due March 1st)

Graduate Students:
* 15% Class participation
* 20% Wiki participation
* 10% Group project oral presentation (April 5th in class)
* 30% Group project written report (Due April 11th)
* 25% Literature review paper (Due March 1st)

Proposals for Implementation reports & Literature reviews should be emailed to Prof. Somayaji by '''February 1st'''.

==Implementation reports (undergrads)==

An implementation report is a 5-10 page paper that either
# describes in detail one existing software system with distributed OS-like properties,
# compare and contrasts an important characteristic of 3 or more software systems with distributed OS-like properties, or
# reports on experiences setting up and using a software system with distributed OS-like properties.
Topics for an implementation report must be approved by Prof. Somayaji.

Implementation reports for Winter 2011:
* [[DistOS-2011W NTP |NTP]]
* [[DistOS-2011W Globus |Globus Toolkit]]
* [[DistOS-2011W Implementation Template|Implementation Template]]
* [[DistOS-2011W BigTable|BigTable]]
* [[DistOS-2011W Cassandra and Hamachi|Cassandra and Hamachi]]
* [[DistOS-2011W Wuala |Wuala]]
* [[DistOS-2011W FWR |FWR]]
* [[DistOS-2011W Plan 9| Plan 9]]
* [[DistOS-2011W Akamai and CDN| Akamai and CDN]]
* [[DistOS-2011W Diaspora| Diaspora]]
* [[DistOS-2011W Eucalyptus |Eucalyptus]]
* [[DistOS-2011W Jolicloud |Jolicloud]]

Students: please add your report above following the template.

==Literature review paper (graduate students)==

The literature review paper should be a 8-12 page paper that reviews research and well-known commercial work in an area of distributed operating systems research or a closely related area.

Literature Review papers for Winter 2011:
* [[DistOS-2011W Naming and Locating Objects in Distributed Systems|Naming and Locating Objects in Distributed Systems]]
* [[DistOS-2011W Distributed File System Access|Distributed File System Access]]
* [[DistOS-2011W User Controlled Bandwidth: How Social Protocols Affect Network Protocols and Our Need for Speed|User Controlled Bandwidth]]
* [[DistOS-2011W General Purpose Frameworks for Performance-Portable Code|General Purpose Frameworks for Performance-Portable Code]]
* [[DistOS-2011W Distributed Data Structures: a survey|Distributed Data Structures: a survey]]
* [[DistOS-2011W Distributed File System Security|Distributed File System Security]]

Students: please add your paper above.

==Group Projects==
* [[DistOS-2011W Attribution|Attribution]]: How do we know who did what?
* [[DistOS-2011W Reputation|Reputation]]: How do we remember and disseminate knowledge of past actions?
* [[DistOS-2011W Contracts|Contracts]]: How can make contracts between computers (promises to exchange actions in present for actions in the future)?
* [[DistOS-2011W Justice|Justice]]: Given that we can gather evidence of misbehavior, how can that evidence be assembled, judged, and the resulting decision enforced?
* [[DistOS-2011W Public Goods|Public Goods]]: How can we build and maintain public goods (e.g., indices, caches)?
* [[DistOS-2011W Public Assistance]]: How do we help agents that are "in need"?

==Readings==

===January 13, 2011===
[http://keys.ccrcentral.net/ccr/writing/ CCR] (two papers)

===January 18, 2011===
[http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/oceanstore-sigplan.pdf OceanStore] and [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/fast2003-pond.pdf Pond]

===February 3, 2011===

*'''[http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=1450841 Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)]:'''
* [http://video.google.com/videoplay?docid=4989933629762859961 Computer Networks - The Heralds of Resource Sharing] (video - optional).

===February 8, 2011===

* Karlin et al. (2008), [http://dx.doi.org.proxy.library.carleton.ca/10.1016/j.comnet.2008.06.012 Autonomous security for autonomous systems].

Optional readings:

* O'Donnell (2009), [http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5350725 Prolog to A Survey of BGP Security Issues and Solutions]
* Butler et al. (2009), [http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5357585 A Survey of BGP Security Issues and Solutions]

===February 10, 2011===

* Savage et al. (2000), [http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-8-4.pdf Practical Network Support For IP Traceback].

===February 15, 2011===

* Satyanarayanan et al. (1990), [http://dx.doi.org.proxy.library.carleton.ca/10.1109/12.54838 Coda: a highly available file system for a distributed workstation environment].
* Ghemawat et al. (2003), [http://labs.google.com/papers/gfs.html The Google File System].

===February 17, 2011===

* Weil et al. (2006), [http://www.usenix.org/events/osdi06/tech/weil.html Ceph: A Scalable, High-Performance Distributed File System].

===March 1, 2011===
* Oda et al. (2008), [http://people.scs.carleton.ca/~soma/pubs/oda-ccs-08.pdf SOMA: Mutual Approval for Included Content in Web Pages].
* Oda & Somayaji (2008), [http://people.scs.carleton.ca/~soma/pubs/oda-asia-08.pdf Content Provider Conflict on the Modern Web].

===Problems to Solve===
*Attack computers with almost no consequences
**DDoS
**botnets
**capture and analyze private traffic
**distribute malware
**tampering with traffic
**Unauthorized access to data and resources
**Impersonate computers, individuals, applications
**Fraud, theft
**regulate behavior

===Design Principles===
*subjects of governance: programs and computers
*bind programs and computers to humans & human organizations, but recognize binding is imperfect
*recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
*rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

==Scenarios==

===1: Stopping DDoS===
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt, AbdelRahman, Rakhim Davletkaliyev

*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,
the sender could be put on a black list.

* (AS) Stopping DDoS against files, services, programs, etc
** (AS) Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
** (AS) If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.
*** I like this idea of having service fallover
*** Expanding on the idea of file replication and sending distress signals to it's neighbours, I could envision a group of servers that would learn to help each other out. Lending processing and storage when they are under utilized. The would sort of form a collective, club or gang. Members who didn't contribute ( always fully utilized ) would eventually be identified and banned. It would be these other computers that the targeted server would rely on for help in this situation. However cool this is it isn' really a solution because one could suppose the attackers might utilize the same strategy to recruit additional help in there attack.

* (AS) Stopping DDoS against specific machines
** (AS) I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.
*** I don't like the idea of sacrificing the one for the many though.
**** (AS) The main thing with what I've proposed is that the motivation behind doing a DDoS attack is completely gone (by doing one a service would either maintain or increase its overall availability). I think by eliminating the main result of a DDoS attack would mean that there would be no reason to guard against DDoS attacks on a specific machine.

*Stopping DDoS
** Many of the DDoS attacks utilize the property of anonymity. These services serve anyone who requests there service. Many DDoS attacks then ensure sufficient traffic that the computer behind the service can no longer cope. If we remove anonymity and only serve 'known' parties the spurious requests would be ignored. So we need to 'know' who our friends are.
*** This of course requires a form of unspoofable authentication unlike IP.
**** (RD) Serving only 'known' parties reduces the distribution of information, or at least its rate. I was thinking of removing anonymity on a lower level, so that any party that's not anonymous while sending a packet to your machine is considered 'known', and anything unknown (unsigned, unrepresented in some way) is blocked. So, we don't really need to 'know' who our friends are, we just need to know who aren't.
**** (RD) Another thing I had in mind is punishment in case a 'known' party participates in DDoS-attack: not punishing the owner of that machine (who probably is a victim as well), but the software or hardware in some sense.

*Stopping DDoS
** (RD) How about developing such a network topology and protocols that make DDoS attacks less efficient or harder to perform? Some sort of CAPTCHA, but for machines and protocols, to distinguish them from bots, maybe?

*Stopping DDoS
** I'm not sure what it means by stopping, I don't think we can stop DDos given the way things are currently ran, we can only block it. From my knowledge most softwares that stop DDoS do so by blocking, or even complete shut down like Mccolo.

*Stopping DDos
**One method is to use the same way of eliminating DoS by rejecting a specific rate of subsequent requests but from irrelevant sources.

*How we could stop DDoS would be to have each connection to the internet assigned to a particular identity. This identity would be used to verify who is attempting connections. The reason DDoS works is because currently, IP addresses can be spoofed. The only way to verify an identity is to request a response, but by then the damage is done. With a verified identity, connection attempts being routed can be verified during transmission, so that the request may not necessarily even reach the destination host.

Basically, we need some encryption system using keys so that as the packets are being routed, the identity of the packet's sender can be verified. Ideally the decryption would be trivial so as to prevent noticeable latency. Because an identity is verified, if there is spoofing of packets, they would be dropped during the routing. If all the identities are verified and are still attempting a DDoS attack, the attacker's identity will be traced back to the attacker.

(RD) (I think we're not looking low enough. We're trying to find a solution for this problem assuming the system that made that problem possible is still unchanged. We enforce more security by identification, encryption, etc, but the system is still problem-prone. This will allow to identify an attacker, but after the attack was started (or even finished). It's like trying to eliminate theft from a society of poor, unemployed, uneducated people by enforcing more security and punishment. Which will help to reduce the rate and motivation, but can't stop the possible attack. It is pretty stupid analogy, but rather than policing that society, I want to make them rich, employed and educated, so that thefts are just not efficient way of getting goods for them. So, rather than protecting machines from attacks, I want to make the system where DDoS-attacks are just inappropriate.)

===2: Stopping phishing===
Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad, Tarjit Komal

* A way of automatically checking the signature of a message to make sure it really is from a trusted source.
** ie: "Nation of Banks, did your member TD send me a message to reset my password?"

*There should be filters to ensure where the message is coming from.If the message is coming from unknown source , it should be blocked.
*Don't use the links in an email to get to any web page, if you suspect the message might not be authentic.
*Avoid filling out forms in email messages that ask for personal financial information. Phishers can make exact forms which you can find on financial institution.
*Make is so a machine needs to be authorized to use your information -- A machine that you don't own can't use your information to do anything, regardless of whether he has it or not.
*Ensure that any website that requires the filling of personal information be a secure website which can be traced to the original organisation.
*Ensure that whatever browser you are using is up to date with the most recent security patches applied.
*Obviously, report and suspected phishing to the appropriate authorities so that proper action can be taken
*"three strikes and you're out"
**Each machine is responsible for the massages it releases. When a machine is a repeat offender it loses access privileges
*Revamp the security login process to something similar to:
**User enters username and clicks next.
**Server returns a user predefined image to the User.
**If image is the right image then user enters password to logon.

===3: Limiting the spread of malware===
Group members: keith, Andrew Luczak, David Barrera, Trevor Gelowsky, Scott Lyons
*(KM) Heterogenous systems - it is much easier to write code to attack a single type of system
*(KM) Individualized security policies
**(AL) A baseline security level would help prevent malware spreading to/from a system with "individual non-security"
*(KM) Identify all programs through digital signatures
*(KM) Peer rating system for programs, customize security policies based on peer ratings
**(SL) Need some way to keep rating system from being "gamed"
***(AL) Maybe a program gets flagged if it experiences a rapid approval increase?
**(AL) Need to protect against benign programs with good ratings being updated into malware
*(KM) System level forensics on program execution and resource/file modification
*(KM) Customizable user and program blacklists
*(SL) Sandboxing with breach management - know what files have been modified by a process
*(SL) Trending - what does the application spend most of its time doing?

*(DB)Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
*(DB)Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*(DB)There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.

===4: Bandwidth hogs===
Group members: Mike Preston, Fahim Rahman, Michael Du Plessis, Matthew Chou, Ahmad Yafawi

*limit bandwidth for each user
*if user has significant bandwidth demands for a certain period of time
**add them to a watch list
**monitor their behaviour
**divert communication to other hosts that can satisfy requests.
***if there are no other hosts that can satisfy the request, then distribute data to other idle and capable hosts. Load is now reduced on the one link.
*QoS
*Tiered Bandwidth Distribution
**The main idea is you get more bandwidth to your machine as much as you give back to the community.
***It's similar to some trackers and dark net programs in which they wont increase your download speed unless you contribute X amount of Bytes back to your peers.
**Tier 1, Basic privileges i.e. all machines have minimal bandwidth.
**Tier n, we define some requirements to be met then we increase bandwidth accordingly.
***Drop a Tier if machine doesn't maintain the specified requirements of that specific tier.
***Advantage, monitoring bandwidth on the network is cheap while implementing what is stated above is not.
*As a metaphor to our "real world society", bandwidth control can be treated as we do speed for cars.
**Certain areas need more free flowing traffic, so speed limits are increased. Others require a slower pace which is enforced. These "areas" can be translated to users or programs in our distributed OS model
**There are repercussions to breaking any of these imposed limits
**Throttling provides once possible implementation of these constraints

====Bandwidth Hog Additional Sources and Information====
1. [http://repository.lib.ncsu.edu/ir/bitstream/1840.16/1197/1/etd.pdf A Solution to Bandwidth Hogs in a Cable Network]
*Starting at page 120 of this thesis is a proposed solution to bandwidth hogs on a cable network. In general, the proposal suggests a solution essentially equal to throttling however I did find the description of the solution to be helpful. I feel it may go well with our tiered suggestion if we were to keep the "earned trust" approach to bandwidth access but at the same time allow users in low congestion times to go above their tier. For example, if congestion is low, why not allow the people on the network to occupy much larger bandwidths. On the network include some form of monitoring protocol which can decide how much access a user is allowed. If more bandiwdth is available, let them have it if it is needed for their request. On the other hand, if congestion is high, the user will be capped at the upper limit of their bandwidth capacity if they are doing something that requires a large amount of bandwidth. In this manner each user will be guaranteed the amount they have earned at their tier, however if they do not want to earn a higher level for high usage timeframes they can instead opt to make use of low congestion timeframes and run their bandwidth heavy applications at that time. The network could also include live data regarding the current bandwidth usage levels as well as trending data so that people can plan when to start bandwidth heavy applications.

2. [http://yuba.stanford.edu/rcp/flowCompTime-dukkipati.pdf Why Flow-Completion Time is the Right Metric for Congestion Control]
*This is a short article which raises an interesting question related to our topic, how should we determine what is considered "bandwidth hogging". For example, do we look at the strain on the network in some capacity (i.e. dropped packets, usage level of the capacity of the pipe,etc.) which is important information for those who build the network; or do we make use of the time it takes for some transaction to occur when a user requests it? This article argues that from a user's point of view, they do not care how much bandwidth they get as long as the task they are requesting is completed as quickly as possible. In our discussion in class we had talked about how majority of people currently do not require large bandwidth needs for normal transactions ( email, web searching, wikis ;-) ), and a much smaller percentage of the population are the ones who actually eat up the larger bandwidth through hog-like applications. Maybe instead of focusing on the bandwidth as the main issue, we should think about how long it takes to complete tasks. Maybe our tiered system would also incorporate some aspect of this train of thought, i.e. people who only send email and surf the web are at tier one, people who use online storage and FTP are on level 2, people who stream movies and other data are at level 3, etc. Then, we could have each tier cost a separate amount and apply some form of control on the technologies available at each tier so that the restrictions of a tier are adhered to.

3. [http://research.microsoft.com/en-us/people/asellen/pap0209-chetty.pdf Who’s Hogging The Bandwidth?: The Consequences Of Revealing The Invisible In The Home]
*This article is from Micrsoft reasearch and it is an interesting look into controlling bandwidth usage by providing people with a tool to monitor the usage and alter how bandwidth is allocated. This tool essentially boils down to the social control idea that we discussed in class. If you know that your neighbours are hogging the bandwidth for very low priority issues then should you not be able to appeal to their conscience in order to gain usage of resources you need? The article provides some examples of homes they provided this control to and how the household politcs factored into the usage of the bandwidth. When usage was no longer hidden it seems as though it became easier to openly discuss how to divide the finite amount of bandwidth. Initial concerns revolved around people just hogging the bandwidth for themselves or playing practical jokes on others in the house by reducing their usage when they were in the middle of some task. Another issue that this type of control brings up is how to prioritize what tasks are "more important". One example given was if a Skype call to family and friends is more important than watching YouTube videos for a work related task. Interestingly the field studies provided some other examples of a "bandwidth etiqutte" that emerged. For example, it was considered very rude to limit somone's bandwidth when he/she was on a Skype call due to the immediate and negative effect but it was deemed acceptable to limit bandwidth during a file transfer as it just meant a few extra minutes for the transfer to complete.

Distributed OS: Winter 2011

2011-01-20T06:15:29Z

Ajluczak: /* 3: Limiting the spread of malware */

==Readings==

January 13, 2011: [http://keys.ccrcentral.net/ccr/writing/ CCR] (two papers)

January 18, 2011: [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/oceanstore-sigplan.pdf OceanStore] and [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/fast2003-pond.pdf Pond]

==Internet Governance==

===Problems to Solve===
*Attack computers with almost no consequences
**DDoS
**botnets
**capture and analyze private traffic
**distribute malware
**tampering with traffic
**Unauthorized access to data and resources
**Impersonate computers, individuals, applications
**Fraud, theft
**regulate behavior

===Design Principles===
*subjects of governance: programs and computers
*bind programs and computers to humans & human organizations, but recognize binding is imperfect
*recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
*rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

==Scenarios==

===1: Stopping DDoS===
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt, AbdelRahman

*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,
the sender could be put on a black list.

*Stopping DDoS against files, services, programs, etc
**Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
**If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.

*Stopping DDoS against specific machines
**I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.

*Stopping DDoS
** I'm not sure what it means by stopping, I don't think we can stop DDos given the way things are currently ran, we can only block it. From my knowledge most softwares that stop DDoS do so by blocking, or even complete shut down like Mccolo.

*Stopping DDos
**One method is to use the same way of eliminating DoS by rejecting a specific rate of subsequent requests but from irrelevant sources.

*How we could stop DDoS would be to have each connection to the internet assigned to a particular identity. This identity would be used to verify who is attempting connections. The reason DDoS works is because currently, IP addresses can be spoofed. The only way to verify an identity is to request a response, but by then the damage is done. With a verified identity, connection attempts being routed can be verified during transmission, so that the request may not necessarily even reach the destination host.

Basically, we need some encryption system using keys so that as the packets are being routed, the identity of the packet's sender can be verified. Ideally the decryption would be trivial so as to prevent noticeable latency. Because an identity is verified, if there is spoofing of packets, they would be dropped during the routing. If all the identities are verified and are still attempting a DDoS attack, the attacker's identity will be traced back to the attacker.

===2: Stopping phishing===
Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad

* A way of automatically checking the signature of a message to make sure it really is from a trusted source.
** ie: "Nation of Banks, did your member TD send me a message to reset my password?"

*There should be filters to ensure where the message is coming from.If the message is coming from unknown source , it should be blocked.
*Don't use the links in an email to get to any web page, if you suspect the message might not be authentic.
*Avoid filling out forms in email messages that ask for personal financial information. Phishers can make exact forms which you can find on financial institution.

===3: Limiting the spread of malware===
Group members: keith, Andrew Luczak, David Barrera, Trevor Gelowsky, Scott Lyons
*(KM) Heterogenous systems - it is much easier to write code to attack a single type of system
*(KM) Individualized security policies
**(AL) A baseline security level would help prevent malware spreading to/from a system with "individual non-security"
*(KM) Identify all programs through digital signatures
*(KM) Peer rating system for programs, customize security policies based on peer ratings
**(SL) Need some way to keep rating system from being "gamed"
***(AL) Maybe a program gets flagged if it experiences a rapid approval increase?
**(AL) Need to protect against benign programs with good ratings being updated into malware
*(KM) System level forensics on program execution and resource/file modification
*(KM) Customizable user and program blacklists
*(SL) Sandboxing with breach management - know what files have been modified by a process
*(SL) Trending - what does the application spend most of its time doing?

===4: Bandwidth hogs===
Group members: Mike Preston, Fahim Rahman, Michael Du Plessis, Matthew Chou

*limit bandwidth for each user
*if user has significant bandwidth demands for a certain period of time
**add them to a watch list
**monitor their behaviour
**divert communication to other hosts that can satisfy requests.
***if there are no other hosts that can satisfy the request, then distribute data to other idle and capable hosts. Load is now reduced on the one link.
*QoS
*bandwidth management/scheduling (similar to OS scheduling)
**utilizing a round robin schedule to allow for periodic increases in bandwidth per user
**priority system that allows for more critical operations being done by a user to take precedence over others
*have the bandwidth separated evenly across all users and allow for users to donate their bandwidth amount for others to use, but can revoke it at any time

Distributed OS: Winter 2011

2011-01-18T21:59:20Z

Ajluczak: /* 3: Limiting the spread of malware */