Re: [V3] RIPT BoF approved for IETF 107

Trying to dive deeper so that the goals/scope/expectations could be defined in a more detailed way:

i- IMHO “being just another app” is a bit problematic, at least not for some real-time session applications

 *   I think it is not realistic to expect that majority of real-time session applications won’t have any notion of “special handling for emergency calls”
 *   Semantics for how 503 responses from back-ends need to be interpreted/dealt with also wouldn’t match well with the “standard HTTP LB” functionality
 *   We obviously can restrict the scope so that “such cases” are out of scope but let’s be aware that those are a non-negligible amount of overall real-time session universe
ii- Back-end failover

 *   Yet another area where Cloud LBs (whether HTTP or L4) fall short
 *   Yes, there are heartbeats between backend and LB but the failure detection time is usually nowhere near being satisfactory for media
 *   What could be useful
    *   Media is negotiated with a backup address
       *   This would be a different URI for HTTP based media
       *   And this should result that a different backend receives the packets
    *   Sender switches to backup address when inactivity is detected
    *   The same could be done with SIP/SDP as well, e.g. maybe by utilizing RFC5888 FID
       *   But FID/semantics of using it in this fashion are not widely supported
    *   v3 being “new”, the rules would be defined from scratch so this can be the standard behavior

Thanks,
Tolga

From: Jonathan Rosenberg <jdrosen@five9.com>
Sent: Wednesday, February 19, 2020 8:20 PM
To: Asveren, Tolga <tasveren@rbbn.com>; Ross Finlayson <finlayson@live555.com>
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com>; Jonathan Rosenberg <jdrosen@jdrosen.net>; v3@ietf.org; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Justin Uberti <juberti@google.com>
Subject: RE: [V3] RIPT BoF approved for IETF 107 - Draft charter below

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

Now we’re getting to some meat! Tolga said:

> I doubt standard HTTP  load balancers can be used as is even if all real time session messaging (signaling, media, …) is HTTP based. Required semantics, e.g. different treatment based on RPH, overload control etc…,  are simply different than what is needed/used/sufficient for standard Web applications. On another note, a core issue for Cloud load balancing is failure detection/failover time for back ends servers. This again is an area where “just using HTTP” wouldn’t help.

So – a key goal here is to move away from voip being ‘special’ to being ‘just another app’. You’re correct that Resource Priority isn’t something existing LB’s deal with, but the idea of prioritizing different requests when a load balancer is overloaded, is not a problem unique to voip. I also don’t think that the applications which typically worry about RPH are initial targets for this protocol.

For overload control – well there I disagree. In this protocol, the HTTP LB holds no call state so normal HTTP overload handling I think will work fine.

Similarly – failure detection is often done today via REST endpoints which are implemented in the origin servers which the LB pings. That will work just fine in this case, Ive personaly implemented stuff that works this way.

That said – you are correct that the charter needs to be clearer on this underlying assumption.

From: Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>
Sent: Wednesday, February 19, 2020 7:37 PM
To: Ross Finlayson <finlayson@live555.com<mailto:finlayson@live555.com>>; Jonathan Rosenberg <jdrosen@five9.com<mailto:jdrosen@five9.com>>
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>>; Jonathan Rosenberg <jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>>; v3@ietf.org<mailto:v3@ietf.org>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>; Justin Uberti <juberti@google.com<mailto:juberti@google.com>>
Subject: RE: [V3] RIPT BoF approved for IETF 107 - Draft charter below

“Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice.”

I would like to point out that this is an important assumption and does not entirely overlap with reality. Application specific and L4 load balancers are used widely in Cloud deployments for real-time sessions. I doubt standard HTTP  load balancers can be used as is even if all real time session messaging (signaling, media, …) is HTTP based. Required semantics, e.g. different treatment based on RPH, overload control etc…,  are simply different than what is needed/used/sufficient for standard Web applications.

On another note, a core issue for Cloud load balancing is failure detection/failover time for back ends servers. This again is an area where “just using HTTP” wouldn’t help.

Having “HTTP only” as a core principle is fine but I think the rationale for that should be articulated more in detail and clarity.

Thanks,
Tolga

From: V3 <v3-bounces@ietf.org<mailto:v3-bounces@ietf.org>> On Behalf Of Ross Finlayson
Sent: Wednesday, February 19, 2020 9:52 AM
To: Jonathan Rosenberg <jdrosen@five9.com<mailto:jdrosen@five9.com>>
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>>; Jonathan Rosenberg <jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>>; v3@ietf.org<mailto:v3@ietf.org>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>; Justin Uberti <juberti@google.com<mailto:juberti@google.com>>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

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

> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <jdrosen@five9.com<mailto:jdrosen@five9.com>> wrote:
>
> Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice. That means that clients have to send media through HTTP. Secondly, we assume that sticky routing happens in these load balancers the ‘normal’ way – through a combo of hashing of 5-tuples and usage of session cookies. That means that, in order to get the media to the server handling the signaling (which is what we want), the media needs to come in the same connection, and use cookies. This further ties it to HTTP. In order to deal with failures of those servers and enable mid-call recovery without loss of media packets, we also need the transport to contain call identifiers. This way, media can just ‘be sent’ to a new server in the pool behind the load balancer, and it can pick up where things left off in the previous server without losing any media packets (like - not one). In RIPT this happens because all media are PUT/GET from the call URI.

OK, thanks - this explanation makes it very clear that what you’re planning is a protocol for audio/video calls *over HTTP* - and over HTTP only. A lot of the confusion (largely on my part, I admit) about what you’re proposing would have been avoided if this had been clearer in the name of the protocol (and BOF) - i.e., if there had been an “H” in there (I would have preferred something like MoH: “Media over HTTP” :-)

And grandiose statements about this protocol "replacing SIP, RTP and SDP” don’t help either - unless you really see the “HTTP Internet” (hourglass) becoming the entire Internet. (Not all of us are ready to concede that, just yet ;-)

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/<http://www.live555.com/>

--
V3 mailing list
V3@ietf.org<mailto:V3@ietf.org>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>

________________________________
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.
________________________________

________________________________

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.