HereToThere: Market-Based Mechanisms for Allocating
Agents to Location-Based Tasks
by
Dennis Gregorovic
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Computer Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 22, 2000
) Copyright 2000 Massachusetts Institute of Technology
Author
Department of Electric&
Engineering and Computer Science
May 19, 2000
Certified
by
v
iSu
Pattie Maes
rvisor
Accepted
by
Ar hur C. Smith
Chairman, Department Committee on Graduate Theses
ENG
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
JUL 2 7 2000
LIBRARIES
HereToThere: Market-Based Mechanisms for Allocating
Agents to Location-Based Tasks
by
Dennis Gregorovic
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Computer Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 22, 2000
Abstract
This thesis proposes a new approach to the vehicle routing problem. The vehicle routing
problem is defined as deciding how to allocate a fleet of delivery vehicles to a number of
parcels needing delivery in order to optimize some goal and subject to constraints.
Current solutions tend to be centralized and narrow in focus. The solution proposed here
is the use of market-based mechanisms that allow vehicles to bid for parcels. The
specific method presented in this thesis is a sealed-bid competitive auction where
vehicles bid for parcels along a set of parameters such as cost and delivery speed and the
parcels choose the winning vehicle. Each parcel and each vehicle has an agent that
makes bidding decisions based on individual utility functions. Benefits of this system
include efficiency, scalability, and feasibility in a wide range of certain situations. An
interactive simulator was written in Java that has supported these conclusions.
3
4
Table of Contents
1
2
Introduction
11
1.1 The Problem ..................................................................................................
11
1.2 Current Approaches.......................................................................................
11
1.2.1
Taxis..................................................................................................
11
1.2.2
Courier Services ................................................................................
13
1.2.3
Packet Routing ..................................................................................
14
1.3 New Approach................................................................................................
15
1.4 Roadm ap to the thesis.....................................................................................
17
Related Work
19
2.1 M arkets for Resource Allocation ..................................................................
19
Case Studies .......................................................................................
20
2.2 Vehicle Routing Problem ..............................................................................
22
2.1.1
3
2.2.1
Routing..............................................................................................
22
2.2.2
Allocation.........................................................................................
23
The HereToThere Simulator
25
3.1 Important A spects..........................................................................................
26
3.1.1
Tim ing ................................................................................................
26
3.1.2
Order of Operations............................................................................
26
3.1.3
Bidding ..............................................................................................
26
3.1.4
M ap.....................................................................................................
27
3.1.5
Vehicles..............................................................................................
27
5
3.1.6
4
5
6
Parcels ..............................................................................................
30
3.2 U ser Interface .................................................................................................
30
3.2.1
U ser M ode..........................................................................................
32
3.2.2
Batch M ode........................................................................................
32
3.3 A rchitecture ...................................................................................................
33
Experiments & Initial Results
35
4.1 Evaluating D ifferent Strategies......................................................................
36
4.2 Scalability.....................................................................................................
43
4.3 Feasibility .......................................................................................................
43
Future Work
47
5.1 Realistic Environm ents..................................................................................
47
5.2 Timing ...............................................................................................................
47
5.3 Im proved A lgorithm s...................................................................................
48
5.4 Reputation .....................................................................................................
49
5.5 U ser Interface ................................................................................................
49
5.6 Subcontracting...............................................................................................
50
5.7 M ultiple Bids Per V ehicle............................................................................
51
Conclusion
53
Appendix A - Important Simulator Classes
55
References
59
6
List of Figures
Figure 1 Bidding process with the use of a gateway...................................................
16
Figure 2 H ereToThere application..............................................................................
25
Figure 3 Sample HereToThere Simulator Screenshots..............................................
31
Figure 4 Sample input file for batch mode...................................................................
33
Figure 5 Parcel Sensitivity Levels..............................................................................
37
Figure 6 Effect of Price Sensitivity on Delivery Cost and Delivery Time .................
38
Figure 7 Effect of Bidding Strategy on Delivery Time and Distance Traveled..........40
Figure 8 Effect of Parcel Intelligence on Global Optimization ..................................
42
Figure 9 Delivery Times for Different Bidding Radii.................................................
45
7
8
Acknowledgements
My biggest thanks go to the Software Agents group. I have learned so much this past
year from hanging out with everyone in the group and I have truly enjoyed my time there.
I wish it didn't have to end so soon, but best of luck to everyone.
I have a ton of gratitude for Pattie Maes who took me into the Software Agents group.
She has been a pleasure to work with and a great thesis supervisor.
TK4D to Bob Broderick and Ben Krinsky for being great fraternity brothers in addition to
awesome classmates.
Finally, I would also like to recognize my mother who helped me get into MIT and has
been helping me keep on track ever since.
9
10
1
Introduction
1.1 The Problem
The problem being looked at in this thesis revolves around a situation in which a number
of parcels appear at different locations randomly over time, and these parcels need to be
delivered to different destination points. There is a fleet of vehicles that performs the
delivery of these parcels. Given this situation, the problem at hand is deciding which
vehicles should be assigned to deliver each parcel, and doing so in a way that maximizes
the utility of both the parcels and vehicles.
1.2 Current Approaches
The parcel delivery problem is quite common in today's society in a number of various
forms. One example is the use of taxis in large cities to deliver people. Courier services
like the Post Office, Federal Express, and UPS are another. Even the problem of packets
being routed through the Internet can be viewed as an instance of this problem.
Specific circumstances of each of these examples have led to different solutions. Here is
an overview of them:
1.2.1
Taxis
The taxi industry has been around for a long time and, especially in the United States,
tends to be very fragmented. It is not only fragmented in terms of companies but also
11
with respect to business plans. Some taxi companies own and operate all of their vehicles
and use drivers as salary employees. Other companies own the vehicles but lease them to
drivers for a fixed cost per day and then the drivers keep all of the revenue they bring in.
In other cases the taxi companies don't own any vehicles but act purely as a fee-based
dispatching service. Finally, some taxi drivers own their own taxi and simply ride around
looking for fares without the use of a dispatch system at all. One effect of this chaos in
the taxi industry is that it has been very slow to innovate or adopt new technology. Most
taxi services still operate through a central radio-based, company-specific dispatch
system. The primary problem with this type of system is that a dispatcher has minimal
current information about the fleet of taxis - a dispatcher only has a vague idea where
each taxi is, does not know which drivers are on break, may not know about local traffic
conditions, etc. In order to decide which taxi to send to a particular job, the dispatcher
must go through a slow dialog process with a number of drivers and may ignore
important considerations like traffic in order to make the decision quicker.
That said, there are some strides being made in the taxi industry. Sigtec and Digital
Dispatch are the two leading companies integrating technology with fleet management
and vehicle dispatch for the taxi industries [5][18]. In 1996, Sigtec used Singapore as a
test bed for the world's first automated taxi system.
This system integrated GPS
technology for locating taxis with a mobile data network and a computerized dispatch
service.
With this system, once a passenger's pickup location is known the nearest
available taxi can be dispatched automatically.
It is estimated that this system has
reduced the average time taken to dispatch a taxi from five minutes to thirty seconds [8].
12
Since the initial launch in Singapore, Sigtec has launched this system in Sydney and
China. Digital Dispatch has developed similar systems and has sold them to taxi
companies in the United States and Canada. Digital Dispatch uses a slightly smarter
dispatching algorithm that weighs in vehicle type and vehicle capabilities (e.g. van vs.
sedan) in addition to distance from parcel [6].
The bottom line is that in taxi industry the integration of technology is happening,
although at a rather slow pace. However, the fundamental approach has not changed.
The process remains that a passenger requesting a taxi contacts a specific taxi company
with his current location, and that taxi company sends the closest available and suitable
taxi to pick up the passenger.
1.2.2
Courier Services
At first glance, courier services like the United States Post Office, FedEx, DHL, and UPS
appear to be in a much different business than your local taxi company, but in fact, they
are all primarily delivery service providers. It's just that courier services deliver a lot
more and often much farther. FedEx alone uses more than 37,000 vans and trucks and
about 550 planes to deliver 3 million packages daily to 211 countries [8]. Given the
enormous size of the delivery problem that a company like FedEx has, it is obvious that a
one parcel per vehicle end-to-end solution isn't going to work. What FedEx and the other
companies have adopted is the hub and spoke model, which is a multi-tier solution where
parcels are aggregated at the local level, transported in bulk, and then delivered to their
final destinations. One benefit of a solution like this is the use of efficient transportation
vehicles for each level, such as airplanes for long distance bulk transport and small trucks
13
for local pickup and drop-off. This model is different from the taxi industry, but within
tiers of the hub and spoke they face similar issues. The solutions used by courier services
are commonly pre-determined allocation plans. For example, FedEx often assigns local
delivery trucks to specific zones and then each truck is responsible for all pickups and
drop-offs in that zone.
Similarly, Post Office deliverymen and delivery trucks have
assigned routes that they follow every day.
Because the courier service industry is dominated by a small number of companies and is
highly competitive, it has seen much more of a technological push. FedEx alone spent
more than $1
billion in 1997 on IT investments [15]. The result of this has been
extremely tight integration of technology with the delivery process. This includes parcel
tracking over the web, location-awareness of all delivery vehicles, hardware and software
solutions for companies to automate large number of delivery requests, electronic
signature capture, and more. However, technology has not fundamentally altered the
courier services industry, it has simply made its existing infrastructure more efficient.
1.2.3
Packet Routing
The Internet, while an entirely different entity than either taxis or courier services, also
faces the problem of how to deliver a number of dynamically arriving parcels. When
data is sent across the Internet it is first broken down into small chunks of data called
packets. These packets are then sent individually and the original data is reconstructed
from these packets at the destination computer. Rarely are packets sent directly from the
source computer to the destination computer.
Instead, packets start at the source
computer and "hop" from computer to computer until they reach their destination. These
14
computers in the middle are called routers and they decide which route each parcel
should take to reach its destination. Therefore, formulated as a delivery problem, the
parcels are packets of data and routers are the vehicles.
Each router is connected to a small number of other routers. When a router receives a
packet, it must decide among the routers it is connect to which one it should use to send
the packet onto. The goal of this decision is to minimize the number of hops the packet
must make to reach its destination. To simplify a bit, the way that routers decide where
to send packets is by keeping a table of every IP address and associating with each
address the router with the lowest hop count. When a packet arrives, the router simply
looks up the IP address of the packet's destination computer and sends the packet to the
router associated with that address in the table [3][16]. The state of the Internet changes
frequently as connections are lost or made and machines come up or go down. So, in
addition to routing packets, routers also communicate with each other to ensure that their
tables are up to date.
1.3 New Approach
The approach that I propose is the use of market-based system [4] where vehicles bid for
parcels and the bidding process determines the allocation of parcels to vehicles.
Specifically, this system works as follows. When a new parcel arrives and needs to be
delivered it will send out a Request For Bid (RFB). If the parcel is able to communicate
directly to the vehicles then the RFB is sent straight to them. Otherwise, a gateway is
used to take the RFB and forward it to the vehicles. As soon as each vehicle receives an
15
RFB it composes a BID. A BID can contain any set of parameters depending on the
scenario. Likely parameters include delivery time, cost of delivery, vehicle information,
etc. The vehicles then send these BIDs back to the parcel (or back to the gateway which
forwards them to the parcel).
which vehicle it prefers.
Once the parcel has received all of its BIDs it decides
It sends a positive acknowledgement to that vehicle and
negative acknowledgements to the rest. At this point the winning vehicle is assigned to
that parcel and the allocation process is over.
Vehicle 2
RFB
ID_1
RFB3
RFB
Parcel
BID_2 F-Vehicle 2
-qGateway
BID_2
BID 2BI3
BID_3
_
RFB
Vehicle 3
Figure
1 Bidding process with the use of a gateway
This approach is different than the taxi and courier service examples discussed before in
that a decentralized market is being used to dynamically allocate vehicles instead of a
using a centralized dispatcher or having a priori assignments. In a sense routers do use a
16
market-like mechanism in that routers "bid" with their hop-count, and the lowest bid
wins. This new approach is also different than the other others described in that it is the
parcel that decides which vehicle to use and not the other way around.
1.4 Roadmap to the thesis
Chapter 2 presents work that is related to this thesis. The theory behind this thesis draws
on the literature in the Dynamic Vehicle Routing problem and the use of markets for
resource allocation. The related works are divided up accordingly.
Chapter 3 will discuss the HereToThere simulation.
This simulation represents a
majority of the time spent researching this thesis. It was critical for both evaluation
purposes and for gaining insight into the effects of a market-based system in action.
Chapter 4 presents several experiments conducted using the HereToThere simulator
along with some initial results.
Chapter 5 contains discussion on future work and implementation issues.
Finally, Chapter 6 will present concluding remarks.
17
18
2 Related Work
Two distinct bodies of research directly relate to the focus of this thesis. The first is the
use of markets for resource allocation, which has been a popular topic in both economics
and software agent research and has been used to attack problems as diverse as
distributed computing and pollution control.
The second body of relevant research
focuses on developing solutions to the problem of dynamic vehicle routing, a variation of
the deterministic vehicle routing problem, which has been studied extensively in
operations research.
2.1 Markets for Resource Allocation
The problem of resource allocation is deciding how to allocate a set of tasks among a
limited amount of resources in such a way as to maximize the efficiency of the system. A
common example is distributed computing where programs are split up among a set of
processors with the goal of minimizing the time necessary to run all of the programs.
Traditional solutions have used centralized controller such as a task scheduler, which is a
master process in charge of assigning the other processes to computers.
Recent research has explored the use of markets as an alternative solution. Any system
where buyers and sellers come together to trade goods can be considered a market, and
obviously there are many examples of markets in our world today such as the New York
Stock Exchange, flea markets, eBay, and more. There are many benefits to a market-
19
based system, but often the primary reason for using one is that it allows for control of
complex and dynamic situations through simple means. [1]
2.1.1
Case Studies
Enterprise
Enterprise is a system developed at MIT in the mid 80's that uses markets to allocate
processing tasks among a network of computers. [12] Enterprise and HereToThere share
a similar bidding mechanism. In Enterprise, when a processing task is created it sends
out a Request For Bid (RFB) to all of the computers on the network. Each idle computer
returns a Bid estimating how long it will take that computer to finish the task. Enterprise
does differ from HereToThere in that as soon as a processing task receives a Bid it
immediately accepts it. Then, as it continues to receive more bids it looks to see if any
are "considerably better" and, if so, cancel the task where it's currently running and start
it on the new computer.
This type of a cancellation system would not work in
HereToThere because the effective cost of "task switching" is much higher due to the
location-based nature of the problem. In other words, in Enterprise a computer's ability
to service a task depends on that computer's hardware and whether it is currently idle or
busy. In HereToThere, a vehicle's ability to deliver a parcel depends on that vehicle's
capabilities and current delivery status, akin to Enterprise, but it also depends the location
of the vehicle, which constantly changes as it delivers.
Another unique aspect of Enterprise is a priority system where certain processing tasks
are more important than others. In HereToThere all parcels and all vehicles are equal in
20
the eyes of the market. However, there are still ways to implement a priority system in
HereToThere that will be discussed in the future work section.
Pollution Permits
The trade of sulfur dioxide permits as dictated by the 1990 Clean Air Act is probably the
most novel example of market use for resource allocation. At the beginning of each year
every regulated facility receives a certain number of "pollution permits." During the year
these facilities can buy and sell the permits among themselves and at the end of the year
each facility must own enough permits to cover the amount of pollution it produced
during the year. The system was designed to help reduce to cost of pollution control for
the facilities. The logic is that the facilities that can efficiently reduce emission will do so
and sell their extra permits while the other facilities will buy those permits to cover their
extra emissions.
The designers of the market mechanisms for pollution permit trade faced a much
different set of needs than in the Enterprise system. For one thing, pollution permit trade
has both buyers and sellers whereas Enterprise was only interested in buyers. In addition,
for pollution permit trade it was desirable to allow bundled trades where combinations of
different permit types are bought or sold together. Another difference is that the volume
of trade of pollution permits is much thinner. Thinner volume usually makes it more
difficult to match up buyers and sellers and was a problem that needed to be addressed.
The solution that the designers came up with is a double-sided combinatorial call auction.
In this auction, any facility interested in buying or selling permits must enter their bids by
21
a specific date. Bids can be conditional on other bids, allowing for bundling. At the
specified date, an algorithm is run on all of the bids to determine prices for all of the
permits with the goal of maximizing the total market surplus in an unbiased manner
towards either buyers or sellers. [11]
2.2 Vehicle Routing Problem
The common definition of the vehicle routing problem (VRP) is, given a set of customer
locations and a set of vehicles, deciding how to visit each of the locations [1].
The
objective is to minimize some function (e.g. total distance traveled) and is usually subject
to some constraints (e.g. the capacity of the vehicles). Although the name implies that
vehicle routing is the sole focus of the problem, there are actually two key aspects routing and allocation. The routing problem is deciding in what order a vehicle should
visit customer locations while the allocation problem is deciding which vehicle should
visit each specific location.
2.2.1
Routing
Vehicle routing problems can divided along the lines of static vs. dynamic. In a static
VRP the list of customer locations is known a head of time and the problem can be
solved deterministically.
This is akin to the traveling salesman problem and has been
extensively covered in the research literature [8].
A dynamic VRP deals with situations where customer locations are not know in advance
but appear over time. Because of the combinatorial complexity of routing decisions, it is
22
usually infeasible to use an optimal algorithm in practice where routing decisions must be
made quickly. Instead, a wide range of heuristics has been developed that have shown to
be near optimal [1]. One of the key benefits of using a market for vehicle allocation is
that each vehicle can use whatever routing algorithm it likes and it makes no difference to
the market itself.
2.2.2
Allocation
Allocation on the other hand is extremely relevant since that is the responsibility of the
market-based mechanisms in HereToThere. Virtually all the research of allocation in the
VRP has taken the same form. When a new parcel arrives, the central controller tests
each vehicle with the new parcel to see which assignment maximizes the overall
objective function.
The best vehicle then is assigned to that parcel. [19] This is
fundamentally different from the approach taken in this thesis in that the thesis does not
assume an overall objective function nor does it require a central coordinator to perform
the allocation.
23
24
3 The HereToThere Simulator
To test the ideas of this thesis both quantitatively and qualitatively I wrote a simulator in
Java called HereToThere that is shown in Figure 2. HereToThere sets up and executes
the basic framework of vehicles bidding for and delivering parcels as they randomly
appear in a uniform Euclidean space. In this section I will first describe the different
aspects and workings of the simulator. Then I will present an overview of the user
interfaces. Finally, I will discuss the architecture of the program.
Figure 2 HereToThere application
25
3.1 Important Aspects
3.1.1
Timing
Timing in the simulator is done entirely via discrete clock ticks. Using the system clock
to do timing is unreliable because it can vary widely depending on the hardware,
operating system, and other programs running. By using clock ticks these concerns are
eliminated. The only drawback is that the performance of the code in the simulator itself
is no longer reflected in the timing. However, this is acceptable since the code for most
of the simulations runs on the order of milliseconds (although the user interface can be
considerably slower), which would be a trivial amount of time in most real-world
situations. Scalability concerns are addressed in the evaluation section.
3.1.2
Order of Operations
Everything in the simulator is run in a serialized fashion. At every tick of the clock the
following events occur in order:
1) All existing parcels that have not found a vehicle yet initiate an auction.
2) Any new parcel looks for a vehicle by initiating an auction.
3) Every vehicle that is picking up or dropping of a parcel moves one unit towards its
destination.
3.1.3
Bidding
For simplicity's sake, bidding is done by one parcel at a time. When a parcel is looking
to be delivered, it sends a request for bids (RFB) to every vehicle it can communicate
with, which are all vehicles by default. However, there is an option to enable a Limited
26
Bidding Radius of arbitrary size. If the Limited Bidding Radius is enabled then each
parcel can only send an RFB to each vehicle that is within that radius of the parcel.
Every vehicle that receives an RFB responds with either a bid or an empty bid. A bid
specifies how long it will take that vehicle to pickup the parcel and how long it will take
that vehicle to drop off that parcel after it is picked up. It may also specify the price that
the vehicle will charge the parcel for delivery. An empty bid indicates that the vehicle is
currently unable to deliver that parcel. Once the parcel has received either a bid or an
empty bid from all of the vehicles then it picks the bid that maximizes it utility. It sends
an acknowledgement to the vehicle that "won."
No acknowledgement is sent to the
"losers" so they infer by lack of acknowledgement that they have lost.
3.1.4
Map
In the simulator, the area in which all of the delivery action takes place is a uniform
Euclidean area represented by a rectangular grid with only discrete integer coordinates.
Travel can only be either horizontal or vertical, and all distances (including a Limited
Bidding Radius) are calculated using Manhattan Distance.
3.1.5
Vehicles
There are two types of vehicles in the HereToThere simulator - taxis and trucks. These
vehicles are very similar except for one key difference. By nature taxis are only allowed
to carry one parcel at a time. In practice this parcel may be one person or a group of
people, but we still treat it as a single object and ignore for simplicity's sake any unusual
circumstances such as multiple drop off locations. Trucks on the other hand usually can
27
transport a large number of parcels at a time. These vehicle properties are represented in
the simulator as capacity constraints where taxis have a capacity of 1 and trucks have an
arbitrary capacity > 1.
All vehicles have the same speed of one map unit per clock tick. Each vehicle can use
one of two driving heuristics for deciding how to get from one point to another. The first
is Horizontal-Then-Vertical where the vehicle first goes all the way horizontal and then
all the way vertical. The other driving method is Alternate-Horizontal-Vertical where the
vehicle alternates moving horizontally and vertically until it reaches its destination.
Each vehicle also has a choice of several bidding strategies (although each vehicle must
use the same bidding strategy throughout a simulation run). These bidding strategies are:
1. Random
If the vehicle is currently picking up or dropping off a parcel then an empty bid is
returned. Otherwise, random pickup and drop off times are returned.
2. Simple
Again, if the vehicle is currently picking up or dropping off a parcel then an
empty bid is returned. Otherwise, pickup and drop off times are calculated based
on the vehicle's distance from the parcel and the distance that the parcel needs to
be delivered.
3. Queue
With the Queue strategy the vehicle always returns a bid.
If the vehicle is
currently idle then the bid returned is the same as with the Simple strategy. If the
28
vehicle is busy, then the pickup and drop off times returned are calculated based
on the vehicle's current delivery schedule. For example, let's say some taxi is
heading to pick up parcel A and gets an RFB from parcel B.
The taxi will
respond with a pickup time that is the sum of how long it will take the taxi to 1)
pickup up parcel A 2) drop off parcel A 3) pick up parcel B. With this strategy
each vehicle maintains a queue of future jobs in addition to its current one.
Taxis and trucks implement their queues in slightly different fashions. Taxis use
a First Come First Served method where new parcel requests are always put at the
end of the queue. Trucks on the other hand insert new parcels into their existing
queue in whichever location minimizes their total travel distances. In addition,
trucks may split up a parcel's pickup from its drop-off in the queue as long as a)
each parcel is picked up before it is dropped off and b) there are never more
parcels in the truck than the truck's capacity. [19]
4. Center Hub
This is an extension to the Queue strategy that employs the use of a hub in the
center of the board. Vehicles using this strategy are assigned to one of the four
quadrants of the board and only travel within their quadrant. Deliveries are routed
through the hub if they cross quadrant boundaries.
These strategies are admittedly simplistic. However, the focus of the thesis is not on
finding optimal routing algorithms but for providing a framework for different routing
algorithms to be used. These bidding strategies were implemented more as a proof of
concept that the system works even when different vehicles use different strategies, and
29
that the choice and distribution of strategies does have an impact on the effectiveness of
parcel delivery.
3.1.6
Parcels
There is only one type of parcel in HereToThere although parcels are allowed to have
varying degrees of price sensitivity.
In HereToThere the parcels appear at random
locations with random destinations.
The parcels appear one at a time in a Poisson
distribution with a mean that is specified by the 'Parcel Frequency' - a parameter
configurable by the user.
3.2 User Interface
HereToThere has two primary modes of operation: User Mode and Batch Mode. User
Mode has an interactive graphical user interface that allows the user to run simulations
with a variety of parameters and displays statistical analysis of each simulation run.
Batch Mode is command-line driven and is used for data collection.
30
Figure 3 Sample HereToThere Simulator Screenshots
31
3.2.1
User Mode
User mode is centered around a graphical user interface built using Java Swing. The GUI
is divided into three major sections. See Figure 3. The first section allows the user to
specify a number of system parameters and to start, stop, and resume a simulation run.
The focus of the second section is a map that shows the position and state of every
vehicle and active parcel. This section of the screen also has a slider bar to control the
speed of the simulation, and toggle button for disabling map updates, and a legend to
explain the symbols in the map.
The third section presents information about each
simulation as its being run. This information includes the current clock tick count, the
number of parcels delivered, and the average pickup, drop off, and delivery times. It also
has charts of the average pickup and delivery times; and detailed information about any
vehicle, parcel, and hub that is selected. These objects become selected when the user
clicks on one of them in the map with a mouse.
3.2.2
Batch Mode
Batch mode is designed for data collection. At the command line an input file must be
specified. This file contains a list of system parameters that describe what simulations to
run.
See Figure 4. Each line in this file specifies a system parameter along with a
minimum value, a maximum value, and a step value for that parameter. If the parameter
is a vehicle than it also specifies what bidding strategy those vehicles should use. The
min, max, and step values are used to calculate a list of values for each parameter (e.g. 5
x 15 x 5 would yield the list 5, 10, 15). Multiple simulation configurations can be listed
in a single file using the word "GO" to separates each one. Once HereToThere reads in
32
the file, it runs a simulation for every Cartesian product of the system parameters. This
allows for easy testing of the effect of several system parameters independently.
parcels 100 x 100 x
frequency 40 x 40 x
truck QUEUE 10 x 10
iterations 50
GO
parcels 100 x 100 x
frequency 40 x 40 x
taxi SIMPLE 10 x 10
taxi QUEUE 5 x 10 x
iterations 50
GO
1
5
x 5
1
5
x 5
5
Figure 4 Sample input file for batch mode
3.3 Architecture
HereToThere was written in Java using Sun JDK 1.2.2 on a Windows 2000 platform.
Java was chosen as the language not only for its ease of use and portability, but also
because its object oriented nature nicely complemented the problem being solved. In the
simulator there are separate Vehicle and Parcel classes as well as Taxi and Truck
subclasses.
There are several other key classes including a Vehicle Manager that
facilities communication between parcels and vehicles, a Parcel Manager that creates
parcels at the appropriate times, a Hub Manager that coordinates the use of hubs, a Bid
Response class for describing bids, and an Algorithm class for enumerating different
bidding strategies. Relevant interfaces to these classes are listed in Appendix A.
Several other classes play an integral role in the simulator but are not a part of the
market-based framework itself. The first two are Main and Simulation, which are the
foundation of the program.
Another important class is MyTimer, which runs as a
33
separate thread and is responsible for producing clock ticks. InputUl, DisplayUl, and
OutputUl comprise the three panels on the GUI. JBarChart and Display are used for the
charts and map respectively. Finally, there is a DataCenter object that records all of the
data during a simulation run, which is either shown in the GUI during User Mode or
outputted during Batch Mode.
34
4 Experiments & Initial Results
Rigorous quantitative evaluation of the framework presented in this thesis is difficult
because the framework is generic enough to work for a wide range of scenarios, each of
which could be evaluated independently along several different metrics. So, what I have
done is come up with a list of important properties that the framework should provide and
then tested to see how these properties are evident using the HereToThere simulator.
These properties are 1) efficiency of homogeneous and heterogeneous environments 2)
scalability 3) feasibility. Efficiency of homogeneous and heterogeneous environments
means the system should work well for scenarios where all delivery and parcel agents use
the same strategies with the same utility functions as well as scenarios where the agents
have individually differing strategies and / or utility functions. Scalability is the ability of
the system to maintain performance levels as the number of vehicles and parcels
increases.
Feasibility is whether the system is actually able to work (i.e. parcels get
delivered) under specific scenarios.
All of the simulations run used the following defaults unless otherwise specified:
Map Size: 300 x 300 units
Number of Parcels: 100, all price insensitive
Mean Parcel Arrival Interval: 40 clock ticks
Vehicles: 10 taxis using SIMPLE bidding strategy
Limited Bidding Radius: none
35
Given a map size of 300 by 300, the average distance between two random points is 200
units. Also, with 10 vehicles, the expected minimum distance between a parcel and any
vehicle is 65 units. Therefore, the best-case expected delivery time is 265 clock ticks (65
for pickup + 200 for delivery).
4.1 Evaluating Different Strategies
One of the greatest benefits of using a market-based system is the variety of potential
participants.
Any vehicle or parcel that is able to use the proper protocol for
communication and follows the bidding convention of the system can participate in the
market irrespective of implementation, utility function, or bidding strategy. This allows
for the traditional homogeneous examples that have been the focus of dynamic vehicle
routing literature as well the heterogeneous systems one would likely find in real-world
examples.
Two simple experiments were run to test the effects of homogeneity and heterogeneity.
In the first test, delivery prices were introduced as a bidding factor to see how price
sensitivity affects vehicle allocation. A series of simulation runs were conducted where
all of the parcels had the same level of price sensitivity within a run but changed between
runs. The four levels of price sensitivity are given by the utility functions in Figure 5. As
for the taxis, a random half of them charged $1 per delivery and the other half charged $2
per delivery. This was then repeated using the prices of $1 and $3. The results in Figure
6 clearly show that increased price sensitivity resulted in lower average delivery cost and
longer average delivery time. The explanation for this is that as parcels become more
36
price sensitive they choose the "cheaper" vehicles more often. This results in lower cost
per delivery. It also raises the average delivery time since the parcels are passing up
shorter delivery in favor of cheaper delivery.
The "correct" ratio of delivery cost to
delivery time is dependent upon price sensitivity. In this situation, a central controller
could not make the correct allocation without knowing the price sensitivity of the parcels.
Insensitive:
utility = 1000 / delivery time
Somewhat Sensitive:
utility = 1000 / (delivery time * price)
Moderately Sensitive:
utility = 1000 / (delivery time * price ^ 2)
Extremely Sensitive:
utility = 1000 / (delivery time * price ^ 3)
Figure 5 Parcel Sensitivity Levels
37
Effect of Price Sensitivity on Delivery Cost
A(0
0
L)
2.50
-
2.00
-
1.50-
4)
1.16
1'01.02
1.000.50
Prices = 1,2
--. *--Prices= 1, 3
-
0.00
not sensitive
moderately
sensitive
somewhat
sensitive
very sensitive
Price Sensitivity
Effect of Price Sensitivity on Delivery Time
1800
-
1600
1600
1400
1200
0
01171
-.
1128
-U--- Prices = 1, 2
1000
*E
800
.a)
~0
600
400
- -18
--
-- Prices= 1,3
.- .-- '34
200
0
not sensite
somewhat
sensitive
moderately
sensitive
\.ery sensitive
Price Sensitivity
I
Figure 6 Effect of Price Sensitivity on Delivery Cost and Delivery Time
Cost values and delivery time are an average per delivery over each set of 50 simulations runs. Within
each set of simulation runs all parcels had the same price sensitivity. In all simulations there were five
taxis that "charged" $1 per delivery. Half of the sets of simulations had an additional five taxis that
"charged" $2 and the other half sets of simulations had additional taxis that "charged" $3.
38
The second set of simulations performed was focused on different vehicle bidding
strategies. Here, all parcels were price insensitive and again there were 10 taxis per run.
This time, however, some of the taxis used the SIMPLE strategy while others used the
QUEUE strategy. With the SIMPLE strategy, taxis that are idle return a bid equal to the
time it would take to pickup and drop off the parcel. Taxis that are idle do not respond
with a bid. The QUEUE strategy works the same for idle taxis, but taxis that are busy
return a bid equal to the amount of time it will take to first deliver their current parcel
plus any additional parcels they have waiting for them and then deliver the new parcel.
As you can see in Figure 7, the average delivery time dropped by almost half when all of
the taxis used QUEUE versus when they all used SIMPLE, which was to be expected
since the QUEUE bidding strategy is able to give better bids than the SIMPLE bidding
strategy. In addition, the total distance traveled by the taxis also decreased with use of
the QUEUE strategy. So, switching to QUEUE from SIMPLE is a "win-win" move
because the parcels benefit from quicker delivery and the taxis benefit from shorter
distance traveled. However, Figure 7 does reveal an unexpected result, which is the spike
in delivery time that occurs when there is one taxi using QUEUE. Why is it that when
one taxi improves its strategy all of the parcels suffer?
39
Effect of Bidding Strategy on Delivery Time
2000
1800
1600
e1400
1200
1000
600-
-
.
400
200
0
Queue: 0
Queue: 1
Queue: 2
Queue: 3
Queue: 4
Queue: 5
Queue: 6
Queue: 7
Queue: 8
Queue: 9
Queue: 10
Sirrple: 10
Sirrple: 9
Simple: 8
Simple: 7
Sirrple: 6
Simple: 5
Simple: 4
Sirple: 3
Simple: 2
Simple: 1
Sirple: 0
Distribution of Taxi Strategies
4
Parcel Frequency = 40 clock ticks -. -A--- Parcel Frequency = 30 clock ticks
Effect of Bidding Strategy on Distance Traveled
43000
-o 41000
Z 39000
2 370000 35000--
.
33000 31000 - -
-1---
5
ii 290000 27000 --
---
-- -
25000
Queue:
1
Queue:
2
Queue:
3
Queue:
4
Queue:
5
Queue:
6
Queue:
7
Queue:
8
Queue:
9
Queue:
10
Simple: Simple:
9
10
Simple:
8
Simple:
7
Simple:
6
Simple:
5
Simple:
4
Simple:
3
Simple:
2
Simple:
1
Simple:
0
Queue:
0
Distribution of Taxi Strategies
- Parcel Frequency = 40 clock ticks -- -A--- Parcel Frequency = 30 clock ticks
Figure 7 Effect of Bidding Strategy on Delivery Time and Distance Traveled
For each set of simulation runs there were 10 taxis with some using the SIMPLE bidding strategy and the
rest using the QUEUE bidding strategy as shown on the horizontal axis. For half of the simulation sets the
mean parcel frequency was 40 clock ticks and the other half had a parcel frequency of 30 clock ticks.
Delivery times are an average per delivery. Distance traveled is total distance for all taxis per simulation.
The error bars show one standard deviation in each direction.
40
The reason for this is that taxis using SIMPLE will not respond to an RFB if they are
busy while a taxi using QUEUING will always respond. During the simulation, when the
taxis using SIMPLE were all busy then new parcels would only receive a bid response
from the taxi using QUEUING, and since this was the only bid they received they would
use it no matter how bad it was. Indeed, because of this that one taxi got to deliver
disproportionably large share of the parcels, so it succeeded in its goal of local
optimization at the expense of overall parcel utility. Now, the question is whether this is
"bad" and if so, what's to blame. I would say that it is not bad - it's just the result of the
market. However, it's also not ideal, as we would like competition amongst the vehicles
to not only benefit themselves but the parcels as well. There are two solutions to this
which are two sides of the same coin - either improve the vehicle strategies or improve
the parcel strategies.
In the first case, it was shown that parcel delivery performance
increases as soon as three or more of the taxis adopt the QUEUING strategy. We could
imagine that in the real world if there was a taxi doing significantly better than the other
taxis would strive harder to compete. The other solution is to increase the intelligence of
the parcel's agent. While the HereToThere marketplace does not allow parcels to switch
vehicles once they have accepted a bid, they are allowed to refuse any bid they don't like.
If an agent knows that the bids it receives may change over time then one way to improve
it would be to set an upper limit on the delivery time it is willing to accept. This was
done in HereToThere by setting a worst-case delivery time of 1200 clock ticks, which is
roughly four times the ideal delivery time. If the best bid received by a parcel was for a
delivery time of more than 1200 clock ticks then that parcel refused all of the bids and
41
sent out a new RFB at a later time in hopes of getting a better bid. Using this parcel
strategy, the test was rerun and the results shown in Figure 8 confirm the theory.
Effect of Parcel Intelligence on Global Optimization
2000
1800
1600
10 1400
E
S1200
Z; 1000
cm
A---
800
0
<600
400
200
0
Queue: Queue: Queue: Queue: Queue: Queue: Queue: Queue: Queue: Queue: Queue:
10
9
7
8
6
5
4
3
2
1
0
Simple: Simple: Simple: Simple: Simple: Simple: Simple: Simple: Simple: Simple: Simple:
0
1
2
3
4
5
6
7
8
10
9
Distribution of Taxi Strategies
--
Always Accept Best Bid - - 0
- - Accept Best Bid If Below Threshold
Figure 8 Effect of Parcel Intelligence on Global Optimization
Delivery times are an average per delivery over 50 simulation runs and the error bars show one standard
deviation in each direction. For each set of simulation runs the mean parcel frequency was 30 clock ticks
and there were 10 taxis with some using the SIMPLE bidding strategy and the rest using the QUEUE
bidding strategy as shown on the horizontal axis. For half of the simulation sets the parcels always chose
the bid with the lowest delivery time. For the other half the parcels only chose the bid with the lowest
delivery time if the delivery time was less than 1200 clock ticks. Otherwise, they accepted no bid and kept
requesting bids until a suitable one was found.
42
4.2 Scalability
How well a system scales is a relationship of the resources it requires as the size of its
inputs increases. A distributed framework like the market-based system used here scales
better than a central controller system for two reasons. First, because each parcel and
vehicle is responsible for its own bidding, the processing demand is distributed among all
of the objects instead of a single controller. In addition, the computational demands
placed on parcels and vehicles are minimal. Parcels have to calculate the utility of each
bid they receive, so the amount of work for each parcel is 0 (V) where V is the number
of vehicles. Vehicles have to compute a bid for every RFB so the amount of work that
vehicles have to do is 0 (P) where P is the number of parcels. The second reason why
the HereToThere system scales well is low bandwidth.
The only information being
transferred is RFBs and bids, which are both minimal in size and there are only 0 (VP) of
these transmitted.
4.3 Feasibility
There are some scenarios where a centralized system can't work at all. The best example
is ad-hoc networks composed of devices with a limited transmission radius. Developing
efficient systems that work with ad-hoc networks is becoming especially important these
days with the proliferation of handheld devices and standards soon to be quickly adopted
such as Bluetooth [2]. Because of the small transmission radius, each device can only
communicate with other agents around it, and even with the use of multi-hop systems
they may not be able to reach a central server. Still, using market-based mechanisms
43
these devices can buy and sell delivery tasks to the agents nearby. The HereToThere
simulator mimicked this ability by having a Limited Bidding Radius mechanism.
If
enabled, parcels could only communicate with vehicles within the specified radius.
When a new parcel appears with a limited bidding radius, if there is no vehicle close by at
that moment it must wait until a vehicle comes by.
performance.
This results in a drop-off in
How much performance drops is very dependent on the length of the
bidding radius and whether the parcels have thresholds for accepting bids. This is shown
in Figure 9. In extreme cases (radius < 75) delivery times can be 10 to 20 times worse
than with an unlimited bidding radius. However, at least the parcels are being delivered
which would not be possible in the central controller scenario.
44
Delivery Times for Different Bidding Radii
6000
5000
3000
4)
C)
00
1000
25
50
75
100
125
150
175
200
Bidding Radius
-+---
Always Accept Best Bid -
-- - --
Accept Best Bid if Below Threshold
Figure 9 Delivery Times for Different Bidding Radii
Delivery times are an average per delivery over 50 simulation runs and the error bars show one standard
deviation in each direction. For each set of simulation runs there were 10 taxis with some using the
QUEUE bidding strategy and all parcels had a specific bidding radius as shown on the horizontal axis. For
half of the simulation sets the parcels always chose the bid with the lowest delivery time. For the other half
the parcels only chose the bid with the lowest delivery time if the delivery time was less than 1200 clock
ticks. Otherwise, they accepted no bid and kept requesting bids until a suitable one was found.
45
46
5 Future Work
While simulations are very useful, implementation is always the best test of any system.
In building the simulator several significant simplifications were made. Here is a list of
them and the issues that would need to be addressed.
5.1 Realistic Environments
Obviously the artificial city used in HereToThere is not reflective of any real-life city. A
real-life city would be irregularly shaped, have a network of streets, have traffic speeds,
have patterns of traffic flow, and a list of externalities that could affect pickup and
delivery of parcels.
The city in the HereToThere simulator was intentionally left as
simple as possible so that the research could focus on the market mechanisms and not on
building a realistic city. It is true that in a real-world situation that vehicles especially
and parcels to some extent would need to include both background and real-time
knowledge of the city in order to make accurate bidding decisions. However, the method
of bidding and its outcome should be the same.
5.2 Timing
Possibly the largest simplification that the HereToThere simulator assumes is that of
timing. In the simulator all events happen in order and at discrete time steps. As part of
this, all RFBs are sent out one at a time, and each RFB collects all of its bids and decides
on one before the next RFB is sent. There are two main problems here.
47
First, in the real world time is continuous, nothing is instantaneous, and multiple things
can happen at the same time. Because it takes time for an RFB to reach the vehicles, the
vehicles to send back their bids, and the parcel to notify the winner, we would expect that
vehicles would have to deal with multiple RFBs at the same time.
One benefit of timing in the real world is that it eliminates artificial bidding preferences
that the simulator introduced.
For example, in the simulator, at each clock tick, all
existing parcels got a chance to have vehicles bid on them before any new parcels were
able to contact the vehicles. In the real world bidding is not done "in order" and so this
problem would go away.
5.3 Improved Algorithms
The algorithms used by the vehicles in the simulator for deciding how to do routing and
how to bid are extremely simple. They should take into account many more things in the
real world. In the taxi scenario, for example, they should account for traffic, road layout,
city regulations, refueling, driver breaks, and more. Also, vehicles should use a good
strategy for what they do when they are idle. For example, a vehicle might want to move
to a central location or a location of high parcel frequency in hopes of being in a position
to offer a more attractive bid for future parcels.
Another thing that would be cool would be to extend the use of Hubs. Currently, the
CENTER HUB strategy has shown to not be worthwhile.
48
However, it would be
interesting to see how efficient a system with multiple hubs would be. One system for
example could employ the use of four symmetric hubs with trucks running between the
hubs and taxis running from the hubs to and from the pickups and drop-offs. This would
more closely resemble a real-world hub and spoke delivery system.
5.4 Reputation
In the simulator it is known that the vehicles are reporting accurate bids to the parcels.
Although they may give different bids depending upon their routing algorithms, none of
them is trying to win parcels by intentionally bidding below their actual possible delivery
time. However, the vehicles can still underestimate their delivery time in cases where
future parcels change their delivery order. Whether intentional or unintentional, there
needs to be some way of punishing vehicles who don't live up to their bids and rewarding
those that do.
The straightforward solution to this would be the use of reputation
mechanisms. With reputation mechanisms, once a parcel is delivered it rates the vehicle
on how the delivery time it gave in its bid compared with its actual delivery time. This
way each vehicle would buildup a reputation score over time. This score would then
become a part of future bids, allowing each parcel to factor reputation into its vehicle
decision.
5.5 User Interface
In the simulator there is a user interface that allows the user to specify which algorithms
the vehicles should use, but there is no interface that allows the user to send out RFBs or
reply with corresponding bids. All of that is done automatically in the code. In the real
49
world, you may or may not need a higher level of interaction with humans. In the taxi
scenario, the person who wants a taxi needs some way of specifying where she is and
where she wants to go. On the taxi end, either the taxi company can have a computer
does the bidding on behalf of the taxis or the RFB could be propagated to the taxis where
the driver could respond to the bid. Then, once the bids are sent back to the person either
she could decide which bid she wants to accept or she could have a software agent that
would make that decision for her. Ideally, the use of software agents would reduce the
amount of user attention needed.
5.6 Subcontracting
Subcontracting is the process where a single delivery agent acts as a "representative" for
multiple delivery agents. There are primarily two uses for subcontracting. The first is for
coordinated effort of vehicles.
An individual router, for example, does not deliver a
packet from its source to destination. Instead, the hop count that routers use to bid
"represents" other routers, and through this coordinated effort packets reach their
destination. The other primary use of subcontracting is for abstraction. Abstraction is
useful for when you don't want the parcel to communicate directly with each vehicle, but
prefer to have the parcel communicate with a vehicle representative. One scenario where
this would make sense is a marketplace for taxis with several different taxi companies
participating. It's likely that for competitive reasons a taxi company would not reveal
how many taxis it has out any given moment, so instead of having every taxi respond to
an RFB it can have a delivery agent that collects bids from the taxis and then only sends a
select few to the parcel. Another reason a taxi company may want to do subcontracting
50
in this fashion is to set up a bid filter to screen bids before they are sent back to the
parcel.
No matter what the reason, subcontracting provides a way for intelligent
coordination of delivery agents that is transparent to parcels.
5.7 Multiple Bids Per Vehicle
In HereToThere, each vehicle responds to a Request For Bid with either no bid or exactly
one bid. However, there are situations in which vehicles may want to return multiple
bids to allow more choice alternatives for the parcel. One way in which multiple bids
could be beneficial is as a method for prioritizing parcels. For example, a vehicle could
offer a "standard" bid and a "priority" bid. The "priority" bid would likely offer shorter
delivery time in exchange for a higher delivery cost. This is akin to the pricing system
used by courier services, but it is much more flexible in that the priority pricing could be
determined dynamically for each parcel.
51
52
6 Conclusion
This paper has proposed the use of market-based mechanisms as a new approach for
allocating delivery agents to location-based tasks. It then looked at the use of a specific
market-based mechanism - a sealed bid, competitive auction - for a particular problem in
this domain - the Dynamic Vehicle Routing Problem. Initial research has shown that this
new approach provides benefits including efficiency in heterogeneous environments,
scalability, and feasibility. An interactive simulator of the application supported these
benefits. In addition, a wide range of topics of future research for this framework has
been presented.
53
54
Appendix A - Important Simulator Classes
Simulation.java
Constants
public static final int MAXX = 300
public static final int MAXY = 300
Constructors
public Simulation ()
Methods
(HubManager hm, VehicleManager vm, ParcelManager pm,
int bidradius)
void start (int[][] taxis, int[][] trucks, int numparcels,
int parcelfrequency, int bid-radius)
void stop ()
void resume ()
void clockTick()
void setBatchMode (boolean batch)
boolean getBatchMode ()
public void start
public
public
public
public
public
public
Vehicle.jiava
Methods
public abstract BidResponse getBid (Parcel p)
public abstract void ackBid (Parcel p, boolean accepted)
public abstract void clockTick()
Constructors
public Taxi
public Taxi
public Truck
public Truck
(Simulation simulation, Point p, Rectangle bounds,
Hub[] hubs, int algorithm, int id)
(Simulation simulation, Point p, int algorithm, int id)
(Simulation simulation, Point p, Rectangle bounds,
Hub[] hubs, int algorithm, int id)
(Simulation simulation, Point p, int algorithm, int id)
55
VehicleManager.java
Methods
public void reset ()
public BidResponse[] getBids
public void clockTick()
(Parcel parcel,
Point location)
Constructors
public VehicleManager(Simulation
simulation,
int[][] taxis,
int[][]
trucks)
Parcel.iava
Variables
Point current, next, finish
Methods
public
public
public
public
void hubStop (Point p)
void pickup ()
void dropoff ()
boolean go ()
Constructors
public Parcel
public Parcel
(Simulation simulation, int id)
(Simulation simulation, int id, Point start, Point finish)
ParcelManager.java
Methods
public void clockTick()
Constructors
public ParcelManager(Simulation s)
public ParcelManager(Simulation s,
mt
np, it f)
Hub.iava
Constructors
public Hub(Simulation simulation,
Point location,
Methods
public void addParcel (Parcel parcel)
public Point getLocation ()
public void sendParcels ()
56
int numparcels)
HubManager.ava
Constructors
public HubManager (Simulation simulation,
int num hubs,
int numparcels)
Methods
public Hub[] getHubs (Rectangle bounds)
public void clockTick ()
Algorithm.iava
Constants
public static final int RANDOM = 0, SIMPLE
=
1, QUEUE
=
BidResponse.lava
Constants
public
public
public
public
static
static
static
static
final
final
final
final
String
String
String
String
PICKUP = "PICKUP";
DROPOFF = "DROPOFF";
DELIVERY = "DELIVERY";
PRICE = "PRICE";
Variables
public Vehicle vehicle;
public HashMap conditions;
Constructors
public BidResponse (Vehicle vehicle, HashMap conditions)
57
2, CENTERHUB
=
3
58
References
1.
Bertsimas, Dimitris J and D. Simchi-Levi. (1996) A New generationof Vehicle
Routing Research: Robust Algorithms, Addressing Uncertainty. Operations Reseach
vol. 44, pp. 286 - 304.
2. Bluetooth (1999), Bluetooth ProtocolArchitecture Version 1.0. Bluetooth White
Paper 1.C.120/1.0. http://www.bluetooth.com/developer/whitepaper/whitepaper.asp
3. Cisco Systems. Routing Basics,
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito doc/routing.htm
4. Clearwater, Scott H., editor. (1996) Market-Based Control:A ParadigmFor
DistributedResource Allocation. World Scientific Publishing Co. Pte. Ltd.
5. Digital Dispatch Systems, http://www.digital-dispatch.com/
6. Digital Dispatch Systems (1992), Transportationdispatch and delivery tracking
system. U.S. patent US5122959.
7. Gendreau, Michel and J.Y. Potvin. (1998) "Dynamic Vehicle Routing and
Dispatching." In Fleet Management and Logistics (pp. 115 - 124), Kluwer Academic
Publishers, Boston.
8. Goldberg, Matt (1996), "How FedEx Runs on Time," Fast Company, Issue 8, p. 38,
http://www.fastcompany.com/online/08/minm8.html
9. Kahaner, D.K. Singapore's Smart Taxis. (1996) Asian Technology Information
Program Report ATIP96.016.
http://www.atip.or.jp/ATIP/public/atip.reports.96/atip96.016r.html
10. Lawler, E.L. et al. (1985) The TravelingSalesman Problem: A Guided Tour of
CombinatorialOptimization. John Wiley, Chester, U.K.
11. Marron, Donald B. and C.W. Bartles. (1996) "The Use of Computer-Assisted
Auctions for Allocating Tradeable Pollution Permits." In Market-Based Control:A
ParadigmForm DistributedResource Allocation (pp. 274 - 299), World Scientific
Publishing Co. Pte. Ltd.
12. Malone, Thomas W., et al. (1988) "Enterprise: A Market-like Task Scheduler for
Distributed Computing Environments." In The Ecology of Computation (pp. 177 205), Elsevier Science Publishers B.V.
59
13. 0. Shehory and S. Kraus, (1998) "Methods for task allocation via agent coalition
formation," Artificial Intelligence, Vol. 101, No. 1-2, May, 1998, pp. 165 - 200.
14. Psaraftis, H.N. and G.G. Tharakan. (1979). A Dynamic ProgrammingApproach to the
Dial-a-RideProblem. An Extension to the Multi- Vehicle Case. Department of Civil
Engineering Report R79-39, Massachusetts Institute of Technology
15. Rao, Bharat, Z. Navoth, R. Wuebker, and M. Horwitch. (1998) "The FDX Group:
Building the Electronic Commerce Backbone for the Future" Institute for
Technology and Enterprise. http://www.ite.polv.edu/people/brao/fedex case.htm
16. Requirements for IP Version 4 Routers, RFC 1812,
http://andrew2.andrew.cmu.edu/rfc/rfc 1812.html
17. Rodden, Tom. et al. (1998) "Exploiting Context in HCI Design for Mobile Systems"
First Workshop on Human Computer Interaction with Mobile Devices
18. Sigtec Pty Ltd, http://www.sigtec.com.au/corpmain.htm
19. Wilson, N.H.M., J.M. Sussman, H.K. Wang and B.T. Higonnet. (1971). Scheduling
Algorithms for Dial-a-Ride Systems. Urban Systems Laboratory Report USL TR-7013, Massachusetts Institute of Technology
60
Open Markets for Agent Interaction:
Enabling a Multi-Agent System of Markets and Traders
Jim Youll, Pattie Maes
MIT Media Laboratory
20 Ames St., Cambridge, MA 02139, U.S.A.
E-mail: {jim,pattie}@media.mit.edu
ABSTRACT
Market operators have always provided two important
services to traders: a market place where compatible traders
meet, and enforcement of a market model. In traditional
markets, the market place and market model are
inextricably bound.
This paper considers the separation of market model from
market place. We discuss the design of distributed market
systems optimized for interactive, negotiation-dominated
environments for electronic commerce. In our architecture,
a plurality of market models is active. These models,
executed by agents representing buyers, sellers and interagent services, form a distributed marketplace.
We discuss new economic interactions made possible by
the decomposition of the market into components that may
be individually negotiated, modified, or delegated. Market
participants may act in many market places simultaneously,
pursuing diverse strategies ranging from contingent
arrangements to fully- delegated multi-party agreements.
KEYWORDS:
Software agent, market, negotiation,
transaction processing, auction, retail, wholesale, risk
management
1. INTRODUCTION
The operator of a traditional market such as a stock
exchange, retail store or online merchant provides two
important services to participating traders. First, the market
place is a venue where compatible traders meet (such as
"New York Stock Exchange"). Second, market models
created and enforced by the market control the flow of
goods and money and dictate the rules of engagement
between traders. For example, New York Stock Exchange
rules require full disclosure of bid/ask prices, minimum
price variations of $0.0625, and trades in 100-share "round
lots" [20]. In traditional markets, the market place and
market model are inextricably bound. A NYSE trader
cannot, for example, trade by self-made rules within the
exchange even if other interested traders also agree to
honor his conventions. And a trader cannot demand that the
rules of one stock exchange be honored in another.
Agent-based electronic marketplaces [9] could facilitate
new transaction and negotiation models that are not viable
in traditional physical marketplaces, including the ability to
flexibly apply one's preferred rules ofsengagement across
many market places. However, most present electronic
markets do not employ agents and are typically modeled
after physical markets in which every market model
belongs to some market place.
For example, both open-air flea markets and Ebay auctions
attract niche specialty traders to a bazaar environment. The
electronic market wins a large audience by bringing
together geographically disparate participants. But the
physical market's salespeople can dynamically restructure
goods and prices to accommodate changing conditions and
buyer demands. Real-world sellers can also create bundles
and special offers tailored to individual buyers. Highlyengaged interactions of this nature do not occur on
electronic markets such as Ebay.
This paper considers the separation of market model from
market place. Can a viable economy arise when a central
market authority no longer controls the interactions
between traders? What are the fundamental, minimal rules
of engagement to which all agents must adhere, and how
will they communicate? In this new order, what is the
appropriate division of authority and responsibility between
the market, market agents, and market intermediaries?
2. DIGITAL AND PHYSICAL MARKETS
As researchers continue to explore the issues of expressive
human interaction through the Internet [25], common
Internet applications in their present form clearly limit the
medium's ability to provide a level of human interaction
comparable to that found in face-to-face discourse. From
the start, the technical limitations of virtual marketplaces
may hinder rich interaction and compromise that might
1
otherwise enhance trader-to-trader discourse.
Beyond the limitations of the medium, the market models
underlying Ebay [11] and sites like it may actively
discourage dynamic interaction between buyers and sellers.
In contrast to a seller in an open-air flea market who
constantly invents new offers to entice buyers, an Ebay
seller who frequently alters a listing may be penalized if
buyers interpret Ebay's prominent notice of changes as a
negative indicator. Ebay also locks out modifications once
bidding has begun. The rules are sensible for basic
mechanized auctions, but preclude expressive responses to
changing market conditions. Creative vendors have
circumvented the rules through a practice in which items
for sale are displayed with URLs directing customers to the
sellers' own web sites, which display bundles and dynamic
offers not possible on Ebay. These vendors may aid
consumers by chaining together previously partitioned
marketplaces, increasing competition and reducing search
costs.
Auction environments such as Ebay and the Michigan
Internet AuctionBot [26] present literal models of physicalworld auctions. Retail sites like Homeruns.com closely
mimics brick-and-mortar retailers, even appropriating
supermarket nomenclature such as "aisles" and "deli" for
its virtual supermarket. Priceline.com deploys a patented
bidding model in which buyers accept restrictions on their
ability to reject undesirable offers in exchange for the right
to bid on items that ordinarily bear non-negotiable prices
[21]. Coalition or "aggregate" buying at sites like
Mobshop.com represents another conceptual model made
practical by the Internet. In this market, buyers subscribe to
product offerings whose prices fall for everyone as more
buyers join. Aggregate markets are open to new
participants for a time period predetermined by the market
operator, ranging from several hours to several days.
These Internet-based marketplaces nonetheless bind place
to market model precisely as their physical-world
predecessors do. For example, Mobshop.com buyers cannot
join group purchases led by other aggregators such as
Mercata.com without joining the Mercata.com marketplace.
Neither can they attempt a group purchase at another retailonly site. Priceline.com's buyer-bidding model cannot be
used to purchase goods from sellers not represented by
Priceline.com.
Some of these markets do permit sligh tuning of their rules.
Mobshop.com accepts price-contingent commitments ("if
the price falls to level P, then I will buy the item"). Ebay
allows sellers to set reserve prices (private or public) and
opening bids - practices that impose some characteristics of
a retail fixed-price sale on an auction. Amazon.com allows
retail buyers to see if the same goods are for sale at auction
- but only in Amazon-run auctions, not others. Overall,
there is little theoretical backing for these models compared
to the wide range of auction theory [24].
2.1 Business drivers, market structure and the
consequences of high search costs
The business models of market-making companies depend
upon control of the marketplace and the ability to capture
and retain traders. Especially when a market trades
homogeneous goods, markets may attempt to attract traders
(consumers) by promoting proprietary trading models or
financial terms that are represented as improving market
conditions for traders. Each market seeks to seize a greater
share of all traders by presenting its market model as a
competitive advantage.
Two costs are borne by consumers who attempt to survey a
market before committing to a transaction or relationship:
search cost and switching cost.
Search cost - the cost of discovering new markets or new
trading partners, or the cost of discovering the "market
price" of some good or service. Maintaining current
relationships carries zero search cost. The expected
additional utility of any new relationship established as the
result of a given search must exceed the search cost to
make a search worthwhile.
Switching cost - the cost of cessation of business with a
given trading partner, plus the cost of establishing a
business relationship with a newly discovered provider.
Bertrand addressed the question of sellers' profits in
competitive commodities markets, predicting that
downward pressures brought about by buyer price
comparisons should drive prices to the marginal production
cost [4]. Kephart [17] has further modeled the risks to profit
and price stability in agent economies whose traders have
ready access to price information across markets and low
search costs.
Chamberlin presented the concept of product differentiation
in response to Bertrand. arguing that price will always
exceed marginal cost, even in a competitive setting, due to
buyer preference. Sellers thus profit by charging more than
the production cost, even for commodity goods [8]. And
Diamond argued that the cost of discovering prices (search
cost), even if very small, could potentially dissuade buyers
from comparing any prices. When buyers do not search,
monopolistic price levels may appear even in a crowded
market populated by many competitors selling commodity
goods [10].
Anderson and Renault endorsed a possibility discussed but
dismissed by Ausubel concerning the role of search costs
and switching costs as contributors to high credit card
interest rates [2], citing the dramatic increase in credit card
advertisements that began after Ausubel's 1991 study. Card
issuers began promoting low initial interest rates and prefilled application forms, actions that lowered consumer
search costs. However, the substantial rise in ititeresi iates
after perhaps six months for a given card, Anderson and
2
Renault write,
component." [1]
"suggests a strong switching cost
Individual market actors must not only search for the
desired goods or possible trading partners in an everexpanding universe, but must also evaluate trading venues,
market models, prices and terms. Every new marketplace
adds to the overall search cost for traders who participate in
multiple markets. The success of existing markets has
enticed Internet heavyweights to enter the online market
business, possibly leading to a proliferation of market
places. [23]
A proliferation of electronically facilitated markets could
partition buyers and sellers, increasing search costs rather
than driving them down. Electronic markets built in the
tradition of physical markets deliver economic rewards to
market builders but need not be engineered to improve
flexibility or reduce prices or search costs for market
participants[14].
Anderson and Renault conclude that the optimum number
of firms decreases as search cost increases, but predict that
any search costs exacerbate over-entry by firms into
optimally-populated or overpopulated markets. Whenever
the entry of a new firm into a market increases consumer
search costs, the overall density of searches will decline,
reducing competition and permitting higher prices.
However, even when some level of consumer search cost is
inevitable, market prices may fall as a consequence of
consumer taste diversity. Taste diversity fosters more
searches, increased search activity fosters competition, and
competition in turn leads to lower prices.
2.2 Double dipping
The New York Stock Exchange (NYSE) restricts its
activities to operational and administrative functions of its
market. Unlike the NYSE, new-era market operators such
as Priceline.com and Mobshop.com may act as both market
managers and market participants. Profits for these firms
flow not only from order handling, but also from their
imposition of undisclosed spreads between the selling price
and the price at which they purchase the underlying goods
or services from producers [13]. Thus, these participants are
more like ordinary vendors and less like true market
operators, no more motivated to identify or provide the best
prices or largest selection to buyers than any other
merchant [21].
3. THE OPEN MARKET AND ITS APPLICATIONS
We propose a market structure that maintains near-constant
search costs while permitting rich interaction between
buyers and sellers, accommodating the participation of
many firms eager to trade. We believe such a marketplace
can effectively encourage searches while offering a means
for vendors to convert buyer preferences into sales
opportunities. Increased search activity should encourage
competition and promote lower prices, while the vendors'
ability to differentiate themselves through unique product
offerings, multi-parameter negotiations, and trading
policies may provide the leverage they need to avoid the
Bertrand Paradox and its prediction of price regression to
marginal cost.
Our design separates the market model from the market
place, binding preferred and potential interaction models
directly to transacting agents. Buyers and sellers find each
other through directories that could be considered abstract
market places. Unlike traditional markets, however,
participating agents follow their own dynamically chosen
strategies when negotiating the rules of engagement with
other agents, rather than the "rules of the market."
A large open market system is a distributed network of
specialized directories for market-based agents. The
directories may be strongly vertical, bringing together
specialists in a narrow market niche ("National Beanie
Baby collectors' market") or mostly horizontal ("Downtown
Cambridge merchants' market") bringing together trading
partners from many specialties who often do business with
one another. The exact content, purpose and interactions
facilitated through them will be determined in practice and
constantly evolving. The system shquld encourage the
dynamic creation of "markets" by many parties for any
reason they find useful.
Three application areas made feasible by an open,
distributed market are described next:
1. Complex conditions for routine transactions
2. Component-based transactions
3. Better communication through and about markets
3.1 Complex conditions for routine transactions
Open markets facilitate conditional, ad hoc arrangements
between trading partners in forms of negotiation, agreement
and settlement that cannot be anticipated a priori, the
ordinary mandate of conventional market models.
Bundles - Trading partners may arrange the sale of "this
item and that item," with consideration to the buyer for a
greater overall purchase, and some benefit to the seller.
Forward contracts - Traders may wish to enter into a
commitment to buy or sell a quantity of goods over time
rather than all at once. Buyers making such commitments
for goods would ordinarily do so in exchange for an
incentive, such as a discount or preferential delivery terms,
from a complementary trader. A loan of cash and its
subsequent repayment schedule could also be considered a
form of forward contract.
Contingencies - Conditions related to the traders or to
external events may control the ultimate terms of a deal.
Two productive uses of contingent terms in market
transactions are: the reduction of risk for one or both parties
when external results are not yet known, such as the
3
approval of a home mortgage; encouraging
consummation of transactions by supporting
constructive nature of consumer choice [5].
the
the
The current generation of electronic marketplaces does not
broadly support ad hoc bundles, forward contracts or
contingent arrangements. With market models bound to
these marketplaces, every marketplace would have to add a
multitude of possible transaction models to the underlying
software that runs the market. Also, markets' primary
function has been the rapid and efficient clearing of
transactions by the single set of rules that define it.
Complex transactions such as those described here may
preclude immediate clearing. Trader-to-trader transaction
systems can more readily support complex interactions
provided the peers unambiguously state, and agree to, the
conditions of the interaction.
3.2 Component-based transactions
Even the smallest transactions include many participants
and transaction elements. Prior to completion of a
transaction, the services of all the necessary participants
must be engaged, payment terms arranged, and
requirements negotiated. Upon completion of the
transaction, participants must be individually compensated
according to the agreed terms.
An example of a small sale involving many participants is a
music purchase by credit card from CDNow. Participants
include the customer, CDNow, the credit card issuing bank,
credit card merchant bank, shipper and insurance provider.
Contributors to this transaction are customarily engaged
and compensated outside the market system, or through
other unconnected markets. CDNow makes direct
-sm
Wholesaler
Merchant Bank
.
Shipperient
Shipper
Issuing
Bank
Insurer
I+
I
I
Goods
Customer
Fig. 1 Settlement of a component-based transaction
arrangements with carriers for shipping, with underwriters
for insurance, and with a merchant bank for financial
settlement. Ultimately, the parties are compensated outside
the "sales market" in which CDNow tendered the sale of
goods and received payment.
In comparison, the participants in a component-based open
market transaction could actively contribute the "missing
parts" to help complete a multi-party transaction. An
insurer, for example, could deploy an agent to bid on the
"risk" in many transactions on a scale that would ordinarily
be too small to even consider. We envision a competitive
insurer underwriting the risk of loss for thousands of
individual, small, mail-order sales, each independently
evaluated and priced according to the relative exposure,
possibility of loss, and "fit" with the insurer's overall goals
and desired customer base. Transactional components are
also used to route payment directly from source to payee
for the process of "settlement." In Fig. 1, a merchant bank
directly compensates the vendor, wholesaler, shipper and
insurer upon receipt of credit card authorization from the
customer.
3.3 Better communication through and about markets
Buyers and sellers in a conventional electronic market
cannot meet potential trading partners in other market
places unless they exhaustively search all such places on
their own. Buyers also must conduct a similar exhaustive
search to compare prices or products offered.
Spiders that periodically survey the items posted at for-sale
sites [19] are one answer to the problem of poorlydistributed market information. This approach consolidates
information about price and goods across many market
places, but is inherently inefficient. Information is not fed
back into the markets themselves, but used as a third-party
reference, not seen by all traders, . Operators of some
market places oppose external market-querying activities,
and have employed both technical and legal defenses [3,6]
to stop "scans" by information-gathering intermediaries.
Other than web sites specifically designed to host "wanted"
ads [16], most sales-oriented sites are not also equipped to
accept or respond automatically to an individual's "wants."
This limitation not only reduces consumer choice, but also
works against such sites' ability to learn what potential
customers were really looking for.
An open market, on the other hand, supports simultaneous
participation in many market places by both buyers and
sellers. Desired goods and services receive equal billing
with offered goods and services.
4. DESIGN CONSIDERATIONS
We divide the conventional concept of "market" into two
disjoint, distributed elements. Both market places and the
market models must be capable of freestanding operation in
this environment. We might say that there are no actual
4
"markets" per se. Market activities are distributed among all
the buyers and sellers. Their composite state at any moment
is the state of the "market."
A key design challenge has been the creation of minimallyintrusive protocols to support agent autonomy for the
negotiation of not only goods and funds, but also the rules
of engagement themselves.
4.1 The market place
The "marketplace" itself remains a common forum in which
traders establish a presence and attempt to engage other
traders and market service providers. But this
"marketplace" is little more than a directory of agents
participating in each market, whose listings are available to
all participants. A diminished market authority assumes an
administrative role, facilitating but not regulating the
interactions of participants. An agent can ask the market to
send notice whenever there is a change in the state of other
agents, a change in the marketplace itself, or when specific
goods or agents of interest appear in the directory.
4.2 Market models
Market models, the rules and conventions for peer-to-peer
trading are moved out of the "market" and onto individual
agents. A plurality of market models is active in our
system, with market rules determined and enforced by
individual agents representing buyers, sellers and
intermediaries. This design stands in contrast to
conventional markets in which the essence of the
marketplace is the underlying transaction model.
4.3 The market authority
Our vision of an open market is thus a set of conventions
permitting independent agents to follow their own
strategies when directly engaging each other in negotiations
and transactions. What had been "markets" are now
"directories." Markets help complementary agents meet,
perform basic administrative functions, and broadcast event
notifications.
in a traditional stock exchange, or advertisements in a
newspaper classified section. Some markets, including
Priceline.com or Mobshop.com, promote their market
models. Insurers tout their long histories and stability.
Online auctioneers advertise the size of the auction
audience and the reliability of their systems. Physical-world
auctioneers promote their ability to win a higher price for
sellers, their specialized audiences, and their expertise with
difficult-to-sell goods.
In the world of open markets, the matter of a market's
"audience" is less significant. And advertising messages
about past performance, longevity and audience size are not
likely to be understood by trading partners built of
software. How then, might traders advertise their
availability and attract others to interact with them?
Initially, we believe traders will gain prominence by listing
their availability in many directories and by implementing
flexible trading rules to improve their chances of finding a
compatible trading partner. As markets mature, traders will
seek entry to "preferred" directories that emerge over time,
created by private individuals and trade or consumer
groups.
Eventually, as technologies and markets evolve, traderrating services will monitor market activity, collect
assessments and recommendations from market entities,
and provide evaluations of reliable, appropriate trading
partners in a form useful to interested agents.
4.4 Protocols and practices
Communications within the open markets follow a few
guiding principles:
1. All values are communicated with units (USD, Km,
hr, units, etc)
2. Agents subscribe to common ontologies for item
codes, field names, units, and protocols
3. All messages bear expiration timestamps; all
markets adhere to one time standard
The former role of the central market authority as rulemaker and rule-enforcer is removed. In practice, agent
interactions may create an illusion of place when viewed
from a distance. But it is the peer-to-peer negotiations and
transactions carried out between traders, taken as a whole,
that create myriad short-lived markets.
4. Messages from one agent to another may be
answered by a critique from the receiving agent,
indicating out of bounds values or fields that were not
understood by the receiving agent
4.4 Market prominence and trader self-promotion
Traditional markets distinguish, name and advertise
themselves through the models with which they match
buyers and sellers, the manner in which their participants'
offerings and wants are made known to others, the rules
they impose on participants, and the unique offerings found
within.
4.5 Messages
Agents may send these messages to markets:
1. {Add me to, remove me from} the directory
2. Notify me if (join, leave, item n I event occurs
3. What agents in your directory are complementary to
(requirements}
A market's primary advantage may be the broad, uniform
exposure a given message receives - such as stocks for sale
Markets may send these messages to agents:
1. Event (join, leave, item) occurred
2. Confirming (added to, removed from} directory
5
3. These agents complement your requirements
Agents may send these messages to each other:
1. What parameters do you require?
2. I require these parameters {list}
3. Will you give me an exclusive for {time}
4. Here is an offer { (field, value), (field, value),
{list
...
}
An agent that receives a message from another agent may
answer with a field-by-field critique, inspired by [12]:
{field} (too high, too low, do not understand value,
required, do not understand units} { suggested value
4.6 Basic conversation flow
Sender
Format and send message
Receive critique
Execute private strategy
Repeat with replacement message to answer critique
Receiver
Receive message
Execute private strategy
Issue critique
4.7 Peer discovery
An agent interested in finding transaction partners may
pursue either or both of these basic strategies:
1. Ask the market if its directory
complementary traders; contact them
lists any
2. Post its identification, wants/offers and availability
to the market; wait to be contacted
4.8 Market service providers
Open markets may contain not just buyers and sellers, but
also providers that exist specifically to offer marketenhancing services to traders. We believe these intramarket service providers will prove an important, essential
part of the market machinery.
Some likely service providers are currency converters, cost
estimators, reputation reporting/querying tools, transaction
auditors, and group purchase aggregators. The exceptionhandling systems designed by Mark Klein and Chrysanthos
Dellarocas [18] could be attached to open market agents as
intra-market services, introducing robust failure handling to
otherwise unsophisticated agent machinery.
5. RELATED WORK
The COPS project [22] discusses a distributed market
model in the evolution of an infrastructure for "security and
fairness" in trading. COPS provides transaction security
across dynamic, distributed market structures.
providers, and described two implementations of the
models in the Stanford Digital Library Project [15].
The Internet Open Trading Protocol (IOTP), RFC2801, [7]
provides an electronic commerce framework and
communication standard that is payment system
independent and encapsulates many popular payment
systems. IOTP codifies several "roles" in an e-commerce
transaction. and provides information and payment routing
between them.
6. CONCLUSIONS AND FUTURE WORK
We have discussed a framework, design philosophy and
potential economic implications of a peer-based open
market of trading agents.
We are building simulations of the open market framework
discussed in this paper to evaluate the requirements for
effective communication between economic agents, and to
explore the optimal balance of responsibilities between the
market, agent intermediaries and market principals.
We are further testing new kinds of economic interactions
made possible by the decomposition of the market into
components. Market models not designed after physical
markets but made possible by such a system will be tested
against traditional market models to determine whether
they generate advantages for traders.
Early results support the intuitive conclusion that
freestanding agents in an open market are larger and more
complex than agents in traditional markets. They require
more code and introduce new opportunities for failure and
unexpected behaviors. Inter-agent communications must
adhere to the lowest common denominator by which agents
may communicate, basically, text messaging. RMI and
CORBA are communication options that would allow
transmission of more complex negotiation objects at the
expense of still more complex individual agent traders.
A heavily-mediated open marketplace could allow lesscapable agents to "hire" the additional capabilities they
need, rather than bringing every necessary skill themselves.
ACKNOWLEDGMENTS
We thank Joan Morris and the Software Agents Group for
their advice and invaluable assistance. We also thank
British Telecom and the sponsors of the Digital Life
Consortium and e-Markets SIG at the MIT Media
Laboratory for their support of our research.
REFERENCES
1. S.P. Anderson and R Renault Pricing, product
diversitv, and search costs: a Bertrand-ChamberlinDiamond model, RAND Journal of Economics, Vol.
30, No. 4, Winter 1999, pp. 719-735.
presenied fiurmal s'1oppin 1m-1dUI L Us.cibe Mre
modes of interaction between customers and information
Kteclpel
6
2.
L.M. Ausubel The Failureof Competition in the Credit
Card Market, American Economic Review, Vol. 81,
1991, pp. 50-81.
3.
J.P. Bailey and Y Bakos An exploratory study of the
emerging role of electronic intermediaries,
International Journal of Electronic Commerce, vol.1,
no.3, Spring 1997, pp.7-20. M.E. Sharpe, USA.
16. S. Kirsner Technology & Innovation, The Boston
Globe, Mar. 20, 2000, p. C1
4.
J.L.F. Bertrand Thiorie mathimatique de la richesse
sociale par Lion Walras: Recherches sur les principes
mathimatiques de la theorie des richessepar Augustin
Cournot, Journal des savants, Vol. 67 (1883), pp. 499508.
17. J.O. Kephart and A. Greenwald Shopbot Economics, in
Proceedings of Fifth European Conference on
Symbolic and Quantitative Approaches to Reasoning
with Uncertainty, University College London, London,
July 6, 1999.
5.
J.R. Bettman, MF Luce and JW Payne Constructive
Consumer Choice Processes, Journal of Consumer
Research. Vol. 25 (3). p 187-217. December 1998.
18. M. Klein and C. Dellarocas, Exception Handling in
Agent Systems, in Proceedings of the third annual
conference on Autonomous Agents, 1999, pp. 62-68.
6.
H. Bray Net Auctioneer Ebay Sues Mass. Web Site
Over Link, The Boston Globe, Dec. 14, 1999, p. C2.
19. http://www.mysimon.com
7.
D. Burdett, Internet Open Trading Protocol - IOTP
Version 1.0, ftp://ftp.isi.edu/in-nots/rfc2801.txt
8.
E. Chamberlin The Theory of Monopolistic
Competition, Cambridge. Mass.: Harvard University
Press, 1933.
9.
A. Chavez and P Maes Kasbah: an agent marketplace
for buying and selling goods, in Proceedings of the
first international Conference on the Practical
Application of Intelligent Agents and Multi-Agent
Technology, London, U.K., April 1996.
10. P.A. Diamond A Model of PriceAdjustment, Journal of
Economic Theory, Vol. 3 (1971), pp. 156-168.
11. EBAY, Inc. Annual Report, 12/31/99, Disclosure
Incorporated, 2000.
12. G. Fischer, A.C. Lemke and T. Mastaglio The Role of
Critiquing in Cooperative Problem Solving, ACM
Transactions on Information Systems, Vol. 9, No. 3,
April 1991, Pages 123-151.
13. S. Ginsberg Fishing for That Affordable Fare?
Priceline's Hook: You Name a Price, it Hunts for
Takers, The Washington Post, June 24, 1998, p. C9
14. G.L. Ho, J.C. Westland and H. Sewon The impact of
electronic marketplaces on product prices: an
empirical study of AUCNET, International Journal of
Electronic Commerce, vol. 4, no. 2, Winter 1999-2000,
pp. 45-60. M.E. Sharpe, USA.
15. S.P. Ketchpel, H. Garcia-Molina and A. Paepcke
Shopping models: a flexible architecture for
information commerce, in Proceedings of the 2nd ACM
international conference on Digital Libraries, 1997, pp.
65-74.
20. New York Stock Exchange Rules and Procedures,
Commerce Clearing House, Inc. Chicago, Illinois.
21. Priceline.com Inc. Annual .Report,
Disclosure Incorporated, 2000.
12/31/99,
22. A.W. ROhm, G. Pernul COPS: A Model and
Infrastructurefor Secure and Fair Electronic Markets
In Proceedings of the 3 2 "d Hawaii International
Conference on System Sciences, 1999
23. AOL, Yahoo Jump Aboard Online-Marketplace
Bandwagon, San Jose Mercury News, Mar. 21, 2000.
24. A. Segev and C. Beam Brokering Strategies in
Electronic Commerce Markets, in Proceedings of the
ACM conference on Electronic Conference (May 3-5,
1999, Denver, CO), 1999, pp. 167-176.
25. F.B. Viegas and J.S. Donath Chat circles, in
Proceedings of the CHI 99 Conference on Human
Factors in Computing Systems (May 15-20, Pittsburgh,
PA), 1999, pp. 9-16.
26. P.R. Wurman, MP Wellman and WE Walsh The
Michigan Internet AuctionBot: A ConfigurableAuction
Server for Human and Software Agents, in Proceedings
of the second international conference on Autonomous
Agents (May 10-13, Minneapolis, MN), 1998, pp. 301308.
7