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

Incremental XDS proposal. #3470

Merged
merged 11 commits into from
Jul 2, 2018
Merged
Show file tree
Hide file tree
Changes from 5 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
44 changes: 44 additions & 0 deletions api/XDS_PROTOCOL.md
Original file line number Diff line number Diff line change
Expand Up @@ -285,6 +285,50 @@ admin:

```

### Incremental xDS

Incremental xDS is separate xDS endpoint available for ADS that allows:

* Incremental updates of the list of tracked resources by the xDS client.
This supports Envoy on-demand / lazily requesting additional resources. For
example, this may occur when a request corresponding to an unknown cluster
arrives.
* The xDS server can incremetally update the resources on the client.
This support the goal of scalability of xDS resources. Rather than deliver
all 100k clusters when a single cluster is modified, the management server
only needs to deliver the single cluster that changed.

An xDS Incremental session is always in the context of a gRPC bidirectional
Copy link
Member

Choose a reason for hiding this comment

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

Nit: s/Incremental/incremental/ here, incremental is an adjective not a proper noun.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

stream. This allows the xDS server to keep track of the state of xDS clients
connected to it. There is no REST version of Incremental xDS.

In Incremental xDS the nonce field is required and used to pair
IncrementalDiscoveryResponse to a IncrementalDiscoveryRequest ACK or NACK.
Copy link
Member

Choose a reason for hiding this comment

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

Can you add docs links (as done with DiscoveryRequest/Response) above? Also, use quote style for proto message names as done for these messages above.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Optionaly, a response message level system_version_info is present for
Copy link
Member

Choose a reason for hiding this comment

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

Nit: s/Optionaly/Optionally/

debugging purposes only.

IncrementalDiscoveryRequest can be sent in 3 situations:
1. Initial message in a xDS bidirectional gRPC stream.
2. As a ACK or NACK response to a previous IncrementalDiscoveryResponse.
Copy link
Member

Choose a reason for hiding this comment

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

Nit: s/a ACK/an ACK/

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

In this case the response_nonce is set to the nonce value in the Response.
Copy link
Member

Choose a reason for hiding this comment

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

Nit: use quote style for response_nonce and error_detail here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

ACK or NACK is determined by the absence or presence of error_detail.
3. Spontaneous IncrementalDiscoveryRequest from the client.
This can be done to dynamically add or remove elements from the tracked
resource_names set. In this case response_nonce must be omitted.

In this first example the client connects as receive a first update that it ACKs.
Copy link
Member

Choose a reason for hiding this comment

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

s/as receive/and receives/

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

The second update fails and the client NACKs the update. Later the xDS client
spontaneously requests the "wc" resource.
Copy link
Member

Choose a reason for hiding this comment

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

I think the wc resource_list_subscribe arrow is the wrong way around in the diagram.


![Incremental session example](diagrams/incremental.svg)

On reconnect the xDS Incremental client may tell the server of its known resources
to avoid resending them over the network.

![Incremental reconnect example](diagrams/incremental-reconnect.svg)

The Incremental xDS method may be added to CDS and RDS in the future.

## REST-JSON polling subscriptions

Synchronous (long) polling via REST endpoints is also available for the xDS
Expand Down
1 change: 1 addition & 0 deletions api/diagrams/incremental-reconnect.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading