Finish docs.
diff --git a/doc/load-balancing.md b/doc/load-balancing.md
index 03c9bd2..4ed938c 100644
--- a/doc/load-balancing.md
+++ b/doc/load-balancing.md
@@ -11,7 +11,7 @@
Prior to any gRPC specifics, we explore some usual ways to approach load
balancing.
-### Proxy Model
+## Proxy Model
Using a proxy provides a solid trustable client that can report load to the load
balancing system. Proxies typically require more resources to operate since they
@@ -21,7 +21,7 @@
The proxy model was deemed inefficient when considering request heavy services
like storage.
-### Balancing-aware Client
+## Balancing-aware Client
This thicker client places more of the load balancing logic in the client. For
example, the client could contain many load balancing policies (Round Robin,
@@ -41,7 +41,7 @@
the load balancing complexity of multiple layers and presents it as a simple
list of servers to the client.
-### External Load Balancing Service
+## External Load Balancing Service
The client load balancing code is kept simple and portable, implementing
well-known algorithms (e.g., Round Robin) for server selection.
@@ -56,7 +56,7 @@
# Requirements
-### Simple API and client
+## Simple API and client
The gRPC client load balancing code must be simple and portable. The
client should only contain simple algorithms (e.g., Round Robin) for
@@ -68,7 +68,7 @@
complex decisions and inform the client. The load balancer may communicate
with the backend servers to collect load and health information.
-### Security
+## Security
The load balancer may be separate from the actual server backends and a
compromise of the load balancer should only lead to a compromise of the
@@ -90,13 +90,13 @@
are discouraged from trying to extend gRPC by adding more. Instead, new
load balancing policies should be implemented in external load balancers.
-## Load Balancing Policies
+## Workflow
Load-balancing policies fit into the gRPC client workflow in between
name resolution and the connection to the server. Here's how it all
works:
-![image](images/load_balancing_design.png)
+![image](images/load-balancing.svg)
1. On startup, the gRPC client issues a [name resolution](naming.md) request
for the server name. The name will resolve to one or more IP addresses,
@@ -130,33 +130,3 @@
received.
6. The gRPC client will send RPCs to the gRPC servers contained in
the server list from the Load Balancer.
-
-## Client
-
-When establishing a gRPC _stream_ to the balancer, the client will send an initial
-request to the load balancer (via a regular gRPC message). The load balancer
-will respond with client config (including, for example, settings for flow
-control, RPC deadlines, etc.) or a redirect to another load balancer. If the
-balancer did not redirect the client, it will then send a list of servers to the
-client. The client will contain simple load balancing logic for choosing the
-next server when it needs to send a request.
-
-## Load Balancer
-
-The Load Balancer is responsible for providing the client with a list of servers
-and client RPC parameters. The balancer chooses when to update the list of
-servers and can decide whether to provide a complete list, a subset, or a
-specific list of “picked” servers in a particular order. The balancer can
-optionally provide an expiration interval after which the server list should no
-longer be trusted and should be updated by the balancer.
-
-The load balancer may open reporting streams to each server contained in the
-server list. These streams are primarily used for load reporting. For example,
-Weighted Round Robin requires that the servers report utilization to the load
-balancer in order to compute the next list of servers.
-
-## Server
-
-The gRPC Server is responsible for answering RPC requests and providing
-responses to the client. The server will also report load to the load balancer
-if a reporting stream was opened for this purpose.
diff --git a/doc/service_config.md b/doc/service_config.md
index 6093fc3..7318b69 100644
--- a/doc/service_config.md
+++ b/doc/service_config.md
@@ -123,6 +123,9 @@
}
```
+Note that new per-method parameters may be added in the future as new
+functionality is introduced.
+
# Architecture
A service config is associated with a server name. The [name
@@ -131,71 +134,14 @@
TODO(roth): Design how the service config will be encoded in DNS.
+# APIs
+The service config is used in the following APIs:
-
-The gRPC load balancing implements the external load balancing server approach:
-an external load balancer provides simple clients with an up-to-date list of
-servers.
-
-![image](images/load_balancing_design.png)
-
-1. On startup, the gRPC client issues a name resolution request for the service.
- The name will resolve to one or more IP addresses to gRPC servers, a hint on
- whether the IP address(es) point to a load balancer or not, and also return a
- client config.
-2. The gRPC client connects to a gRPC Server.
- 1. If the name resolution has hinted that the endpoint is a load balancer,
- the client's gRPC LB policy will attempt to open a stream to the load
- balancer service. The server may respond in only one of the following
- ways.
- 1. `status::UNIMPLEMENTED`. There is no loadbalancing in use. The client
- call will fail.
- 2. "I am a Load Balancer and here is the server list." (Goto Step 4.)
- 3. "Please contact Load Balancer X" (See Step 3.) The client will close
- this connection and cancel the stream.
- 4. If the server fails to respond, the client will wait for some timeout
- and then re-resolve the name (process to Step 1 above).
- 2. If the name resolution has not hinted that the endpoint is a load
- balancer, the client connects directly to the service it wants to talk to.
-3. The gRPC client's gRPC LB policy opens a separate connection to the Load
- Balancer. If this fails, it will go back to step 1 and try another address.
- 1. During channel initialization to the Load Balancer, the client will
- attempt to open a stream to the Load Balancer service.
- 2. The Load Balancer will return a server list to the gRPC client. If the
- server list is empty, the call will wait until a non-empty one is
- received. Optional: The Load Balancer will also open channels to the gRPC
- servers if load reporting is needed.
-4. The gRPC client will send RPCs to the gRPC servers contained in the server
- list from the Load Balancer.
-5. Optional: The gRPC servers may periodically report load to the Load Balancer.
-
-## Client
-
-When establishing a gRPC _stream_ to the balancer, the client will send an initial
-request to the load balancer (via a regular gRPC message). The load balancer
-will respond with client config (including, for example, settings for flow
-control, RPC deadlines, etc.) or a redirect to another load balancer. If the
-balancer did not redirect the client, it will then send a list of servers to the
-client. The client will contain simple load balancing logic for choosing the
-next server when it needs to send a request.
-
-## Load Balancer
-
-The Load Balancer is responsible for providing the client with a list of servers
-and client RPC parameters. The balancer chooses when to update the list of
-servers and can decide whether to provide a complete list, a subset, or a
-specific list of “picked” servers in a particular order. The balancer can
-optionally provide an expiration interval after which the server list should no
-longer be trusted and should be updated by the balancer.
-
-The load balancer may open reporting streams to each server contained in the
-server list. These streams are primarily used for load reporting. For example,
-Weighted Round Robin requires that the servers report utilization to the load
-balancer in order to compute the next list of servers.
-
-## Server
-
-The gRPC Server is responsible for answering RPC requests and providing
-responses to the client. The server will also report load to the load balancer
-if a reporting stream was opened for this purpose.
+- In the resolver API, used by resolver plugins to return the service
+ config to the gRPC client.
+- In the gRPC client API, where users can query the channel to obtain
+ the service config associated with the channel (for debugging
+ purposes).
+- In the gRPC client API, where users can set the service config
+ explicitly. This is intended for use in unit tests.