Re: [V3] LB / Failure Detection

I think we are considering different use cases/deployment models.

I am not sure whether all cases require that SIP+RTP is handled by the same instance. Actually, I would argue that there are situations where this is only not needed but not desired. Separating signaling and media handling to different micorservices allows independent horizontal scaling, resiliency and utilizing nodes with special capabilities, e.g. GPU/SR-IOV etc…, only for media, i.e. when needed.

With L4 LBs, decryption is not an issue either as the IP/transport headers are not encrypted with SRTP. It works, the only issue is LB failure detection times of backends.

And even just for LB for HTTP based signaling, I don’t think generic HTTP LBs would cater the needs of emergency calls etc…

The current v3 direction seems to be targeting a particular use case. If so, it would be good to specify this clearly so that we know where would like to go.

On another note, RTP(+-)/QUIC seems like a better alternative to me compared to RTP(+-)/HTTP/QUIC as it would broaden the use cases where it can be utilized.

Thanks,
Tolga

From: Jonathan Rosenberg <jdrosen@jdrosen.net>
Sent: Saturday, April 11, 2020 8:52 AM
To: Asveren, Tolga <tasveren@rbbn.com>
Cc: v3@ietf.org
Subject: Re: [V3] LB / Failure Detection

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

You can distribute RTP, but its the SIP+RTP that is really painful in combo.

If the goal is for SIP+RTP to land on the same instance, what you want is initial load balancing across the cluster for the SIP message. Once this lands on a specific node in the cluster, you want subsequent SIP, and all of the media, to land on that node. Because the RTP has a totally different 5-tuple than then SIP, the L4 LB will not send it to the same instance.

We also would like decryption to happen at the edge for the outer transport; obviously this doesnt happen with L4 load balancers, and that is a feature we want.

We also want more advanced load balancing features that see into the application layer - URL maps in the http world. We cannot do that with L4 load balancers.

Thx,
Jonathan R.

On Mon, Mar 30, 2020 at 7:20 PM Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> wrote:
A basic question about how RIPT would make things better compared to RTP in terms of making use of Public Cloud Load-balancers:

With RTP: One can use L4 LB distributing traffic to a Redundancy Group. The pain point is that LB is slow in detecting failures of Redundancy Group members.
With RIPT media: One can use HTTP LB distributing traffic a Redundancy Group. I would think failure detection characteristics will be similar to L4 LB and delayed failure detection issue would continue to be an issue.

In a nutshell, what would one gain by using a HTTP LB instead of L4 LB?

Thanks,
Tolga

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________
--
V3 mailing list
V3@ietf.org<mailto:V3@ietf.org>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>

--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>
http://www.jdrosen.net<http://www.jdrosen.net>