Add gRPC proto for rate-limit xDS Config communication

[renuka-fernando]

Related Issue

https://github.com/envoyproxy/ratelimit/issues/201

[mattklein123]

I think it would probably be better to put this in https://github.com/cncf/xds. cc @envoyproxy/api-shepherds any thoughts? This is a new xDS based API for serving rate limit configurations to a rate limit server. Possibly related to the parallel work the Google folks are doing on the new quota based rate limit API.

[mattklein123]

Instead of building this based on the old RLS protocol, It may make sense do it based on the new RLQS protocol introduced in https://github.com/envoyproxy/envoy/pull/19793. This is currently being implemented in Envoy by @tyxia (CC @yanavlasov @sergiitk). I think in the long run, we will want to move away from RLS and instead recommend using RLQS, which is much more scalable, so it may not make sense to invest more in RLS at this point.

Lots of people use the existing RLS and it works fine for many cases. I think it's fine to have work still done on that.

[renuka-fernando]

Hi @markdroth, @mattklein123,

Could you please guide me adding this on the cncf/xds repo? I would like to know the proper location that the proto files should be included and other changes that should be made.

I drafted a PR with removing the service RateLimitConfigDiscoveryService, which is included in this PR, since we are going to use ADS. Hence it is just the RLS config proto messages in the draft PR: https://github.com/cncf/xds/pull/51.

[mattklein123]

As we said above, I don't think we have to add anything to either cncf/xds or go-control-plane. You can use ADS and define the protos wherever you want, including here. I'm going to close this PR for now so feel free to open a new simpler one.

[renuka-fernando]

As we said above, I don't think we have to add anything to either cncf/xds or go-control-plane. You can use ADS and define the protos wherever you want, including here. I'm going to close this PR for now so feel free to open a new simpler one.

Hi @mattklein123, thank you for your quick response.

If we add RLS config type as a known type in go-control-plane as in the PR: https://github.com/envoyproxy/go-control-plane/pull/598, we can use the existing Snapshot in go-control-plane to easily implement a server.

import (
	"github.com/envoyproxy/go-control-plane/pkg/cache/types"
	"github.com/envoyproxy/go-control-plane/pkg/cache/v3"
	"github.com/envoyproxy/go-control-plane/pkg/resource/v3"
	"github.com/envoyproxy/go-control-plane/pkg/server/v3"
)
...
	snapshot, _ := cache.NewSnapshot("1",
		map[resource.Type][]types.Resource{
			resource.RateLimitConfigType: {
				&rls_config.RateLimitConfig{
					Domain: "foo",
					Descriptors: []*rls_config.RateLimitDescriptor{
						{
							Key:   "k1",
							Value: "v1",
							RateLimit: &rls_config.RateLimitPolicy{
								Unit:            "minute",
								RequestsPerUnit: 3,
							},
						},
					},
				},
			},
		},
	)

	if err := snapshot.Consistent(); err != nil {
		log.Printf("snapshot inconsistency: %+v\n%+v", snapshot, err)
	}

	snapCache = cache.NewSnapshotCache(false, cache.IDHash{}, nil)
	if err := snapCache.SetSnapshot(context.Background(), "test-node", snapshot); err != nil {
		log.Printf("snapshot error %q for %+v", err, snapshot)
	}

	grpcServer = grpc.NewServer(grpcOptions...)

	lis, err := net.Listen("tcp", fmt.Sprintf(":%d", port))
	if err != nil {
		log.Fatal(err)
	}

	discoverygrpc.RegisterAggregatedDiscoveryServiceServer(grpcServer, srv)
	if err = grpcServer.Serve(lis); err != nil {
		log.Println(err)
	}

Otherwise, we can implement our own Snapshot in the ratelimit repo and use the SnapshotCache in go-control-plane to implement an xDS server for ratelimit service.

I think adding known types is required even if we use ADS. Please correct me if I am wrong. Please share your thoughts on this.

cc @alecholmez