Re: [V3] LB / Failure Detection

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=
40cisco.com@dmarc.ietf.org> 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" <v3-bounces@ietf.org
> on behalf of 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
> https://www.ietf.org/mailman/listinfo/v3
>