Subject: [V3] ekr's comment #1: load balancing

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Mar 2020 22:36:29 +0000

I figured for ease of following I'd take ekr's review and split it up into a few separate mails.
https://mailarchive.ietf.org/arch/msg/v3/V2BuGEZJpEMcAKcYLNHDMtV3i70/

ekr says:
-----------
> WEB ARCHITECTURE
This document talks multiple times about how it's designed to work
with existing HTTP infrastructure and there are a number of features
of this design that seem to be dictated by that. However, it seems to
me that you are making a number of surprising (and perhaps incorrect)
assumptions about architecture and in general this seems misguided.

- Transport Connections and HTTP Requests Need Not Fate Share There
seems to be an implicit assumption in this design that HTTP LBs have
semi-persistent routing, such that if request 1 and request 2 go to
different servers this is a "migration" event (S 8.9). This may be the
case in some architectures but it's not by any means guaranteed. The
LB is free to send every request to a different server, and Web
applications need to be designed to accommodate this.
(see, for instance:
https://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.html
.
section The Runtime Environment).

While this might in principle be compatible with RIPT as designed, it seems
unlikely to work well if each byway goes to a different server.
------

My assumption is that cloud load balancers can be configured to perform sticky routing, *not* that all load balancers will do it by default. In other words, the assumption is that the ript server is being deployed into a cloud environment which is under the control (via configuration) of the company that is deploying the server, and therefore its settings can be tuned to make ript work properly. Sticky routing is broadly supported. It is supported by AWS (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html#enable-sticky-sessions-application), Google (https://cloud.google.com/load-balancing/docs/backend-service#session_affinity) , Azure (https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-distribution-mode) . I suspect the others do too but I didn't check. Many web apps that were built on-prem and were stateful, but are now being run in cloud compute environments, have an identical need so I don't expect this feature to be removed.

You are correct that ript wont work well if each byway aka media packet goes to a different server. Though, this may depend on the application. For apps that don't really process the media in a highly stateful way, it might actually work fine. For stateful operations like transcoding it would obviously be bad, yes.

That said, I think what is needed here is a better statement on the constraints. Instead of making things a hard rule like, "must work with existing cloud services without change", I think a better statement is perhaps something like, "aligns with web design principals, protocols, and features of cloud services in such a way that it minimizes the set of features which are unique to real-time".  Would that work better?

Thx,
Jonathan R.

--
Jonathan Rosenberg
CTO and Head of AI, Five9

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.