Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A27: xDS-Based Global Load Balancing #170

Open
wants to merge 7 commits into
base: master
from
Open

Conversation

@markdroth
Copy link
Member

markdroth commented Jan 8, 2020

No description provided.

@markdroth markdroth requested review from ejona86 and dfawley Jan 8, 2020
@ejona86
ejona86 approved these changes Jan 8, 2020
Copy link
Member

ejona86 left a comment

LGTM (assuming FIXME is resolved, and that's not even that big of a deal.)

to query for the `Cluster` resource with the cluster name from the LB
policy configuration.

Initially, the CDS policy will support only hard-coded cluster names, so

This comment has been minimized.

Copy link
@ejona86

ejona86 Jan 8, 2020

Member

Do you mean "policy names" instead of "cluster names"?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

No, it was correct as written, but the wording was a bit confusing. I've attempted to clarify.

client will make a CDS request asking for that specific cluster name.

Because we are requesting one specific resource by name, the CDS response
should include exactly one `Listener`. However, many existing xDS servers

This comment has been minimized.

Copy link
@ejona86

ejona86 Jan 8, 2020

Member

s/Listener/Cluster/ ?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Good catch, fixed.

@dfawley
dfawley approved these changes Jan 9, 2020
Copy link
Contributor

dfawley left a comment

Just one nit (in 3 places) otherwise LGTM pending the FIXME.

should be tolerant of servers that may ignore the requested resource name;
if the server returns multiple resources, the client should look for the one
with the name it asked for, and it should ignore the rest of the entries.
Comment on lines 285 to 287

This comment has been minimized.

Copy link
@dfawley

dfawley Jan 9, 2020

Contributor

Use "must" instead of "should"? Or "will" may better match the wording in the rest of the document.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Done.

should be tolerant of servers that may ignore the resource name in the
request; if the server returns multiple resources, the client should look
for the one with the name it asked for, and it should ignore the rest of
Comment on lines 308 to 310

This comment has been minimized.

Copy link
@dfawley

dfawley Jan 9, 2020

Contributor

As above: s/should/???/

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Done.

should be tolerant of servers that may ignore the requested resource name;
if the server returns multiple resources, the client should look for the one
with the name it asked for, and it should ignore the rest of the entries.
Comment on lines 367 to 369

This comment has been minimized.

Copy link
@dfawley

dfawley Jan 9, 2020

Contributor

As above: s/should/???/

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Done.

resources. Configures the set of endpoints (backend servers) to load
balance across and may tell the client to drop requests.

gRPC will support the Aggregate Discovery Service (ADS) variant of xDS,

This comment has been minimized.

Copy link
@junpengl

junpengl Jan 9, 2020

Willl gRPC support both State of the World (SotW) and incremental variant of ADS or just one of them?
Also does this mean that gRPC won't support basic xDS via gRPC and RESTful xDS?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Initially, we will support only SotW ADS. In the future, we may add support for (or maybe even switch to?) incremental ADS, since the incremental protocol's semantics are much clearer than the non-incremental protocol. (We've run into a lot of edge cases while implementing this, which led to efforts like envoyproxy/envoy#9029 to try to clarify the exact semantics of the protocol.)

We do not currently plan to support non-aggregated xDS. My understanding is that the trend right now is toward the aggregated variants of the protocol, and the current proposal for UDPA (the future evolution of xDS) is to offer only an aggregated protocol. So we'd prefer not to put effort into older variants that aren't really going to be used in the future.

We do not plan to support REST. After all, gRPC is intended to replace REST. :)

This comment has been minimized.

Copy link
@junpengl

junpengl Jan 9, 2020

Those all sounds reasonable to me. Maybe it would be useful to put some of the info here? Like only support SotW ADS now and may switch to incremental ADS.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 9, 2020

Author Member

Done.

When the channel attempts to connect, the xds resolver will
instantiate an XdsClient object and use it to send an xDS request for
Comment on lines 157 to 158

This comment has been minimized.

Copy link
@euroelessar

euroelessar Jan 11, 2020

Are XdsClients of different gRPC channels going to share underlying TCP connections to XDS backend and/or XDS ADS stream?
For instance, what is a behavior in case if single process has 100 different gRPC channels powered by xds resolver/balancer?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 13, 2020

Author Member

Each channel that uses an "xds:" URI will have its own channel to the xds server. For Java and Go, this means that there will actually be a separate TCP connection to the xds server. For C-core, however, because we share subchannels between channels, if there are multiple channels open to the same xds server, we will share the underlying TCP connection. However, even when the TCP connection is shared, there will be a separate ADS stream for each channel.

We have discussed in the past the possibility of sharing the XdsClient between channels. We may be able to implement that in the future if the duplicate TCP connections or duplicate ADS streams become a problem.


The `ClusterLoadAssignment` proto must have the following fields set:

- The `endpoints` field must contain at least one entry. In each entry:

This comment has been minimized.

Copy link
@euroelessar

euroelessar Jan 11, 2020

Is LocalityLbEndpoints.load_balancing_weight field for supported?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 13, 2020

Author Member

Yes. Thanks for catching this -- I've added it to the doc.

- The `lb_endpoints` field must contain at least one entry. In each entry:
- If the `health_status` field has any value other than HEALTHY or
UNKNOWN, the entry will be ignored.
- The `endpoint` field must be set. Inside of it:

This comment has been minimized.

Copy link
@euroelessar

euroelessar Jan 11, 2020

Is LbEndpoint.load_balancing_weight field supported?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 13, 2020

Author Member

No, it will not be supported initially, but this is something we want to do in the future. We have some more design work to do before we can support weighted round robin for endpoint picking.

- If the `lrs_server` field is set, it must have its `self` field set, in
which case the client should use LRS for load reporting. Otherwise
(the `lrs_server` field is not set), LRS load reporting will be disabled.
Comment on lines +388 to +390

This comment has been minimized.

Copy link
@euroelessar

euroelessar Jan 11, 2020

Is gRPC implementation going to (eventually) coalesce the data for multiple clusters within the same LRS stream given the same lrs_server?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 13, 2020

Author Member

Communication with the LRS server will be handled by the XdsClient. So if a given channel is talking to multiple clusters, all of those clusters will be reported on the same LRS stream. However, for now, each gRPC channel that uses xds will have its own XdsClient and will therefore also have its own LRS stream. If we decide in the future to change things such that we share one XdsClient between gRPC channels, then we would probably be able to combine the data from multiple channels into a single LRS stream.

string and whose route field must be set. Inside that route message,
the cluster field will indicate which cluster to send the request to.
Comment on lines +331 to +332

This comment has been minimized.

Copy link
@euroelessar

euroelessar Jan 11, 2020

Is there a possibility in the future to give access to per-route filter configs to application interceptors (or some other channel filters)?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 13, 2020

Author Member

Eventually, yes, we would like to allow interceptors to be configured via xds. However, we need to do some design work before we can make this happen, because there are some significant architectural differences between Envoy filters and gRPC interceptors that cause data model mismatches between xds and gRPC.

does not specify a port.

Because we are requesting one specific resource by name, the LDS response
should include exactly one `Listener`. However, many existing xDS servers

This comment has been minimized.

Copy link
@voidzcy

voidzcy Jan 14, 2020

There is some confusion for legacy management servers: I am assuming "do not support requesting one specific resource" means "do not honor resource names in the request". Currently we require the management server to always send client newly requested resources, this implies that server needs to honor what the client requests for. Therefore, I doubt if this kind of legacy management servers would still work for us.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 14, 2020

Author Member

I am assuming "do not support requesting one specific resource" means "do not honor resource names in the request".

Correct.

Currently we require the management server to always send client newly requested resources, this implies that server needs to honor what the client requests for. Therefore, I doubt if this kind of legacy management servers would still work for us.

For LDS and CDS, legacy management servers will always send all resources in every response. Therefore, even if the server ignores the resource_names field, sending a new request will cause the server to send a new response containing all resources, which must by definition include the new one being requested.

We should not have a problem supporting legacy management servers.

Copy link

htuch left a comment

This is awesome, very exciting to see this gRFC and xDS gain a new client. Flushing out some comments (up to the CLA proto section..).

subscribing to a different type of configuration resource. In the xDS
API flow, the client uses the following main APIs, in this order:

- __Listener Discovery Service (LDS)__: Returns `Listener` resources.

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Do you want to link back to some reference or proto for each of these resources?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Done.


The `node` field will be populated with the [xDS `Node`
proto](https://github.com/envoyproxy/data-plane-api/blob/1adb5d54abb0e28ca409254d26fad1cf5535239b/envoy/api/v2/core/base.proto#L85).
Note that the `build_version` field should not be specified in the

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Do you want to also mention the user agent name/version here, since build_version is deprecated?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

For now, we're going to populate build_version, since that's what existing management servers will be looking at. We can add support for the new fields as management servers start to look at them.

target URI used to create the gRPC channel. For example, a user may
create a channel using the URI "xds:example.com:123" or
"xds:///example.com:123", which will use xDS to establish contact with
the server "example.com:123". The "xds" URI scheme does not support any

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Is there any way we can standardize this URI scheme for other environments that want this ability to opt-in to xDS? I assume Envoy Mobile doesn't care as it always uses xDS (@junr03)

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

I am certainly open to doing this if anyone else wants to use this URI scheme.

It's worth noting that the way that gRPC uses URIs is a little unusual from the user's perspective: the URI does not indicate the protocol used to access the specified name but rather how to resolve the specified name. In other words, the "xds" URI scheme tells gRPC to use xDS to resolve the specified name, but no matter what URI scheme is used there, we still use gRPC to talk to the resulting addresses. This is exactly the opposite of how URIs are used in a context like a browser, where the URI scheme indicates the protocol used to access the specified name (e.g., "http", "https", "ftp", etc).

Given that, I'm not sure how many other systems will actually find this URI scheme useful. For example, I would expect Envoy Mobile to use the same types of URIs as a browser does; the use of xDS is inherent in that case, so there's no need to put it in the URI, but a URI scheme like "http" or "ftp" will be needed to determine which type of API listener to request.

But all of that having been said, if we do have someone else who wants to use this URI scheme, then I agree that it would be a good idea to standardize it.

When the channel attempts to connect, the xds resolver will
instantiate an XdsClient object and use it to send an xDS request for
a `Listener` resource with the name of the server that the client
wishes to connect to (in the example above, "example.com:123"). If the

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

There is a design choice, including port alongside hostname. This is somewhat related to how we ended up doing naming of resources for VHDS. Some resource types naturally lend themselves to a certain form. It might be worth elaborating on why you included port here, and also updating the xDS protocols docs to indicate that on-demand listeners should be named this way.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

The reasoning for this is covered in the section about LDS below. It's basically being done to allow the xDS server to define the default port. That way, we don't need to hard-code a default in the gRPC client itself.

I'm not sure that this is really relevant to the current xDS protocol docs. It's really more a data model issue than a transport protocol issue. Do we have a doc for the data model somewhere? This could probably be documented as part of describing HTTP API listeners.

config](https://github.com/grpc/grpc/blob/master/doc/service_config.md),
which the resolver will return to the channel.

In particular, the resulting service config will select use of the CDS

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Not sure how the "In particular" relates to the above (this is more a grammar nit).

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Fixed.

field, so it needs to be in host or host:port syntax. However, the gRPC
client will not interpret it in any special way. This means that the
xDS server effectively defines what the default port means if the URI
does not specify a port.

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

FWIW, this will break a lot of xDS servers that use completely arbitrary names for Listeners.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Because gRPC requires HTTP API listeners and no existing management server provides those, those management servers are already going to need to add new listener resources in order to support gRPC. Given that, I don't think it's a significant additional requirement to say that the new resources have to be named a certain way.

It's also worth noting that service owners still have a lot of flexibility in these names. The only requirements here are (a) that the name be in a form that can be used in the HTTP/2 ":authority" header and (b) that the name of the listener resource is the same name used in the URI on the client side. The contents of the name can actually be whatever the service owners want -- they don't even need to have a suffix matching any particular DNS domain.

Note that these naming requirements are basically inherent to HTTP API listeners; although gRPC is going to be the first xDS client to use HTTP API listeners, they're not really specific to gRPC. In the future, when Envoy Mobile uses HTTP API listeners, I would expect them to have the same requirements.

With regard to the broader question of requiring existing management servers to make changes to support gRPC, we would have really preferred a design where they didn't need any modifications, but we don't think that's actually feasible, because there are some inherent differences between a proxy like Envoy and a client like gRPC (e.g., the need to use API listeners). But we have tried to minimize the set of changes that existing management servers will need to make, and in general I suspect that the need to support HTTP API listeners will be the only significant change that is needed.


#### RDS

If the `Listener` does not include the `RouteConfiguration` in-line,

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Nit: inline or in-line?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Changed.

`RouteConfiguration` name specified in the `Listener`.

Because we are requesting one specific resource by name, the RDS response
should include exactly one RouteConfiguration. However, the gRPC client

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

include "at least" one..

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Changed to "no more than", since that more accurately conveys the real point here.

this by adding support for route matchers at the same time as we
add `weighted_clusters` support, in which case the final route in the
list can continue to use the `cluster` field but earlier routes can
use `weighted_clusters`.)

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

One option might be to add some additional metadata matching, e.g. allowing the route to depend on information in the Node expressing capability. Maybe.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

It's not clear to me how that would actually help address this backward-compatibility problem. Can you give an example of how that might work?

More generally, I think this is actually an area where there's a lot of friction between the xds data model and the gRPC architecture. I think that this will require some additional discussion as part of the UDPA effort (for some context, see cncf/udpa#4 (comment)).

client will make a CDS request asking for that specific cluster name.

Because we are requesting one specific resource by name, the CDS response
should include exactly one `Cluster`. However, many existing xDS servers

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Another place to consider weakening form exactly to at least one. I don't think it's a good to idea to start mandating that management servers behave a certain way when they can handle the more general case and specialize for gRPC.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Done.

Copy link

htuch left a comment

Final comment flush.

- If the `health_status` field has any value other than HEALTHY or
UNKNOWN, the entry will be ignored.
- The `endpoint` field must be set. Inside of it:
- The `address` field must be set.

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

Which parts of address? What about Unix Domain Sockets etc?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Good point -- added details on this.

We don't currently support UDS.


FIXME: Is this true? Need to resolve internal discussion and decide
whether to remove this before merging this gRFC.
- The `policy.disable_overprovisioning` field must be set to true.

This comment has been minimized.

Copy link
@htuch

htuch Jan 14, 2020

I feel this is a good candidate for client feature capabilities.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Haven't we already added the disable_overprovisioning field to xDS? Wouldn't the capability basically replace that field?

I'm open to doing this via a capability, as long as we can figure out the right transition plan. The reason for the FIXME comment here is that we've been trying to reach consensus on this with @vishalpowar and his team, so we should discuss this further.

Copy link
Member Author

markdroth left a comment

Thanks for the thorough review, @htuch! Please let me know if you have any questions about any of this.

subscribing to a different type of configuration resource. In the xDS
API flow, the client uses the following main APIs, in this order:

- __Listener Discovery Service (LDS)__: Returns `Listener` resources.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Done.


The `node` field will be populated with the [xDS `Node`
proto](https://github.com/envoyproxy/data-plane-api/blob/1adb5d54abb0e28ca409254d26fad1cf5535239b/envoy/api/v2/core/base.proto#L85).
Note that the `build_version` field should not be specified in the

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

For now, we're going to populate build_version, since that's what existing management servers will be looking at. We can add support for the new fields as management servers start to look at them.

target URI used to create the gRPC channel. For example, a user may
create a channel using the URI "xds:example.com:123" or
"xds:///example.com:123", which will use xDS to establish contact with
the server "example.com:123". The "xds" URI scheme does not support any

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

I am certainly open to doing this if anyone else wants to use this URI scheme.

It's worth noting that the way that gRPC uses URIs is a little unusual from the user's perspective: the URI does not indicate the protocol used to access the specified name but rather how to resolve the specified name. In other words, the "xds" URI scheme tells gRPC to use xDS to resolve the specified name, but no matter what URI scheme is used there, we still use gRPC to talk to the resulting addresses. This is exactly the opposite of how URIs are used in a context like a browser, where the URI scheme indicates the protocol used to access the specified name (e.g., "http", "https", "ftp", etc).

Given that, I'm not sure how many other systems will actually find this URI scheme useful. For example, I would expect Envoy Mobile to use the same types of URIs as a browser does; the use of xDS is inherent in that case, so there's no need to put it in the URI, but a URI scheme like "http" or "ftp" will be needed to determine which type of API listener to request.

But all of that having been said, if we do have someone else who wants to use this URI scheme, then I agree that it would be a good idea to standardize it.

config](https://github.com/grpc/grpc/blob/master/doc/service_config.md),
which the resolver will return to the channel.

In particular, the resulting service config will select use of the CDS

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Fixed.


In particular, the resulting service config will select use of the CDS
LB policy, described below. The configuration of the CDS policy will
indicate which `Cluster` resource will be used.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

I've attempted to clarify the wording here.

`RouteConfiguration` name specified in the `Listener`.

Because we are requesting one specific resource by name, the RDS response
should include exactly one RouteConfiguration. However, the gRPC client

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Changed to "no more than", since that more accurately conveys the real point here.

this by adding support for route matchers at the same time as we
add `weighted_clusters` support, in which case the final route in the
list can continue to use the `cluster` field but earlier routes can
use `weighted_clusters`.)

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

It's not clear to me how that would actually help address this backward-compatibility problem. Can you give an example of how that might work?

More generally, I think this is actually an area where there's a lot of friction between the xds data model and the gRPC architecture. I think that this will require some additional discussion as part of the UDPA effort (for some context, see cncf/udpa#4 (comment)).

client will make a CDS request asking for that specific cluster name.

Because we are requesting one specific resource by name, the CDS response
should include exactly one `Cluster`. However, many existing xDS servers

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Done.

- If the `health_status` field has any value other than HEALTHY or
UNKNOWN, the entry will be ignored.
- The `endpoint` field must be set. Inside of it:
- The `address` field must be set.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Good point -- added details on this.

We don't currently support UDS.


FIXME: Is this true? Need to resolve internal discussion and decide
whether to remove this before merging this gRFC.
- The `policy.disable_overprovisioning` field must be set to true.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 15, 2020

Author Member

Haven't we already added the disable_overprovisioning field to xDS? Wouldn't the capability basically replace that field?

I'm open to doing this via a capability, as long as we can figure out the right transition plan. The reason for the FIXME comment here is that we've been trying to reach consensus on this with @vishalpowar and his team, so we should discuss this further.

#### xds Resolver

Clients will enable use of xDS by using the "xds" resolver in the
target URI used to create the gRPC channel. For example, a user may

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 16, 2020

I have a question, why not use target ui to represent edsServiceName directly, and use edsServiceName to get ClusterLoadAssignment directly, but go through Listener and Cluster?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 16, 2020

Author Member

That probably would have worked for just the specific set of functionality that we're going to provide in the initial release, but we are definitely going to need the full xDS API flow later when we add support for things like routing and configurable LB policies, and we wanted the right structure in place from the get-go so that users don't have to change things on their clients or their management servers later as we add more features.

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 17, 2020

thanks, this is a good answer for me.

using the [LRS
protocol](https://github.com/envoyproxy/data-plane-api/blob/master/envoy/service/load_stats/v2/lrs.proto).
Note that the EDS policy will not support per-endpoint stats; it will
report only per-locality stats. Currently, the EDS policy will report

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 17, 2020

Do you mean that only the client-side stats are reported? These metrics do not seem to be useful for load balancing.

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 17, 2020

Author Member

I'm not sure which sentence you're asking about here.

The first sentence means that we will report only aggregate stats for the localities as a whole. In particular, we will not support the report_endpoint_granularity field in the LRS response, nor will we populate the upstream_endpoint_stats field in the LRS load report.

The second sentence means is that we won't populate the load_metric_stats field in the LRS load reports, which is intended to contain data reported to the client by the backend. The other fields, including number of requests sent/in flight/succeeded/failed, are all data that client already knows.

The data that we will report is sufficient for basic locality-level load balancing. There are certainly more advanced scenarios that will need more functionality, but we'll add support for those later.

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 19, 2020

ok, I have got it. Thanks.

Note that the EDS policy will not support per-endpoint stats; it will
report only per-locality stats. Currently, the EDS policy will report
only client-side stats; in the future, we will support also reporting
backend server stats reported to the client via

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 17, 2020

Will the backend server stats be passed to the client use in-band way here?

This comment has been minimized.

Copy link
@markdroth

markdroth Jan 17, 2020

Author Member

We will eventually support sending backend stats to the client both on a per-RPC basis and via an out-of-band stream. The per-RPC mechanism, which involves the backend load data being sent in each RPC's trailing metadata, will probably happen first. However, the OOB mechanism is useful for cases where the RPCs are long-running streams, where we need the data to be reported more frequently than RPCs are completing.

In any case, the details for backend load reporting will be covered in another gRFC when we get to the point where we're ready to implement this.

This comment has been minimized.

Copy link
@CodingSinger

CodingSinger Jan 19, 2020

Thanks, your answer helped me a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.