Merkato Version 2.0.12 Seller’s User Manual
Draft Version 0.9
InvisibleHand Networks, Inc
3 Burlington Woods Dr.
4th Floor
Burlington, MA 01803
781-221-4800
ÓCopyright 2001 Invisible Hand Networks
All Rights Reserved.
This document contains information, which is protected by copyright. Reproduction, adaptation, or translation without prior permission is prohibited, except as allowed under the copyright laws.
The following are trademarks, registered trademarks, or service marks of Invisible Hand Networks: Merkato
Java is a trade mark of Sun Microsystems
Disclaimer
The information contained in this document is subject to change without notice.
DOCUMENTATION IS PROVIDED “AS IS” AND INVISIBLE HAND NETWORKS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
Invisible Hand Networks, Inc. shall not be liable for errors contained herein, or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Revision History:
Draft 0.5 – First version of seller manual (based on buyer manual 0.5)
Draft 0.7 – First Review Draft
Draft 0.8 – Explanation of marginal and look-up interpretations of the reservation rate table added.
Draft 0.9 – Incorporated comments from Adriana
Contents
Seller Type of Service Options
Maximum/Current Bandwidth Available per Market
Simple look-up Reservation Pricing
Reservation Market Buy-Back Agents
Arranging Panels within Agent Windows
Spot Market vs. Reservation Market
Reservation Market Agent Window
The Progressive Second Price Auction
Controls which react to market conditions
Settings Controlled by Merkato Administrator
What is Merkato?
Merkato is a unique way to obtain bandwidth, on demand, at fair and equitable prices. Merkato uses a patent pending Progressive Second Price Auction mechanism to collect bids from multiple buyers, analyze the bids to determine the natural market price for this bandwidth, and then automatically apportion that bandwidth to the successful bidders at the market price. The components of the Merkato system are illustrated below.
Buyers of bandwidth pre-configure their agents to be aware of the price they are willing to pay for a range of available quantity. The seller of the bandwidth also configures his strategy, which includes the minimum unit price at which he is willing to sell the bandwidth. Buyer and seller agents then express their willingness to pay for bandwidth in the form of bids (consisting of a unit price and quantity) and send them to the central Resource Agent. (Sellers create a price floor by offering to buy their own bandwidth at their lowest acceptable price.) The resource agent responds to bids with proposed allocations and pricing, which the buyer and seller agents can either accept (by not bidding further), or reject (by submitting another bid). When there is no more bidding, the auction closes, and actual allocations are made. The entire process takes no more than 5 minutes. The auction is completely open and fair, with all bidders anonymously seeing what the other bidders have offered. The Progressive Second Price auction mechanism ensures that all bidders receive their allocation at the fair market price, which will be equal to or less than the price they offered.
The core of the Merkato system is the Resource Agent. The Resource Agent is responsible for
· Collecting bids from active bidders,
· Determining a proposed allocation of bandwidth for each bidder based on the progressive second price auction rules,
· Calculating the market price for each bidder, and
· Distributing all this information anonymously to all bidders.
This represents only a single cycle in the bidding process. Bidders who did not receive an allocation or whose allocation was less than requested, may submit another bid in order to improve their position. This cycle continues until each bidder is satisfied with their allocation, or cannot bid at the current market price. When bidding is complete, the Resource Agent will
· Inform all bidders of the final results,
· Send the bandwidth distribution information to the network driver for implementation the bandwidth distribution, and
· Send the billing information to the accounting database.
Although the auction allocation process is run continuously, there is no need for users to be directly involved at all times. Your agent will bid automatically for you based on a profile of the value you place on bandwidth, which you prepare in advance.
Your financial limits, bandwidth desires, and bidding strategy are expressed using templates provided via the Merkato user interface. These templates are created using the Valuation and Strategy panels in the interface
Once the agent is configured, Merkato offers the user the option of bidding from their desktop using a Java application, or remotely communicating with their agent, which bids from a server co-located with the Resource Agent. The location near the Resource Agent from which the agent bids is referred to as the “Garage”. Both methods have their advantages. The desktop display gives you real-time information about the auction and its participants. On the other hand, if you are not actively interacting with the application, it is best to return your agent to the “garage: to eliminate the potential of ceasing to bid due to desktop PC or network connectivity problems.
Merkato Seller Options
A seller must decide the nature of the marketplace they are creating and then communicate that information to the Merkato administrator so that the system can be configured correctly.
Merkato controls an interface of a router or QOS-enabled switch. The capacity of this interface, or a portion of it, represents the product which the seller is offering to buyers through the Merkato automated marketplace.
Merkato is a very flexible platform and the seller has the opportunity to select among many configurable options.
The first group of choices relate to the nature of the bandwidth “product” you will be offering your customers:
· How will buyer traffic be identified? Merkato must be able to distinguish between data belonging to each buyer so that bandwidth can be apportioned correctly. The most common identifier is an IP subnet - identified by an IP address and subnet mask - but we can also support distinguishing traffic by the physical or logical port to which a buyer is connected, VLAN tags on the data streams of buyers, or the MAC address of the next-hop router from which all traffic associated with that buyer flows. (All buyers within the same marketplace must use a common method for identification of their traffic.)
· In what direction will bandwidth be apportioned? Although buyer traffic nearly always flows both in and out of any interface, it is often unnecessary to apportion bandwidth in both directions. Generally, there is an obvious direction which corresponds to the application being addressed. For example, if Merkato is used to apportion bandwidth among content providers, the direction to control would be from the source of content to the users of that content. If there is no obvious direction, Merkato can be used to apportion bandwidth in both directions simultaneously. It is also possible to use Merkato to create separate markets for incoming and outgoing traffic, although care must be taken that if bandwidth is granted in one direction, sufficient bandwidth for protocol acknowledgements is also provided in the other direction.
· How strict do you wish to be in imposing limits on bandwidth? The most common method of enforcing bandwidth limitations is the least forgiving, that is, to discard any buyer’s traffic that exceeds the amount of bandwidth purchased. In some cases, however, you may wish to allow excess traffic to be sent if there is sufficient capacity due to the other buyers not using the allocation they purchased. We only recommend allowing this permissive behavior in unique applications. When taken to extremes, any buyer could use the whole amount of bandwidth for sale during periods when no other buyers happen to be sending data. The end result is that your buyers will not be purchasing bandwidth, but rather be purchasing bandwidth insurance – guarantees of a desired minimum amount of bandwidth during periods of congestion. As you might imagine, buyers will quickly discover that they need to purchase only the absolute minimum amount of bandwidth except during times of network congestion, so the market for bandwidth tends to be very limited.
The second group of choices relate to the nature of the marketplace you will create
· How much bandwidth do you want to release to the market? Under the Merkato system, pricing is driven by demand. The seller can stimulate demand by reducing the available bandwidth, but of course, will sell less total bandwidth that way. At the other extreme, if always exceeds demand, the market price will remain at the seller’s floor price (which may not be undesirable). The seller may independently specify the amount of bandwidth to be sold on the Spot market and the Reservation market. In the Spot market, the seller specifies a maximum capacity to the Merkato administrator, but afterwards, can adjust it downward at any time via an agent interface.
·
What pricing levels do you want to create for the
reservation market? Reservation
market pricing is determined by a rate table which the seller conveys to the
Merkato administrator. The seller may specify pricing based on the amount of
bandwidth requested as well as on the length of time for which it is requested.
Merkato 2.0.12 supports 4 seller-defined
time steps and 5 seller-defined quantity steps. (A total of 20 price steps).
The seller also specifies the cancellation fee as a percentage of the remaining
value of the contract being terminated. This is described in detail in the next
section.
·
What method would you like to use to interpret your
Reservation Market price table? As
part of the creation of a Reservation Market pricing structure, you will create
a table of unit prices based on duration of a reservation and the quantity
requested. (Each “square” of the table will represent a range of duration and a
range of quantity.) You may configure
Merkato to interpret this table in one of two ways:
1. As a simple look-up table. If the duration and quantity fall within the limits specified for a price “square”, then this is the unit price offered to the customer.
2. As a dual-marginal rate calculation. When used in this way, each “square” of the rate table gives the unit price for the amount of bandwidth which falls within that square. In other words, the price for bandwidth becomes a series of calculations at different unit prices.
The advantage of the first method is simplicity. It is quite easy for buyers and sellers to determine what the unit price will be for any amount of bandwidth at any duration. The advantage of the second method is the lack of price discontinuities as you cross price boundaries.
To give a more everyday example, the first method is the “donut” model. You get a price break at a dozen donuts, but the fact that you would pay more for 11 donuts than 12 leads to a price discontinuity. The second method is the US tax code model, where your first $10,000 of income is taxed at 10%, your next $10,000 of income is taxed at 20%, etc. This pricing method has no discontinuities, but is more difficult to calculate.
These methods are described further in the section on seller market place options.
· What floor price would you want to establish for the Spot market? In the spot market, bidding for bandwidth always begins at the floor price set by the Seller. This price is configured dynamically via an agent interface and changes take effect at the start of any round What method would you like to use as your Spot Market pricing basis? Merkato allows the seller to price bandwidth based on the opportunity cost of each individual buyer (“static seller” model) or based on the price offered for the last unit of bandwidth sold (“dynamic seller” model). New valuation models available to buyers have made the static seller model impractical and it is only still offered for backward compatibility with previous versions of Merkato.
· Do you wish to create one or more buy-back bidders for the purpose of dynamically releasing bandwidth to the marketplace depending on the market price? Sellers may elect to create artificial buyers whose purpose is to release bandwidth to the marketplace at fixed price points. These artificial buyers accomplish this by bidding at the appropriate price point and quantity and “winning” that bandwidth until they are outbid by “real” buyers. Care must be taken to ensure that this is explained to the “real” buyers so that they do not feel that the market is being manipulated unfairly by the seller. This is explained further in the “Advanced Seller Guide” chapter of this manual.
· Do you wish buyers to access spot and reservation markets through a single agent or through separate agents? In the normal mode of operation, a single log-in is used to access both the spot and reservation agents. The buyer selects the agent they wish to access by uploading it from either the spot garage or the reservation garage. Alternatively, both agents could be kept in the same garage, but must be accessed via different usernames (ideally usernames which make it clear which market they apply to). We feel that the convenience of logging in with a single username outweighs the slight inconvenience of selecting a garage from which to upload the agent, but you may make your own determination and your Merkato administrator can set the system up either way.
· How often would you like spot market auctions to be run? By default, spot market auctions are run as often as possible – often every 5 minutes or less. We feel it is best to run the auctions as often as possible to provide buyers with the fastest possible response time to their changes. If for some reason you would like to run auctions less often – perhaps you would like them to occur at a relatively fixed interval – you can ask your Merkato administrator to increase the “pause time” between auctions. By default the pause time is just long enough to allow allocations to be configured in the network before the next auction starts, but this can be increased to serve as a method of lengthening the time between auctions. Note that although the time between auctions is lengthened, the auctions themselves will still occur within the same short interval between pauses.
Several of these options will be discussed more fully in the following sections, as well as in the “Advanced Seller Guide” Chapter.
Seller Type of Service Options
In this section, the seller options which relate to the qualities of the bandwidth being sold are discussed. These include how buyer flows are identified, in what direction bandwidth is controlled, and how bandwidth will be limited.
Flow Identification
The router or switch must be able to distinguish data streams belonging to customers on a shared link. The option chosen is configured by the Merkato administrator based on information provided by the seller about the buyers. Our options include:
· IP address and subnet mask
· Physical Port (or logical interface)
· VLAN tag
· MAC address of next-hop router
All these options are enabled by the use of Access Control List (ACL) filters on the router which enforces the Merkato appropriations.
Use IP address and subnet mask when customer traffic is distinguished by either the source or destination IP address within the packets, or by a range of source or destination IP addresses.
Use physical port (or logical sub-interface) when customers are distinguished by the router port (or logical sub-port, also called a “sub-interface”) through which the traffic flows.
In some cases, customer traffic can only be differentiated within a device which is not the router which is doing the bandwidth apportioning. In this case, the device doing the differentiating should label packets from different buyers with unique VLAN tags, which then can be used by the control router to decide which data stream belongs to whom.
In some cases, traffic is distinguished by the device sending the data to the control router (or receiving data from it). To accommodate this application, we allow use of the MAC (physical port) address of the next-hop device to be used to distinguish customer traffic. To accommodate device replacement, we allow the control router to learn the MAC address of the next hop by asking this adjacent device for the information based on a configured IP address. (Known as “ARP” – address resolution protocol.)
Traffic Direction
In nearly all Merkato applications, bandwidth is apportioned in one direction only. For example, if the buyers’ traffic consists of locally sourced data streams, Merkato would typically be used to apportion bandwidth from the data source hosts to the distribution network. The seller will have to discuss their network structure with the Merkato administrator and determine the best setting.
Should the seller wish to sell bandwidth in both directions independently, there are a few points to consider. Data traffic seldom flows one direction only. Most protocols need at least a limited amount of bandwidth in the opposite direction to accommodate protocol acknowledgements. Generally one tenth of the bandwidth in the primary direction is sufficient. Merkato has the ability to maintain a “best effort” data path for non-bidders and bidders who receive no allocation and this feature should be used to supply the “reverse” paths.
Bandwidth Limit Method
For most applications, Merkato uses the control router’s ability to apply rate limits to traffic streams to enforce bandwidth allocations. In this mode, each buyer receives a bandwidth allocation whether they use it or not.
We have implemented support for what we call “bandwidth insurance”. This is implemented using weighted fair queue settings on the control router. In this mode, bandwidth allocations represent a minimum amount that the buyer’s traffic will receive. If buyers do not use their full allocation of bandwidth, the excess bandwidth is essentially returned to a common pool which all buyers can use. In the limiting case, a buyer could potentially use all the available bandwidth while purchasing a very small amount, assuming that all other buyers are not using their allocation during that time period.
We do not recommend using the “bandwidth insurance” mode as it tends to make the market for bandwidth collapse except during those times of congestion. Only in cases where demand exceeds supply by a significant amount, but supply cannot be increased, have we seen this mode of operation to be necessary.
Seller Market Control Options
As the seller, Merkato gives you many options with respect to manipulating the quantity available based on the current demand and market price. Some of these methods are configured once by the Merkato administrator, some can be controlled by the seller on-demand by configuring a seller agent, and some can be pre-configured to act dynamically based on changing market conditions.
Maximum/Current Bandwidth Available per Market
You must ask your Merkato administrator to initially configure the maximum bandwidth available for a link in the NSP (Network Service Provider). You can then divide that bandwidth among one or more Merkato markets, or keep it on hand for when demand in any one market increases.
A single link can be divided among any number of Spot or Reservation markets. In general, there is no advantage to creating multiple markets of the same type (i.e. multiple spot markets) unless there is some quantity of service parameter which distinguishes bandwidth of one market from another.
The reservation market has a maximum setting for total capacity on the NSP and a “current” setting on the resource agent (which must be less than or equal to that set on the NSP). Sellers will need to contact their Merkato administrator to have this value changed. Of course, the capacity should never be reduced below the amount currently reserved (and in use) by buyers.
The Spot market has multiple ways to control total capacity. The maximum is set both at the NSP and the Resource Agent. The “current” capacity is under control of the seller via their desktop agent and can be changed at the beginning of any auction.
Reservation Price Table
Reservation pricing is controlled via a table configured at the Resource Agent. Sellers will need to contact their Merkato administrator to make changes to this table. The format is similar to this:
The following values are configurable:
· Unit prices corresponding to each time column and quantity row
· Values for each time column heading
· Units for each individual time column heading
· Values for quantity row headings
· Units for all the quantity row headings
How you structure the table is entirely up to you. In general, the highest prices would be charged for short reservations for small quantities of bandwidth. Accordingly, you are likely to offer the best price for large quantities of bandwidth over long periods of time.
It is entirely up to you how you transition between these two extremes in your rate card.
Note that the first column is likely to act as an upper limit for the spot market pricing because buyers can purchase bandwidth for very small time increments at this guaranteed price.
In addition to the unit price for bandwidth, you may also specify a cancellation fee. This fee is expressed as a percentage. It represents the percentage of the value of the cancelled portion of the contract which will be charged to the buyer. For example, if the cancellation fee is 50% and the buyer cancels at the mid point of the contract, they will owe the original contract price times 50% (the remaining portion of the contract) times 50% (the cancellation fee), or 25% of the original contract on cancellation. The buyer is informed of this fee in a pop-up confirmation window when they cancel and existing reservation.
You may have Merkato interpret the price table in one of two ways, as a simple price look-up or as a dual-marginal price table.
Simple look-up Reservation Pricing
A simple look-up price table is just what it appears. You find the price square which represents both the duration and the quantity which the buyer is requesting, and this is the unit price you offer. The following table indicates the unit prices for various quantities and durations. The columns represent various reservations’ durations, and the rows represent various quantity values, which a buyer might select. Note that it is simply an expansion of the rate chart which creates it.
|
Quantity |
Duration in Days |
|
|
|
|
|
|
|
|
0.5 |
1 |
5 |
10 |
50 |
100 |
500 |
|
1 |
$300.00 |
$300.00 |
$275.00 |
$250.00 |
$225.00 |
$200.00 |
$200.00 |
|
5 |
$300.00 |
$300.00 |
$275.00 |
$250.00 |
$225.00 |
$200.00 |
$200.00 |
|
10 |
$275.00 |
$275.00 |
$250.00 |
$225.00 |
$200.00 |
$175.00 |
$175.00 |
|
50 |
$250.00 |
$250.00 |
$225.00 |
$200.00 |
$175.00 |
$150.00 |
$150.00 |
|
100 |
$225.00 |
$225.00 |
$200.00 |
$175.00 |
$150.00 |
$125.00 |
$125.00 |
|
500 |
$225.00 |
$225.00 |
$200.00 |
$175.00 |
$150.00 |
$125.00 |
$125.00 |
Marginal Reservation Pricing
Using marginal reservation pricing, the price table represents incremental prices for bandwidth and time, which fall within the given range. In other words, if there are price breaks at 5, 10, and 50 Mbps, and the customer purchases 11 Mbps, they will pay the 1 Mbps price for their first 1 Mbps, The 10 Mbps price for the bandwidth between 1 Mbps and 10 Mbps, and the 50 Mbps price for the bandwidth between 10 Mbps and 11 Mbps.
The following chart shows the effective unit prices for bandwidth when the reservation rate sheet is as shown in the example above. The columns represent various reservations’ durations, and the rows represent various quantity values, which a buyer might select.
|
Quantity |
Duration in Days |
|
|
|
|
|
|
|
|
0.5 |
1 |
5 |
10 |
50 |
100 |
500 |
|
1 |
$300.00 |
$300.00 |
$280.00 |
$270.00 |
$244.00 |
$232.00 |
$206.40 |
|
5 |
$300.00 |
$300.00 |
$280.00 |
$270.00 |
$244.00 |
$232.00 |
$206.40 |
|
10 |
$287.50 |
$287.50 |
$267.50 |
$257.50 |
$231.50 |
$219.50 |
$193.90 |
|
50 |
$257.50 |
$257.50 |
$237.50 |
$227.50 |
$201.50 |
$189.50 |
$163.90 |
|
100 |
$241.25 |
$241.25 |
$221.25 |
$211.25 |
$185.25 |
$173.25 |
$147.65 |
|
500 |
$228.25 |
$228.25 |
$208.25 |
$198.25 |
$172.25 |
$160.25 |
$134.65 |
Note
that the effective unit prices in the chart are only valid for the exact
durations and quantities shown.
Durations and quantities which fall within the sample values would have
their own unique unit prices, falling somewhere between those given here.
Spot Market Floor Price
The seller has control over the spot market floor price. This is the lowest unit price for which the seller is willing to allow buyers to purchase bandwidth. This price is very important for the seller since it is not only the minimum price which will be received, it is also the price which will be charged to all buyers if all the bandwidth allocated to the market is not sold. This is because Merkato (under a dynamic seller strategy) charges all buyers the price of the last unit of bandwidth sold. If all the bandwidth is not sold, the floor price is used as the basis for pricing.
The floor price is set in the seller valuation panel, shown in the Express interface, below
Any changes made take effect at the start of
the next auction. The price in the “Budget/Max Value” field represents the
amount desired for the entire “Max Qty”. Therefore the unit price is the
“Budget/Max Value” divided by the “Max Qty”. Note that if you change the “Max
Qty” to raise or lower the amount of bandwidth available in the marketplace,
you must proportionally raise or lower the “Budget/Max Value” to maintain the
same unit floor price.
Spot Market Selling Strategy
Merkato allows you to select among two seller strategies, dynamic and static, which essentially change the way bandwidth is priced.
The static strategy is the basic mode of operation for Merkato. It is based on the original second price auction mechanism where the successful bidder obtains the item being auctioned based on the price offered by the next highest unsuccessful bidder. In the case of bandwidth, this is interpreted to mean the amount offered by losing bidders for the same amount of bandwidth. If the total amount of bandwidth requested by losing bidders is less than that of the successful bidder being priced, the difference is made up using the floor price. The disadvantage of this selling strategy is that because buyers are allowed to bid many times during an auction cycle, there are rarely any unsuccessful bidders and virtually every auction would close at the floor price. For this reason, the pricing basis was changed by introducing a dynamic selling strategy.
Under the dynamic selling strategy, the seller’s own agent bids for all the bandwidth at a price just enough to lose. The seller’s own agent therefore creates the basis for the pricing for all bidders. As long as the dynamic seller bids just below the price offered for the last unit of bandwidth, it will never inadvertently purchase bandwidth itself. (Although it does use its status as a bidder to maintain the floor price.) The action of the dynamic seller can be observed in the Auction Table and Auction Chart displays in the desktop interface.
Spot Market Buy-Back Agents
In some cases, the seller will want to create a more complex floor price strategy. For example, the seller might wish to release additional bandwidth to the marketplace at a certain price point. This would be accomplished by increasing the amount of bandwidth available in the marketplace and simultaneously creating an artificial buyer to offer a static bid for that same amount of bandwidth at the desired price point. In order to obtain that additional amount of bandwidth, a real buyer would have to out-bid this artificial, “buyback” buyer. This same method can be duplicated to release bandwidth at various price points. In some cases, you may wish to create a buyback buyer who uses a more complex bidding strategy – essentially one which gradually releases bandwidth to the marketplace as prices rise.
Invisible Hand Networks recommends that you reveal your buy-back buyers to your legitimate buyers so that they can factor their behavior into their bidding strategy. Static buy-back agents are “self revealing”, i.e. very easy to detect by buyers using the Auction Table display. When used, they allow the seller more freedom to dynamically change the market conditions while not significantly reducing the “openness” of the market.
Reservation Market Buy-Back Agents
The maximum amount of bandwidth available via the Reservation market is configured into the Resource Agent by your Merkato administrator. In general, there is no advantage to adjusting the bandwidth more dynamically, but it is possible. You could create your own buyer agent and interact with it to obtain bandwidth on your behalf. This bandwidth would be off the market for the duration of the reservation unless you cancel the reservation prematurely.
The Seller Agent Interface
Your first point of entry to the Merkato System is through the Portal, a web-based application which provides accounting and status information, as well as access to the Merkato agents. Your version of the portal may have a slightly different appearance than that shown below, but the functionality will be the same.
The user will initially see a page which contains username
and password fields.
Enter a valid username and password to gain further entry.
Entering a valid username and password, and
pressing the “Go” button, will result in display of the top-level agent page,
shown below.
From there, entry is gained to the various pages which make up the Portal and to the agent interfaces – Express, Wizard, and Desktop. Note that the Wizard interface does not currently support Seller configuration. Selection of this interface will result in an error message.
Agent Login
· The “Wizard” interface does not currently support seller configuration. Selection of this interface will result in an error message.
· The “Desktop” interface allows you to configure your agent and view the auction in progress. Your “agent” will bid in the auction to maintain your floor price and establish a market price for bandwidth. When you activate the Desktop interface, your agent is brought to your desktop and bids on your behalf from there.
· The “Express” interface is displayed the upper left of the Portal page upon successful login. Through this interface, the user obtains status information from, and sends configuration information to, their agent in the “garage”. The Express interface is considered advanced because the fields are less interactive than the Java-based desktop interface. A seller should always keep their agent in the garage when not actively interacting with it. This is critical for seller agents because if the Seller agent ceases to bid from the user’s desktop, the auction will cease.
Installing the Java Plug-in
If this is the first time you are using Merkato on your desktop, you must download the Java version 1.3 plug-in to your browser before accessing the Desktop interface. You can allow Merkato to do this automatically for you, or you may download it directly from the source whose link is provided in the login page.
You may also download it free from Sun Microsystems. The URL is:
http://java.sun.com/products/plugin/
Follow the
instruction and download the plug-in for Microsoft Explorer. (Note: As of this
writing, to get the plug-in, you must download the entire Java Run
Time Environment, which is greater than 5 MB in size. Note also that the
Netscape version 6.1 browser for Windows appears to support the Merkato Java
applications, but it is not fully tested in version 2.0.12.)
Desktop
Interface
The “Desktop” interface allows you to control the selling agent and observe the auction in progress. Your “agent” is brought to your desktop and, if the dynamic selling strategy is used, bids on your behalf from there.
You access the Desktop through the portal login interface, selecting “Desktop” as the Interface Choice.
When the Desktop Interface is accessed, the following window will appear.
Note the instructions to not close the window. You may browse to other pages, but must leave this browser window open for the Merkato Desktop to continue operating properly.
The first window you will see is the Merkato Desktop. This is the window from which you will download one or more Merkato agents.
To download an agent, select the “Download Agent” command from the “File” menu-bar.
You will be prompted to enter the username and password for the desired agent. By default, this will be the same as the username and password you used to access the Desktop interface from the initial login (the fields will be populated with this information), but you may specify another valid username and password to download another agent.
If there is a choice, select the “garage” where the profile of your agent is kept.
When downloaded, you will see an agent window similar to the one below.
Arranging Agent Windows
By default, all agent windows are constrained to be viewed from within the Desktop window. If you wish the agent window to appear as an independent window on your Windows screen, use the “Detach” function from the Desktop menu-bar, under “Window”, as shown below.
When the “Detach All” function is activated, a check will appear beside the name in the menu-bar list to indicate this.
Whether the agent windows are inside or outside the desktop, they can be automatically arranged relative to each other. If you select “Tile All” within the “Windows” menu-bar list, the windows will arrange themselves in a tight, non-overlapping pattern
Alternatively, you may select “Cascade All”, which arranges the windows so that the upper left-hand corners are all offset from each other and the windows form an overlapping pattern, as shown below.
Arranging Panels within Agent Windows
The agent window consists of multiple panels which can be displayed or not displayed as the user wishes.
By default, panels are stacked, as shown below. Each time a panel is selected for viewing, it appears beneath the one previously activated. If you wish to close a panel, you may either use the close-box tab at the upper right hand corner of the window (looks like an “x”), or re-select the panel in the pull-down menu bar lists. The window will close and the other windows will fill in the spot it had occupied.
If you wish a more free-form placement of windows, then click on the “Stack” icon (at the far right of the icon bar) or select “Stack” from the pull-down menu under “View”. Merkato panels can be arranged at will and even overlapped. If a panel is closed, the other panels do not move to occupy the vacant space.
To resize the agent window to exactly match the panels displayed, press the “Pack” icon (second from right) or use the equivalent function under the “View” menu-bar.
Upload Function
Your agent will represent you by sending bids to a Resource Agent. Your agent may continue to bid on your behalf from a “garage” co-located with the Resource Agent when you close the agent on your desktop (and using your current desktop agent settings). This is known as “uploading” your agent. When you upload your agent, all configuration changes are saved and the agent on your desktop is closed. Uploading is accomplished by either pressing the up-arrow on the icon bar (fourth from left) or selecting the equivalent function under the “File” menu-bar. Note: Sellers must always upload their agent before exiting, or the auction will cease.
Connect/Start/Stop
The three icons at the upper left of the icon bar indicate “Connect”, “Start” and “Stop” respectively. When your desktop agent is initially downloaded, it will either be in the “started” state, if it was actively bidding in the garage, or in the “disconnected” state, if it was not actively bidding in the garage (but may be actively bidding from another desktop).
When you first download an agent, it may be disconnected from the auction. Your desktop agent will not bid or allow you to view any status if disconnected, although you may change and save configuration settings. The “disconnected” state is indicated by the connect symbol on the icon bar (to the far left) being un-depressed and un-colored.
When you connect to the auction, by depressing the icon, or selecting “Connect” from under the “Selection” menu-bar item, you may observe the auction, but are not participating in it. (This is most useful for buyers. As a seller, if you are not participating in an auction, the auction ceases.)
When you wish to start bidding, either press the “Start” icon (second from left on icon bar) or select the “Start” list item under the “Selection” menu-bar label. Bidding will start immediately with the current active settings.
Once bidding begins, pressing the “Stop” icon (third from left on icon bar) or selecting the “Stop” list item under the “Selection” menu-bar label will stop the auction. Bidding will cease and you will not only be returned to “stopped” mode, but will be disconnected as well. To re-start the auction, you will need to “Connect” once more and press “Start”.
Note that if more than one user has access to the Merkato username and password, it is possible that one bidder will be previewing an auction and be observing his own agent bidding on another user’s desktop. (If an auction is in progress when you, as a seller, access the desktop, this must be the case.) Since bidder ID’s are anonymous, there is no way to know directly which agent is yours (although once you become adept at reading the auction table and auction canvas, it is possible to identify the seller’s agent by its behavior.)
Should the user previewing the auction decide to press “Start” to begin bidding, they will see a message like the one below. Should they confirm their wish to begin bidding, their agent will gain control of the bidding process and the other agent, on other user’s desktop, will be disconnected.
The last user to log in successfully always “wins” control of the agent, and the previous user will receive an error message, as shown below, indicating that their agent is no longer bidding.
This “bumping” of an active seller agent is very disruptive to the auction and should not be done without good reason.
Spot Market vs. Reservation Market
There are two ways to purchase bandwidth in a Merkato system. Buyers may request and receive a fixed amount of bandwidth, at a fixed price, for a fixed term, or they may create a bidding strategy and contend for bandwidth with other buyers at frequent intervals. The first method is called the Reservation market and uses a reservation agent. The second method is called the Spot market and uses a spot agent. In this version of Merkato, there is no Reservation Agent for sellers (although you may wish to have your Merkato administrator create a buy-back reservation agent for you for the convenience of adding bandwidth to the marketplace). All reservation settings are pre-configured in the Merkato server.
Spot Market Agent Window
The agent window consists of multiple panels which may be displayed, or not displayed, as the user wishes. The use of each panel will be discussed individually, in roughly the order one would expect a first-time user to access them.
Resource Panel
The resource panel is accessed via the “Selection” menu-bar list. When the agent is connected to the auction, the “capacity” display will indicate the total amount of bandwidth available for sale (as set by this Seller agent itself).
Note that a single agent can only bid on one resource at a time. If you select one resource, you automatically de-select the others. Because of this, Seller agents should never have more than one resource choice.
Units Panel
The units panel is used to select display units for all the other panels as well as for several pop-up message screens.
Currency units supported are dollars (“$”) and cents (“c”).
Quantity units supported are kilobits per second (“Kbps”), Megabits per second (“Mbps”), and gigabits per second (“Gbps”).
Time units supported are minutes (“min”), hours (“h”), days (“day”) and months (“month”).
The changes to any units field take effect immediately. All values in all other panels are automatically scaled to reflect the new units without changing the actual value entered.
Seller Valuation
“Valuation” usually indicates a buyer’s maximum willingness to pay for various amounts of bandwidth. For the seller valuation, however, it is used to set the quantity of bandwidth available in the marketplace and the absolute minimum price at which it will be sold. In the course of an auction, your agent uses this valuation information to bid in response to changing market conditions.
If more than one valuation were available for the seller agent, they would all be grouped under the “Valuation” heading in the menu-bar.
The first item in the list, “Show only one” would control whether successive selections of valuation replace the previous valuation shown, or result in multiple panels being displayed. If a check mark appears before this control, only one valuation would be shown at a time.
The valuation has a “Current” radio button label at the top of the panel. Make sure this is active for the Seller Valuation. To make a valuation active, click your mouse on this button in the desired valuation panel. (Had there been a previously active valuation, it would automatically have its “Current” button de-selected.) The green arrow in the menu-bar pull-down list also indicates the valuation which is currently active.
Two configurable parameters determine the behavior of the Seller Valuation.
· “Qty” sets the current quantity for sale in the marketplace. Your agent will sell all this bandwidth to the buyers unless the cumulative bandwidth requested by buyers is less than this amount.
· “Value” sets the minimum amount of money you are willing to accept for the entire “Qty” of bandwidth. (Therefore the floor price is this “Value” divided by the total “Qty”.)
Changes to either one of these values take effect at the start of the next auction.
Note that under certain conditions you might not sell all the bandwidth you are offering.
1. You have “bought back” bandwidth because of insufficient demand at the floor price, or
2. All buyers have configured a maximum amount of bandwidth which they do not wish to exceed regardless of the price and the total demand is less that the amount offered.
If the first condition occurs, you should consider whether your floor price is too high. If the second condition occurs, there is very little you can do except sign up more buyers. If demand on the reservation market is high and the second condition occurs, you might want to consider having your Merkato administrator transfer bandwidth from the spot market to the reservation market.
Strategy – General
Once you have configured your valuation, you must configure how you you’re your agent to use that information. In this version of Merkato, there are only two strategy options for use by sellers in the Spot market: static and dynamic, which are explained in the subsections which follow.
To view only one strategy panel at a time, with the most recently selected panel replacing the previously selected panel, click on “Show Only One” at the top of the Strategy menu-bar list. A check mark will appear next to the list item. If you wish to view multiple strategies at one time, de-select the “Show Only One” option.
The active strategy is selected using the “Current Strategy” radio button at the top of each Strategy panel. Clicking on this button in any panel will activate that strategy and automatically de-activate any other strategies. A green arrow in the menu-bar list also indicates the current active strategy.
Static Seller Strategy
The static seller strategy is obsolete, but is included as a seller option for backward-compatibility. It is useful to understand how it operates because the dynamic seller strategy is implemented as an extension to it.
The static strategy is essentially a method of pricing. Each bidder’s price reflects what the seller would receive with and without the bid. It is easiest to see this as an example. In the following chart, 10 units of bandwidth for sale. Each bidder (A through F) submits a bid consisting of a unit price and a quantity desired. The highest bidder with respect to unit price receives their request, the next receives their request, and so on until all the bandwidth is allocated. Ranking continues even after the bandwidth is exhausted, as shown in the diagram. Bidder A is the highest bidder, offering a unit price of $10 for 10 units of bandwidth. According to the static pricing rules, the seller would bill him for the amount offered by the bids he displaced. The amount offered by bidder A is shown in red ($30) and the amount that he would owe is shown in green ($11). Similarly, as shown in the next diagram, bidder B’s price would be based on the losing bids which total the same quantity he requested, as shown below.
His bid for 5 units of bandwidth at a unit price of $8 would cost him $17.
The problem with this bidding strategy is that under the modern Merkato system, they represent only the first bid cycle of a round. Each losing bidder is allowed to re-bid in an attempt to gain a share of the bandwidth. Typically when they re-bid they do so by requesting a lower quantity. If, for example, each of the above bids represented a budget which the bidders could use to obtain as much bandwidth as possible, the bidding would continue until the equilibrium shown in the following diagram was reached:
Note that all bidders are now in the winner’s column and, if the static seller
rules were adhered to strictly, the seller would receive nothing! It was for
this reason that the dynamic seller strategy was developed.
Dynamic Seller Strategy
The dynamic seller strategy extends the static selling strategy to create a more reasonable pricing structure. Under dynamic seller pricing, the unit price for all bidders becomes the unit price of the last unit of bandwidth sold. How is this accomplished? By creating a bidder who always loses at the highest possible price (and for the highest possible quantity) under the static seller rules (see above). With this bidder in place, the final bids of the round that “breaks” the static seller strategy is shown below:
The dynamic seller agent would bid at the price of the lowest bidder (which is
trivial since all bidders are at the same price in this example). Therefore,
under the static seller pricing model, the basis of all bidders pricing would
be the unit price offered by the seller agent. Now, the seller receives the
price of the lowest successful bidder times the quantity for sale, which is a
much more reasonable proposition.
News
The News panel provides real-time status of your Merkato agent. It is useful when you want to get a quick summary of marketplace conditions and confirm the state of your agent.
Note that there must be a seller agent participating in an auction or else the auction stops. It is possible, however, for one seller agent to be passively observing an auction while another participates in it. It is only under these conditions that a “stopped” or “disconnected” seller agent is allowed.
When your agent is in the “disconnected” state, you will see a display similar to that below.
When connected, but not bidding, you will see a display like the one below, which indicates the capacity being offered by the seller and the current market price of the auction if it is proceeding without your agent's participation (i.e. your agent is a duplicate of the seller agent currently participating in the auction).
Once you begin bidding, you will see displays like the ones below, which add information indicating activity between your agent and the resource agent, which conducts the auction.
Allocation
For buyers, the Allocation panel provides information as to the quantity of bandwidth received and the price paid for that bandwidth at the close of each successive auction. For sellers, the allocation display will always be zero, even if the seller is forced to purchase bandwidth. (This occurs whenever the total demand for bandwidth does not exceed the amount for sale.)
The allocation panel also provides a time indicator for the current auction. Each time any buyer places a bid, the timer is reset to 60 seconds. When all bidders cease bidding (either because they are satisfied with their proposed allocation or have dropped out of the bidding at the current market price), the timer will count down to zero. At that point, the proposed allocations are turned into real allocations by the resource agent. This occurs during a "pause" period. The pause period is indicated by several changes to the time display: the timer label changing from "Time Left" to "Time Since", the font changing to red, and the counter counting up to the pause limit, rather than counting down, as before (see below).
Auction Chart
The Auction chart graphically indicates the state of the Merkato auction in progress, not only for your agent, but for all others actively bidding. For a buyer, the chart would look like this:
For sellers, the display has fewer elements because allocations are not being
made to this agent. The display will look like this:
The chart elements are:
· Auto-scaling Y-axis indicating unit price (axis is scaled to show all current bids)
· Auto-scaling X-axis indicating quantity (axis is scaled to show available quantity
· Blue dots representing the last bids received from all bidders (excluding bids by your agent)
· A red dot, with ID number, indicating the last bid from your agent
· A magenta circle representing the current proposed allocation for your agent (each time any bidder places a bid, your agent received a proposed allocation. If no other bids are received, this is the allocation you would receive)
· A solid magenta dot indicating the allocation you received during the previous auction round.
· Red line representing your agent's valuation curve as determined by settings in your active valuation panel.
· A blue shaded area representing the allocation of bandwidth to successful bidders, except for any bandwidth allocated to your agent. This area is a series of blocks, where the height represents the unit price paid and the width represents the quantity allocated. The highest bidder's block is to the right, with the next highest bidders block immediately to the left of it, until all the bandwidth available has been accounted for. By not showing the bandwidth allocated to your agent, the level of the blue shading exactly under your last bid (the red dot) indicates the current market price.
Clicking on the auction chart changes the quantity scaling from the quantity being offered by the seller to the maximum quantity specified in an agent’s valuation. (This amount is always identical for a seller agent – their maximum quantity setting determines the offered quantity.) This is useful if a buyer’s configured maximum is significantly less than the total quantity offered by the seller and they want to “zoom in” on the portion of the chart which is important to you. Note that the unit price (“Y”) axis auto-scales when you change the quantity scale, as shown below.
Auction Table
The Auction Table gives you a quantitative, real-time view of the auction in progress. The chart, above, indicates what a buyer agent would see. The chart, below, indicates what a seller agent would see, and is slightly less complex.
The columns of the Auction table may be resized (by clicking and dragging column boundaries in the header) or reordered (by clicking and dragging the column headers themselves). The columns are:
· The ID of the bidder. A bidder receives a new ID whenever it is uploaded to or downloaded from the garage.
· The quantity requested in the last bid placed (note that this may be split into multiple rows, as explained below).
· The price (unit price) requested in the last bid placed.
· The "rate" represented by the bid. This is the quantity times the price. It is the maximum cost represented by that bid, but not necessarily the price that will be paid by the bidder.
The elements of the rows of Auction Table are as follows:
· Your agent's last bid is shown with a red font. The last bids of all other agents are shown with a black font (in the blue shaded area) or with a yellow font (in the black area).
· Any bidders, including your agent, which receive an allocation of bandwidth are shown in the blue shaded area. Any bidder who does not receive an allocation is shown in the black area. If a bidder receives only a portion of an allocation, they are shown in both the blue and black areas, with their quantity split accordingly.
· The black area is used to represent the basis for the actual cost paid by your agent if it has received an allocation of bandwidth. How this is actually done is a fairly advanced topic and is explained in the chapter on the Second Price Auction rule. In summary, the yellow shaded areas to the right of the uppermost bidders in the black area indicate the basis of your cost, and the yellow shaded number with magenta font at the bottom of the table indicates your total cost. To figure your corresponding unit price, divide this number by the amount of bandwidth indicated for your agent in the blue shaded area.
Note that if your seller agent “takes a position in bandwidth” because demand does not exceed the amount for sale, the display will look like the one below:
Uploading and Exiting
When you wish to terminate a session on your desktop, you will generally want to upload your agent to the garage to continue bidding on your behalf. (Currently, uploading your agent is the only way to save configuration changes. In a future release, you will be able to save configuration changes to your agent's profile in the garage without exiting your desktop agent.)
Use either the up-arrow in the icon bar, or the "Upload" menu-bar item in the "File" category to access this function. You will be presented with a confirmation query message, as shown below.
The confirmation message indicates the garage where your agent will be placed. If you press "Cancel" at this point, you will be returned to the desktop agent and no upload will occur. Note that the confirmation message indicates whether your agent is bidding or not. If your agent is stopped when you upload, your confirmation message will look like the one below.
Make sure the bidding state is the one you wish to maintain while your agent is in the garage.
In rare instances, you will want to close your desktop window without updating your agent's profile in the garage. You will do this by selecting "Close" rather than "Upload" in the menu-bar list. When you do this, the following confirmation screen will be displayed:
Selecting "Yes" will result in an "Upload" being done before the "Close".
Selecting "No" will result in your desktop agent window being closed without saving any changes you might have made.
Selecting "Cancel" will return you to your desktop agent. Neither an "Upload" or "Close" will occur.
Help
Help screens are available at both the desktop and the agent level.
Reservation Market Agent Window
There is no reservation seller agent per se. This section describes the reservation buyer agent, which can be used by a seller to quickly regulate how much bandwidth is available on the reservation market. (You must talk to your Merkato Administrator to set up a reservation buyer for you.)
The Reservation agent gives the user the ability to obtain bandwidth for an extended period of time at a fixed price. The pricing is set by the seller and depends both on the quantity of bandwidth desired and the duration of the reservation. In the current version of Merkato, all reservations begin immediately and there is no reservation fee.
Reservations may be cancelled at any time prior to expiration, but there is a cancellation fee based on a percentage of the remaining value of the reservation. The seller sets this percentage, which may be any value between 0% (no penalty for cancellation) to 100% (no refund on cancellation). The cancellation percentage is quoted to the user at the time the reservation is made and again when the cancellation is confirmed.
Reservations are created using the Reservation Strategy panel. Active reservations are viewed and cancelled via the Reservation Table panel. These panels are not accessible unless the resource selected in the Resource panel supports reservations.
Reservation agents must be uploaded into the garage when you no longer want them displayed on your desktop. The risk for not doing so is not as significant as for the Spot agents. You will simply lose the last entries you have made in the reservation request fields, but not the reservations you have already confirmed.
The following sections describe the use of these reservation panels in detail.
Resource Panel
Although a reservation and a spot marketplace may allocate the same physical resource, they are controlled by Merkato via separate Resource Agents. In this version of Merkato, bandwidth is pre-assigned to each one of these markets, so reservations do not take bandwidth from the spot market or vice versa.
In order to access the reservation panels, you must select a reservation resource from the Resource panel. The “Capacity” display in the Resource panel informs you as to the bandwidth currently available to you in that marketplace, taking into account quantities currently being allocated to other reservation buyers.
Reservation Strategy
The Reservation Strategy panel is used to create a reservation. Since reservations start immediately, there are no “Start Date/Time” entry fields. The current time is displayed instead. (Note that there may be a delay of as much as 5 minutes from the time the user confirms a reservation until it becomes active.)
The middle group of pull-down fields represents the end date and time. It is up to the user to make sure that the date is valid (no February 30th, for example). The third group of information entry fields, at the bottom of the panel, indicate the desired quantity and calculated duration, respectively. The units for these fields match those selected in the Units panel. To complete your desired reservation profile, enter your desired amount of bandwidth and press “Get Quote”. A pop-up confirmation window will appear, similar to that shown below.
This confirmation form indicates:
· The amount you have requested
· The end date and time of your reservation
· The total cost (unit cost times quantity time duration) of your reservation
· The percentage cancellation fee, applied against the remaining value of the reservation, which will be charged should you elect to terminate a reservation before the end date and time.
Look over all this information carefully before you press “Accept”. If the end date and time is different than you specified, it indicates that you entered an invalid date and Merkato made the best guess of your intent by adding the duration to the current date and time.
Note that given the free-form nature of these fields, it is possible to specify a date and time before the current time. If you inadvertently specify an end date before the start date, an error message like the one below will be displayed.
If your reservation is for a time period which is too short, the following error message will be displayed.
If you specify a quantity which cannot be allocated to you due to other active reservations, you will receive the following error message in place of the reservation confirmation pop-up window.
This error message informs you of both your requested quantity and the quantity available, so you an make appropriate adjustments.
Reservations Table
The reservations table allows you to view and cancel reservations.
When you have confirmed your reservation, it will appear in your Reservation Table. The reservation table is accessed through the “Status” menu-bar list.
The columns of the reservation table may be resized and reordered. To resize a column, click and drag the boundary line between columns within the column header. To move a column to another position, drag and drop its header either to the right or to the left of its current position.
Should you desire to cancel a reservation, click anywhere in the row that represents the reservation. The reservation will be highlighted in blue. Then press the “Cancel Reservation” button at the bottom of the panel.
You will be presented with a confirmation pop-up window similar to that shown below.
The reservation cancellation confirmation screen indicates the following information:
· The quantity of the reservation
· The scheduled end date and time of the reservation
· The percentage cancellation fee which will be applied to the remaining value of your contract if you confirm the cancellation
· The total amount that you will be billed, based on the remaining duration of your reservation, the original total value of your reservation, and the percentage cancellation fee.
If you wish to proceed with canceling the reservation under these terms, press “Yes”. If you wish to not cancel your reservation, press “No”.
Expired reservations are automatically removed from the Reservation table a short while after their end time and date.
Portal
The portal is the entry point to gain access to the agent applications, as well as to obtain historical allocation and billing information. The user will initially see a page similar to the one below, and will enter their Username and Password to gain further entry.
Entering a valid username and password, and pressing the “Go” button, will result in display of the top-level agent page, shown below.
The Express agent interface is shown at the top of the page, with the user interface selection pull-down to the right. Below these areas are the agent status screens indicating recent allocations and market price.
The left portion of the page contains a navigation bar, which provides access to all pages of the portal:
· Agent – (The page shown) contains the Express agent interface, the user interface selection pull-down, the allocation table, and market price charts.
· Traffic – Contains Monthly, Weekly, and Daily charts of traffic associated with this user.
· Account – Contains personal information for this user, including lists of contact and payment records.
· Billing – Provides a billing interface which allows the user to create customer queries into the Merkato database, and automatically provides account balance information.
· Logout – Returns user to log-in screen.
· Contact Create – Interface to create contact records. Multiple contact records may be created for each account.
· Payment Create – Interface to create payment records. Multiple payment records may be created for each account.
Portal Agent Page
The Interface pull-down portion of the screen provides access to the Wizard and Desktop agent applications, described in their own sections of this document. The other areas of the Agent page will be described below.
Express (HTML) Interface
The Express interface is an HTML version of the Desktop interface, with some significant differences:
· It leaves your agent in the garage and controls it remotely. Should you inadvertently close this window, it will make no difference to your agent in the garage. (This is highly recommended for seller agents.)
· Your screen is not updated in real time. You must press the “Refresh” button to update information in status displays.
The Express interface is meant to support advanced users who know what the fields mean and wish to have a quick way to check agent status or make configuration changes.
You access the Express interface through the initial portal browser window. If your agent was active and bidding from the garage, you will see a window like the one below.
The two buttons at the bottom of the window control your communication with the Resource Agent.
· “Refresh” updates the read-only status fields in the windows without sending configuration changes to the Resource Agent.
· “Apply” updates the read-only status fields in the windows and sends configuration changes to the Resource Agent.
To exit the Express window without sending configuration changes to the Resource Agent, simply press “refresh”. All values saved the last time changes were applied will be restored.
The fields in this display are as follows (identified by their row headers):
· “Status” – Controls whether the agent is bidding or not. You must press “Apply” for this change to take effect.
· “Resource” – Selection list for the resource for which you are bidding. You must press “Apply” for this selection to take effect.
· “Strategy” – Auto Strategy is the only strategy supported by the Express interface. Manual strategy can be selected, but there are no bid entry fields. Reservations panels are not currently supported.
· “Current Valuation” – This is display of the valuation currently in use. To change the current valuation, display another valuation and press “Apply”.
· “Valuation View” – This pull-down menu selection allows the user to select and alter settings of valuations without making them active. When you are satisfied with the settings for a new valuation, press “Apply”. The displayed valuation will become the active (current) one, with the configuration values you have entered.
· “Valuation Parameters” – This set of panels contain the settings for the valuation chosen. You must press “Apply” after changes are made, for them to take effect. Not all parameters have meaning for all valuations. If a parameter is not used, its value is indicated as a horizontal bar.
· “Bid” – A read-only display indicating the latest bid submitted. You must press “Refresh” to update this display. If this display is missing, it indicates that your agent is inactive and not bidding.
· “Allocation” – (not shown) A read-only display indicating the allocation received in the last round. Displayed only for active buyers. You must press “Refresh” to update this display. If this display is missing, either your agent is “inactive”, or you did not receive an allocation in the previous round.
· “Units” – The selections made in this panel change the units displayed for all other panels. All values are scaled to reflect the change in units. You need not press “Apply” for this change to take effect.
Some error messages, are displayed in pop-up windows as shown below.
we need another picture here if possible
Other error messages are displayed in the browser window, above the Express Interface form.
Allocation Table
For Buyers, the Allocation table shows bandwidth allocated to this user and the amount charged for this bandwidth, for both reservation and spot market transactions. For Sellers, this table indicates reservations and allocations made to buyers of the bandwidth being offered. The last 10 transactions are shown, ordered by end time, from most recent (or future) to least recent.
Each row corresponds to a single Merkato auction (for Spot market resources) or a single reservation (for Reservation market resources). The columns are as follows:
·
Start Time – The start date and time for this
allocation
·
End Time – The end date and time for this
allocation
·
Quantity (Kbps) – The bandwidth quantity for
this allocation
·
Price ($/month/Mbps) – The unit price for this
allocation
· Cost ($) – The bottom-line cost for this allocation
The purpose of the Allocation table is to give the user an indication that Merkato auctions have been providing the desired results. You may obtain information for longer timeframes in the Billing page via custom queries.
Market Price
For spot market purchases, the market price indicates the price paid for the last unit of bandwidth sold. Under normal operation, all bidders will pay this price for the bandwidth they receive. Fluctuations of this price indicate changes in the dynamics of the market – i.e. bidders entering or leaving the market or altering their valuation profiles.
The market price graphs present two time scales:
· Average market price on an hourly basis
· Average market price on a daily basis
Several bits of information can be obtained from this chart. If the market price is at the floor price of the seller, it indicates that the demand for bandwidth is less than the supply. If the market price is above the floor price, it indicates that all the bandwidth available is being sold. Fluctuations in the price when it is above the floor indicate that buyers are changing their bidding behavior within this timeframe.
![]()
Traffic Page
For Buyers, the traffic page shows the amount of data transferred through the Merkato network control point by the data stream associated with this user. Three charts are provided to represent three timeframes:
· Daily chart showing 5 minute granularity
· Weekly chart showing 30 minute granularity
· Monthly chart showing 2 hour granularity
All three charts are based on 5 minute sample intervals. Merkato gathers traffic statistics in both the input and output direction every 5 minutes. Each 5 minute sample represents an average over that 5 minute period. In other words, peaks of duration less than 5 minutes will not be accurately represented in the charts. These 5-minute samples are used directly in the daily chart. These values are then combined into longer averages for the weekly and monthly charts.
The green-shaded portion of the chart indicates traffic in the incoming direction. Traffic indicated by the blue line is in the outgoing direction. If you are unclear which direction corresponds to “in” and “out” with respect to your application, contact your Merkato administrator.
Below each chart, are three columns of figures indicating the maximum, average, and current values for the period being displayed.
Use the traffic charts to help you decide how much bandwidth to purchase on the spot and reservations markets. Often the best buying strategy is to buy what you normally use on the Reservation market, and purchase additional bandwidth during periods of burst demand on the Spot market. The traffic charts will also help you select the maximum desired quantity for your Spot market valuation settings. There is little performance improvement, but potentially significant cost impact, to purchasing more bandwidth than you need.
For Sellers, the traffic page is not supported, and a “no data” display will be shown. In a future release we will show the sum of all the traffic for the buyers who obtain bandwidth from the seller.
- 
![]()
Account Page
The Accounting page presents account information for this user, as well as a list of Contact and Payment records.
Edit Player Form
The “Edit Player” section displays the name for this buyer configured by the Merkato administrator. A password hint and answer can be configured as well, to help the user remember their password. (Note that the user has to be logged in to see this themselves. If they forgot their password, prior to logging in, they must contact their Merkato administrator to obtain the password hint and answer.) The current password hint categories are:
· None
· Date of Birth
· City of Birth
· Mother’s maiden name
· Your Pet’s name
The response to this “question” is given in the next line. The delivery mechanism can be provided as well. Currently only e-mail or regular mail (or both) are supported for this field.
Contact List
The contact list contains the list of contact profiles you have previously created. If you click on any list item, it will bring up a page which displays the information within this record. If you wish to create a record, use the “Contact – create” utility, accessible via the page selection menu at the left of the page.
Several contacts can be created for one Merkato user account. Coordinate with your Merkato administrator as to how multiple contacts are to function relative to each other (contact of any one is sufficient, contact of all is desired, primary contact with backups, etc.)
If you click on an entry, a page will appear which indicates the contact information for the record selected. You may alter this information by clicking on the “Edit” button at the bottom of the page. (See the Contact – Create section for an explanation of filling in or altering fields within this form.)
Similarly,
selecting a payment entry displays the information for that payment method and
allows the user to edit the entry if desired.
Payment List
The payment list contains the list of payment profiles you have previously created. If you click on any list item, it will bring you to a page which displays the information within this record. If you wish to create a record, use the “Payment – create” utility, accessible via the page selection menu at the left of the page.
More than one payment method may be created for a user account, but you must contact your Merkato administrator as to how billing to multiple payment profiles is to be handled.
Billing Page
The
billing page allows Buyers to do custom queries of the accounting database as
well as display your current balance. (Currently, the Balance field displays
the charges for all known allocations. In a future release of the portal, this
will reflect the true balance, minus payments.) It has no relevance for
Sellers, but will be described here for convenience.
Billing Query Form
The billing query form allows you to select start and end dates. Rather than enter the dates manually, click on the small calendar icon to the right of the field. A pop-up calendar appears from which you may select your start and end dates.
Similarly, the resource can be selected from a list when the pie-chart icon is pressed.
The selection buttons on the right of the form control how the information is displayed on the screen. For example, displaying the information per resource without daily detail would look like this:
But
when daily detail is selected, it breaks the data down further:
Contact Create Page
The
Contact – Create page allows you to create contact records which are associated
with this user.
When your entry is complete, press the “Create” button. Should your entry be incomplete, you will be shown a screen like the one below, and allowed to edit the record further.
If you wish to edit your entry later, click on the appropriate contact record in the “Account” page and, when the information is displayed, click the “Edit” button at the bottom of the form.
When you have completed filling out the form, press the “Create” button at the bottom. If you fail to enter all necessary fields, a page will appear indicating which fields need to be fully completed.
Payment - Create Page
The Payment-Create page is used to create a database record with payment information in it. (It does not have relevance for Sellers.) The create form looks like this:
It
is designed to accommodate many different bandwidth market applications, so you
should contact your Merkato administrator to determine what information is
required.
When
you have completed filling out the form, press the “Create” button at the
bottom. If you fail to enter all necessary fields, a page will appear
indicating which fields need to be fully completed.
Should you desire to edit this record later, select it in the “Account” page,
and press “Edit” at the bottom of the display that appears. An information
entry form similar to the original “create” form will appear and you may change
any records at that time.
The Progressive Second Price Auction
The patent-pending Progressive Second Price (PSP) auction mechanism creates the rules by which the Merkato marketplace operates. The features of PSP include:
· The ability to divide resources among many bidders – not just establish one winner
· The ability to react quickly to changes in buyer’s valuation of the resource for sale.
· The ability to support any number of bidders who may enter or leave the bidding at will.
· Establishment of market mechanisms which create a fair market price for bandwidth, benefiting both buyers and sellers
· Creation of market rules, which encourage bidders to be maximally truthful about their desires and willingness to pay, which allows auctions to converge quickly.
The InvisibleHand Merkato implementation of the PSP algorithm provides the following additional features:
· Light-weight protocol between bidders and resource agent which does not contribute significantly to bandwidth utilization
· Support for multiple buyers and one seller, as well as multiple sellers and one buyer
· Support for broker agents which can buy bandwidth from one source and resell it to many buyers
· Ability of customers to create automated bidding decisions based on mix-and-match combinations of valuation, budget, and strategy.
· Inclusion of seller as a bidder which allows them to take bandwidth off the market if they do not feel the price is sufficiently high.
In order to understand the Progressive Second Price auction mechanism, it helps to consider the rules and motivations behind a non-progressive simple second price auction. In an auction where many buyers are bidding for a single item, a second price mechanism is a way to most quickly decide the highest bidder, without the normal incremental bidding process. In a simple auction, where the highest bidder pays the price they bid, bidders will raise their bids incrementally in successive bidding rounds. Each bidder’s goal is to obtain the item at the lowest price, which will be the price just above what the second-place bidder is willing to pay.
The second price rule does away with the incremental bidding – but achieves the same result - by asking each bidder for a single bid representing what they are willing to pay for the item. The first place bidder wins the item, but pays the amount offered by the second place bidder. That way, the first place bidder is guaranteed that they will not overpay for the item by revealing the maximum amount they are willing to pay and the seller gets essentially the same amount for the item that they would have had the bidding price been raised incrementally until the second place buyer dropped out.
Applying this principle to a divisible resource such as bandwidth is where the “progressive” extension of the second price auction comes in. In a Progressive Second Price auction, each bid consists of a unit price and the amount of the resource desired at that price. The bidders are ranked by unit price and then are tentatively awarded the amount they requested until the supply is exhausted. Unsuccessful bidders may re-bid in order to replace successful bidders in the ranking (hence the term “progressive”). The price every successful bidder pays is the price offered by the lowest successful bidder (in a strict interpretation of second price rules, it would be the highest unsuccessful bidder(s) who sets the price, however, the “progressive” nature of the bidding tends to turn all bidders into winners, which would leave no basis from which to set the price.) Eventually, all bidders will have been awarded a share of the bandwidth or dropped out of the bidding because the “market price” is higher than they wish to pay for any amount of bandwidth.
An example might help clarify the process. Let’s assume that the seller has 10 Mbps to sell and 6 bidders are interested. Bids indicate the amount of bandwidth desired, as well as the unit price they are willing to pay. Let’s assume that the initial bids were these:
Bidder A: 3 Mbps desired at $100 unit price ($300 total)
Bidder B: 5 Mbps desired at $80 unit price ($400 total)
Bidder C: 3 Mbps desired at $50 unit price ($150 total)
Bidder D: 4 Mbps desired at $30 unit price ($120 total)
Bidder E: 6 Mbps desired at $20 unit price ($120 total)
Bidder F: 3 Mbps desired at $10 unit price ($30 total)
Bidders would be ranked according to their offers as shown in the following chart:
Figure 1 Stacked Bids Received for Portions of 10 Mbps of Bandwidth Offered by Seller
The shaded area represents the amount of money the seller is being offered (unit price times quantity). The green shaded area at the left represents the amount offered by successful bidders.
It might be instructive to determine what the seller would receive had he had simply taken the highest initial offers. As you can see, with 10 Mbps for sale, the highest two bidders (“A” and “B”) would receive what they want, and the third highest (“C”) would receive two of the three Mbps he desired. If the seller simply accepted the offers, they would receive $300 + $400 + $100 = $800 for the bandwidth offered from the successful bidders. This represents $80 per Mbps average price for the 10 Mbps offered.
Now lets look at how the bandwidth would be sold in a Merkato Progressive Second Price auction. To recap, the rules of the second price auction are as follows
All bidders may make multiple sequential offers
After each offer is received, the “resource agent” (which runs the auction) ranks the bids according to price offered and apportions bandwidth to the highest bidders
The price at which the lowest successful bidder receives bandwidth is the “market price”, which every successful bidder pays.
The bid and re-bid cycle repeats until all bidders are satisfied with the amount of bandwidth received and their price or have dropped out of the bidding.
Let’s assume that the initial offers from all bidders are as before. All bidders would be informed that the current market price is $50 and the successful and unsuccessful bidders would be informed of their status and allocation (if any). If the second price auction stopped here, the seller would receive $50 for each unit of bandwidth, or a total of $500 for the 10 Mbps of bandwidth, which is $300 less than he would have received by simply accepting the initial offers. Fortunately, for the seller, the process does not end here!
The unsuccessful bidders will bid again, if they can afford to. Bidders "stay in the game" by increasing the unit price offered for bandwidth, above that of the lowest successful bidder. How can a bidder afford to do this if they revealed what they are willing to pay in their first bid? Well, assume that the bidder’s initial offer was determined by a total cost limit as opposed to a desired unit price. In this case, the bidder would desire to re-bid as long as a consistent total cost was maintained - by lowering the requested amount of bandwidth proportionally to any increase in offered unit price. (In Merkato, this price vs quantity information is carried by the valuation settings.) Let’s assume, for simplicity, that all the bidders follow this same strategy and that their initial bids represent their total budget for bandwidth.
Bidder “D” was the highest unsuccessful bidder, offering a unit price of $30 for 4 units of bandwidth. This represents a budget of $120. Bidder “D” sees he can become a successful bidder, this round, by bidding above a unit price of $50. His next offer could be 60 unit price for 2 Mbps of bandwidth and stay within his budget limits. Each bidder can do this in turn if they find themselves pushed out of the successful bidder’s column. Although all the examples so far have involved increments of 1 Mbps of bandwidth, bidders are under no such restriction. Even bidder “F”, with a $30 budget, may become a successful bidder by asking for a fractional amount of bandwidth.
A simulation shows that when the bidding ends, the final bids would look like this:
Bidder A: 2.7 Mbps desired at $112 unit price ($300 total)
Bidder B: 3.6 Mbps desired at $112 unit price ($400 total)
Bidder C: 1.3 Mbps desired at $112 unit price ($150 total)
Bidder D: 1.1 Mbps desired at $112 unit price ($120 total)
Bidder E: 1.1 Mbps desired at $112 unit price ($120 total)
Bidder F: 0.2 Mbps desired at $112 unit price ($30 total)
The chart, below, shows the bids graphically, as before:
Figure 2 Auction Results Under Progressive Second Price Mechanism
The market price of $112.00 represents the amount all bidders would have to offer in order that all are awarded bandwidth, but stay within their initial budget. The seller would receive $1120.00 for the 10 items.
Every bidder is a “winner” and receives an amount of bandwidth proportional to their willingness to pay and consistent with the bidding policies they established for their Merkato agent.
Advanced Sellers Guide
As a seller, we assume your goal is to maximize the revenue received from bandwidth sales. From Merkato’s point of view, you will be maximizing the quantity of bandwidth sold times the unit price received for that bandwidth. Merkato provides the seller with several revenue-optimizing controls. We will break these down into controls which come into play during an auction, ones which can be altered on-demand via the seller agent, and ones which currently require the Merkato administrator to alter (longer term, strategic controls).
All these controls have one thing in common, they either control the amount of bandwidth available or the price at which additional bandwidth will be made available.
Controls which react to market conditions
At the start of each Spot Market auction, the seller floor price and quantity available for sale is determined by settings in the seller agent’s valuation panel. If the seller would like to release or remove bandwidth during an auction in response to changing market conditions, this can only be done via buyer agents configured by the seller. Essentially these buyer agents contend with actual buyers for bandwidth. Because ”real” buyers must out-bid these buyer agents to obtain the bandwidth they hold, the end result is that bandwidth is withheld from the marketplace until a desired price point is reached.
Although any valuation can be used for buy-back buyers, we recommend the use of the inelastic valuation for several reasons:
(1) It is very easy to determine the amount of bandwidth “held back” by inelastic buyers and the price at which they will release it. Use of buyers with other valuations require extensive modeling to ensure that they will release the desired amount of bandwidth at the desired price points.
(2) It is relatively easy for “real” buyers to detect the presence and determine the settings for inelastic buyers. One of the important features of Merkato is its “openness” – the ability of buyers to view what all other buyers have offered for bandwidth in order to optimize their strategy. If buyers can easily detect the price points at which more bandwidth is released to the market, they can incorporate it into their buying strategies. Also, the transparency of the inelastic bidder’s settings allows the seller to change the price point or quantities for these buyers without feeling the necessity to send out a notice to all buyers of a change.
To illustrate how these buy-back agents would work, consider a case where the seller has a floor price of $100 per Mbps for the first 25 Mbps of bandwidth released to the market, and is willing to release three more 25 Mbps blocks of bandwidth if the price reaches $125, $150, and $175 respectively. This would be accomplished with the following seller/inelastic valuation settings for the seller agent and 3 buy-back agents:
|
|
Seller Agent |
Buy-back Agent 1 |
Buy-back Agent 2 |
Buy-back Agent 3 |
|
Max Quantity Setting |
100 Mbps |
25 Mbps |
25 Mbps |
25 Mbps |
|
Max Value Setting |
$10000 |
$3125 |
$3750 |
$4375 |
|
Resulting unit price |
$100 per Mbps |
$125 per Mbps |
$150 per Mbps |
$175 per Mbps |
A few cautionary notes are in order:
(1) The additional bandwidth will be released at each price point only when the market price for all buyers exceeds the unit price represented by the buy-back buyer settings. There is no way to penalize only the buyer who desires an unusual amount of bandwidth for a short amount of time.
(2) You cannot use this method to reduce the price for bandwidth as demand goes up (i.e. provide a quantity discount). This kind of pricing is possible in the reservation market, however.
(3) These buy-back buyers tend to hold the market price at their level until demand is sufficient to reach the next level. This is because, until demand is sufficient to take all their bandwidth away, these bidders act as the lowest successful bidder and set the market price. There is nothing wrong with this, but the “stickyness” of the market price tends to surprise some first-time observers.
(4) Changes in the settings of buy-back buyers take effect as soon as “apply” is pressed and will take effect the auction in progress.
On-demand controls
Merkato provides a great many controls which are controlled by desktop agents and, in the case of the spot market, take effect at the beginning of the next auction. These are:
(1) Quantity available in the spot market. (set via the Seller valuation)
(2) Price floor in the spot market set via the seller valuation)
(3) Quantity available in the reservation market (controlled via buy-back reservation agent controlled by the seller).
Items (1) and (2) have been described fully in the Seller Valuation section of this manual.
Item (3) is the reservation equivalent of the spot market buy-back agents. For example, if a seller has a maximum of 300 Mbps they would like to potentially sell on the reservation market, but currently want to release only $100 Mbps, they could do so by using their own reservation agent to secure the additional 200 Mbps. At any time they wish to release additional bandwidth to the reservation market, it would be necessary to simply cancel the existing reservation. If required, multiple reservation agents could be used to release bandwidth to the market more gradually, depending on market conditions.
Settings Controlled by Merkato Administrator
Settings controlled by the Merkato administrator require advanced notice to change, so should be considered strategic rather than tactical controls. Often the Merkato server will have to be rebooted to have these changes take effect. These controls include:
· Duration of the Spot Market auctions
· Absolute limit to amount which can be sold in the Spot Market
· Maximum Account Balance
· Reservation Price Chart
· Reservation Cancellation Fee
· Bid fee controls (used to limit the length of auctions and potentially could be used as broker fees)
Bid Fees
A basic part of the Merkato system is the concept of bid fees. These serve two purposes:
1. Limit the theoretical length of auctions and prevent auction instability
2. Provide revenue stream for pure bandwidth exchange “brokers”
The way bid fees work as follows. The resource agent has pre-configured settings for the following values:
· Initial Bid Fee Increment
· Number of Bids to Double Fee Increment (MaxNbids)
· Max Bid Fee
The fee for submitting a bid increases continuously throughout the auction. As the bid fee increases, it influences an agents behavior in two stages. The first effect is that the agent will not submit a new bid if it thinks the financial benefit of the new bid is outweighed by the current bid fee. This can be considered a “soft limit” imposed by the bid fee. If the auction continues past this point, there is also a hard limit involved – as soon as the bid fee reaches the maximum bid fee value, the auction is stopped and allocations made based on the last bids received.
The resource agent keeps track of the bid fee for each bidder. Each time a bid is received from any bidder, the resource agent will increment the bid fee by the bid fee increment and inform all bidders what the new value is. Every time the number of total bids reaches the configured “MaxNbids”, the bid fee increment is doubled. For example, if the Initial Bid Fee Increment is “1”, and MaxNbids is 100, then the bid fee after the first bid would be “1”, after the second bid it would be “2”, and so on until 100 bids were received. Thereafter the bid fee increment doubles, so that following the next bid, the fee would be 102, then 104, then 106, etc. After 200 bids, the fee would start incrementing by 4 each bid, after 300 bids, by 8, etc.
In most Merkato installations, the bid fee is used to prevent unstable bidding patterns from keeping auctions running forever, but the amount is not actually charged to customers. In a large part, this is because the agent behavior is automated and customers have little or no control over the frequency at which their agents bid.
In the future, customers who use
Merkato to run bandwidth exchanges may elect to charge the bid fee as a fee for
their services.
Appendix A Buyer Valuation Formulas
If you wish to enter the valuation formulas into a spreadsheet to analyze them, they are provided below. Remember, this is what you bid, but your actual cost is based on the market price as determined by progressive second price auction rules.
The curves will vary according to settings in the valuation panels. To avoid confusion, the names of the settings have been given in the formulas as:
· “Budget” for budget settings in budget-based valuations
· “MaxQty” for either “Max Qty” in Budget-with-limits or the single “Qty” setting in the other valuation panels
· “MinQty” for the minimum quantity setting in the Budget-with-limits valuation
· “MaxValue” for the “Value” setting in the valuation panels
The variables in the equations are:
· “Price” for the unit price
· “Qty” for the quantity of bandwidth which will be requested at that price
Note that the units do not matter as long as you are consistent throughout:
· Budget is in currency per unit time (such as $/month). (Often for simplicity in discussions, we omit the “per month” part.)
· Quantities are quantities of bandwidth expressed in Gbps, Mbps, or Kbps
· Price is in currency per unit bandwidth per unit time (such as $/Mbps/month). (Often for simplicity in discussions, we omit the “per month” part.)
· MaxValue is in terms of currency per unit time (such as $/month). (Often for simplicity in discussions, we omit the “per month” part.)
To convert price to cost, multiple by the quantity (“Qty” in the equations)
Budget Demand
Price = Budget / Qty
Budget-with-limits Demand
For Qty < MinQty
Price = Budget / MinQty
For MinQty <= Qty <= MaxQty
Price = Budget / Qty
For Qty > MaxQty
Price = 0
Inelastic Demand
For Qty <= MaxQty
Price = MaxValue / MaxQty
For Qty > MaxQty
Price = 0
Elastic Demand
Note: “SQRT” = Square Root of what follows in parentheses
For Qty <= MaxQty
Price = MaxValue / ( 2 * SQRT( MaxQty )*SQRT( Qty ))
For Qty > MaxQty
Price = 0
Logarithmic Demand
Note: “Ln” = Natural logarithm of what follows in parentheses
For Qty <= MaxQty
Price = ( MaxValue / MaxQty ) * Ln(MaxQty / Qty ) )
For Qty > MaxQty
Price = 0