On Thu, Jan 19, 2017 at 3:06 PM, 'Julien Boeuf' via grpc.io < grpc-io@googlegroups.com> wrote:
> +stubblefield since he expressed interest. > > Thanks Mark for the reply. Please see inline. > > Cheers, > > Julien. > > On Thu, Jan 19, 2017 at 8:08 AM, Mark D. Roth <r...@google.com> wrote: > >> Julien, >> >> The gRFC process <https://github.com/grpc/proposal/blob/master/README.md> >> says that all discussion should happen in this thread, rather than in the >> PR. So I'll reply to your comments here. >> > Ack. Sorry about that. > > >> >> I agree with you that the proxy mapper could set the HTTP CONNECT >> argument to a server name instead of to an IP address. However, that would >> not be enough to address the case where the servers' DNS information is not >> available, at least not in the general case, because the client still needs >> to know the set of server addresses in order to open the right set of >> connections to load-balance across. >> >> As you and I have discussed, in the specific case where the grpclb load >> balancing policy is in use, then you could in principle make this work, >> because the set of server addresses will actually come from the load >> balancers instead of from the name resolver. However, this would require a >> number of additional hacks: >> >> - The name resolver would somehow have to know that when you request >> a load balanced name, it should return the address of the proxy but with >> the "is_balancer" bit set. >> >> Correct. This can be done using naming convention which is a reasonable > thing to do. > > >> >> - The proxy mapper would need some way to differentiate between the >> connections to the load balancers and the connections to the backend >> servers, so that it could set the HTTP CONNECT argument to the server name >> for the load balancer connections and to the IP address for the backend >> server connections. >> >> Yes, that is correct. A way to do that is to work hand in hand with the > resolver which would set a well known / invalid IP address in case of the > balancer connection (e.g. link local address) so that it can be processed > as a special case by the proxy mapper. It's not great but it would > certainly work. > > >> >> - The proxy itself would have to know how to resolve the internal >> name of the load balancers. >> >> Yes, this is totally reasonable and is one of the benefits of using HTTP > CONNECT. In fact, we are using that very feature for the http_proxy env var > case today. > > >> And even once all of those hacks are implemented, this approach still >> only works for the case where the grpclb load balancing policy is in use. >> If you want to use something like round_robin instead, it won't work at all. >> > IMO, it is OK. I don't believe that round robin is very useful if you have > grpclb at your disposal. If your client is not able to properly resolve > names, then round-robin is out of the equation to begin with. > > >> >> I continue to believe that running a gRPC-level proxy is a better >> solution for this use-case. >> > I agree that this could work. However, this is no silver bullet. Here are > some issues I have with this scheme. > 1. This requires the deployment of a full gRPC proxy in the path as > opposed to a more standard HTTP CONNECT proxy. > That's true, but I think that having this kind of proxy would be fairly useful in other scenarios as well. > 2. More importantly, it requires the termination of the secure session at > the proxy which means that the proxy has to be fully trusted. > Is this a significant problem, given that the proxy would be under the control of the same organization as the servers? > 3. Even if the proxy is fully trusted, you will need a way to: > - carry the whole authentication information of the client from the proxy > to the backend (e.g. attributes, restrictions etc...). > - depending on your transport security protocol, you may or may not have > access to something like Server Name Indication (SNI: > https://en.wikipedia.org/wiki/Server_Name_Indication) which would be > needed in this kind of deployment. > Won't having those capabilities be useful in other scenarios too? I certainly agree that there's some work that needs to be done for the gRPC-level proxy approach. However, it seems like that work would yield a set of tools that would be generally useful in other situations -- in effect, we'd be creating new building blocks that we could compose in different ways in the future to solve other problems. In contrast, the hacks described above that would be necessary to do the work on the gRPC client would only be useful in this particular scenario, and they would actually complicate the existing code instead of providing new building blocks that can be reused later. I think we are in agreement that either approach could be made to work. However, I think the gRPC-level proxy approach is cleaner and provides more long-term benefit. > > >> >> On Wed, Jan 18, 2017 at 2:18 PM, Julien Boeuf <jbo...@google.com> wrote: >> >>> Thanks I saw this. I'll comment on the doc. >>> >>> BTW, i'm at an offsite today (and I was yesterday) but this is really >>> high on my priority list. >>> >>> Cheers, >>> >>> Julien. >>> >>> On Wed, Jan 18, 2017 at 2:12 PM, Mark D. Roth <r...@google.com> wrote: >>> >>>> I've created a gRFC describing how HTTP CONNECT proxies will be >>>> supported in gRPC: >>>> >>>> https://github.com/grpc/proposal/pull/4 >>>> >>>> Please keep discussion in this thread. Thanks! >>>> >>>> -- >>>> Mark D. Roth <r...@google.com> >>>> Software Engineer >>>> Google, Inc. >>>> >>> >>> >> >> >> -- >> Mark D. Roth <r...@google.com> >> Software Engineer >> Google, Inc. >> > > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to grpc-io+unsubscr...@googlegroups.com. > To post to this group, send email to grpc-io@googlegroups.com. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/grpc-io/CAAvOVOd%3DXK0Mw1E9L0hnb7Tb5RaDESvVb% > 3D9S7GE99HfR4w1djg%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAAvOVOd%3DXK0Mw1E9L0hnb7Tb5RaDESvVb%3D9S7GE99HfR4w1djg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJgPXp5kLSpNgxx%2BpeSBQZR0fjWvBmFfh4Vre3GeEOM6uufnPA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
