The quality of service received through an LES connection depends on many factors and hard guarantees cannot be provided. What LES and its flow control design aims at is some degree of predictability. Servers have an estimate of their serving capacity for different types of requests and assign maximum estimated cost values for each request type. They also define the concept of bandwidth which equals the "minimum recharge rate" flow control parameter.
In the current implementation the request cost is interpreted as a conservative estimate for the serving time of the request in a single thread, in nanoseconds. After serving the request, the difference between the upper estimate and the actual serving time is added to the buffer as extra recharge (if positive). If some client buffers are already full then the unused amount of buffer recharge is also distributed among the currently recharging ones, proportionally to their bandwidth.
Since bandwidth is specified as maximum recharged units per millisecond, a total bandwidth of one million means that request serving can occupy at most one thread on average. This is specified in geth by setting the --lightserv parameter to 100 (note that the new server implementation supports values over 100 too). This helps server to operate predictably, with a controlled risk of short term request congestion.
Regardless of whether selecting paid servers happens automatically or manually, if we want to introduce a true market mechanism into the LES service ecosystem then clients need to be able to estimate the value of service offered at a given price and compare the offers to each other. Though bandwidth values of different servers cannot be compared to each other directly, clients can expect the actual serving capacity of a particular server (as experienced on the client's end) to be proportional to the negotiated bandwidth, with a server-specific correction factor. Again, there are no hard guarantees for a server behaving according to the expectations but the clients can (and in the current implementation they already do) make statistics and choose servers with consistently good track records. The point is that a server can easily behave predictably according to this model if parametrized properly.
The server has a private API providing three functions for controlling client bandwidth:
TotalBandwidth()queries the total available bandwidthMinimumBandwidth()queries the minimum bandwidth that can be assigned to a client. This ensures that there is enough buffer limit for the necessary requests and all mechanisms (ODR, header downloader, transaction sending) can operate properly.SetClientBandwidth(id, bandwidth)ensures guaranteed connection for a priority client with the specified bandwidth. Unlike free clients, such a client will never be kicked out.
SetClientBandwidth can only assign a total amount not greater than the system-wide total bandwidth. Free clients can use the remaining bandwidth that is not assigned to any client or assigned to one that is currently not connected. This means that a priority client connecting can cause multiple free clients to be kicked out instantly. Calling SetClientBandwidth with zero bandwidth revokes the priority status of a client. Bandwidth can also be assigned, changed or revoked while the client is connected. LES supports changing the flow control parameters through an AnnounceMsg.
This API allows different payment or other kind of prioritization schemes. One simple scheme that can be implemented with this API right away is a long-term subscription model similar to VIPnodes. A more sophisticated payment channel-based in-protocol payment system is also planned.