Subject: Re: [V3] LB / Failure Detection

From: Justin Uberti <[email-masked]>
Date: Wed, 1 Apr 2020 09:25:59 -0700

Specifically, HTTP LBs can use the fields from the HTTP header to do
routing and load-balancing, e.g., the request path, API key, client
cookies, auth header, etc, rather than just the 5-tuple used by L4 LBs.

On Tue, Mar 31, 2020 at 10:35 PM Mo Zanaty (mzanaty) <mzanaty=
[email-masked]> wrote:

> > In a nutshell, what would one gain by using a HTTP LB instead of L4 LB?
>
> There are many reasons why HTTP apps use HTTP LB instead of (or in
> addition to) L4 LB, such as flexibility, programmability, feature rich
> ecosystem, etc. The HTTP list may be a better place for such a question and
> discussion though, since this is not specific to RIPT, but applies to all
> HTTP apps.
>
> Thanks,
> Mo
>
> On 3/30/20, 7:19 PM, "V3 on behalf of Asveren, Tolga" <[email-masked]
> on behalf of [email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v3
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 1 Apr 2020 12:44:26 -0400

I agree with that part but as said for me the real pain point is failover detection. We still would continue to suffer on that front -and it indeed creates “inconveniences” for media-.

Thanks,
Tolga

From: Justin Uberti <[email-masked]>
Sent: Wednesday, April 1, 2020 12:26 PM
To: Mo Zanaty (mzanaty) <mzanaty=[email-masked]>
Cc: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: [V3] LB / Failure Detection

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

Specifically, HTTP LBs can use the fields from the HTTP header to do routing and load-balancing, e.g., the request path, API key, client cookies, auth header, etc, rather than just the 5-tuple used by L4 LBs.

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

There are many reasons why HTTP apps use HTTP LB instead of (or in addition to) L4 LB, such as flexibility, programmability, feature rich ecosystem, etc. The HTTP list may be a better place for such a question and discussion though, since this is not specific to RIPT, but applies to all HTTP apps.

Thanks,
Mo

On 3/30/20, 7:19 PM, "V3 on behalf of Asveren, Tolga" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>