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

dualstack user guide #1357

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions content/en/docs/guides/dualstack.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
title: "Dualstack Backends"
description: >-
Explains the dualstack backend feature in gRPC.
---

### Overview

In cases where an endpoint (i.e., a gRPC server) has both an IPv4 and
IPv6 address, it is useful for clients to know both of those addresses,
so that they can reach the endpoint on either of them. Because only
one of the two protocols may actually be routable between a given
client and endpoint, clients need to try both addresses to see which
one will work. To minimize connection attempt latency, it is also
desirable for clients to attempt to connect to multiple addresses in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"it is also desirable" doesn't say what is actually done or who is responsible for it. "To minimize connection attempt latency, gRPC clients will attempt..."?

parallel, which is done using the "Happy Eyeballs" algorithm described in
[RFC-8305](https://www.rfc-editor.org/rfc/rfc8305).

In gRPC, it is particularly important for the [Load Balancing
Policy](https://grpc.io/docs/guides/custom-load-balancing) to understand
which addresses are associated with the same endpoint as opposed to
being different endpoints, so that the client does not send twice as
much load to a endpoint with two addresses. To that end, the [Name
Resolver](https://grpc.io/docs/guides/custom-name-resolution) can return
multiple addresses per endpoint (where an endpoint is a single endpoint),
and that information is communicated to the Load Balancing Policy.

Note that the only name resolver implementation that gRPC provides is a
DNS resolver, which does not support dualstack backends. This is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't be clear to users what "does not support" means here. You can use dualstack backends with pick_first. Maybe the earlier paragraph about load balancing policies needs to call out that nothing special needs to happen for the default policy, pick_first. But if using a different policy it probably needs NR support? And then you can use round_robin as an example when explaining the twice-the-load problem.

because DNS inherently returns a flat list of addresses, with no way to
indicate whether or not multiple addresses actually point to the same
endpoint.

There are two ways to use dualstack endpoints in gRPC:

1. Write your own custom name resolver that returns multiple
addresses per endpoint. For more information, see [Custom Name
Resolution](https://grpc.io/docs/guides/custom-name-resolution).
2. Use an xDS control plane that can communicate multiple addresses
per endpoint to the client. For more information, consult the
documentation for your xDS control plane.
Comment on lines +39 to +41
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to say this should link to some grpc xds documentation for how to set up your client to talk to your control plane, but...I can't find anything appropriately user-facing. Should we link to https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md for now?

Should we create another guide that covers how to set up a bootstrap file and create an xds-enabled grpc client (and server, possibly separately)?


For more information on gRPC dualstack backend support, see [gRFC
A61](https://github.com/grpc/proposal/blob/master/A61-IPv4-IPv6-dualstack-backends.md).

### Custom Resolver Dualstack Examples

| Language | Example | Notes |
|----------|------------------|----------------------------------------|
| C++ | | C++ resolver API not yet public. |
| Go | | Go dualstack support not yet complete. |
| Java | [Java example] | |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe indicate that both Java and Go have only experimental support for custom LB policies?

| Python | | Python resolver API not yet available. |

[Java example]: https://github.com/grpc/grpc-java/tree/master/examples/example-dualstack