Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

[Jonathan Rosenberg <[e-mail]>]

Hi Spencer:

As you and Ross have inquired about – a KEY goal for this specification to enable client-to-server real-time media applications in modern cloud platforms. Examples would include audio bridges, contact centers, IP PBXs which handle media (many do), softswitches, cloud sbcs, and so on. All of these handle both signaling and media. This goal does in fact couple the media to signaling in some new ways, which introduce new requirements that a fully clean separation of signaling and media cannot easily address.  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.

All of the above requirements largely point to the need for a new encapsulation technique for the content of RTP packets, which enables them to be transported over HTTP in a way that is quite coupled with the signaling.

Ross had asked (or was it Spencer 😉) about whether the goal was to transmit the media over TCP. Our objective is that the media ultimately end up in a UDP packet in such a way that we avoid HOL blocking and enable the system to function with packet loss causing dropped packets. That can be accomplished in HTTP3 by using a new HTTP transaction for each packet, which maps to a new QUIC stream, which can be opened with zeroRTT, and if you end the transaction and don’t use it again, you end up getting media in a single UDP packet. This however is but one technique. Assuming webtransport gets standardized and widely deployed and runs within http, this would be another. We can also round-robin across transactions (this is what I had in earlier drafts). These are different solutions which the group needs to choose from. But the core requirement is to ultimately get low-latency media.

This also comes with an underlying assumption that the HTTP load balancers, networks, service meshes, serverless compute engines, and so on – which are used for HTTP – achieve low latency in general (network transport aside) – sufficiently low for voip. There is evidence to suggest that this is the case, as more and more ‘non-real-time’ apps on the web are getting pretty darn fast. Financial transaction processing is one such example. In fact, initial experiments were run to push media over plain old HTTP 1.1 in these platforms, which uses TCP, and it was pretty darn good!

HTH –
Jonathan R.



From: Spencer Dawkins at IETF <[e-mail]>
Sent: Wednesday, February 19, 2020 7:41 AM
To: Justin Uberti <[e-mail]>
Cc: Ross Finlayson <[e-mail]>; Cullen Jennings (fluffy) <[e-mail]>; Jonathan Rosenberg <[e-mail]>; Jonathan Rosenberg <[e-mail]>; [e-mail]
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Hi, Justin,

On Tue, Feb 18, 2020 at 10:01 PM Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:


On Tue, Feb 18, 2020 at 2:47 PM Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:
I am also hoping for clarity here, or at least clue.

On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <[e-mail]<mailto:[e-mail]>> wrote:

> On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <[e-mail]<mailto:[e-mail]>> wrote:
>
> Also to be clear - whilst I agree that RTP on QUIC is interesting - it is not in scope because httpbis is our target, not quic. We want to allow voice signaling and media to run over web infrastructure services, so http is our 'waist of the hourglass' not quic.

So just to clarify here:  Is your goal (for this protocol) that media be transferred only over streams (TCP or (reliable) QUIC), not datagrams?  Consequently, how important is end-to-end latency for audio/video calls that would use this protocol?

And are peer-to-peer audio/video calls (that would not involve a web server at all, except perhaps for initial end-user lookup/discovery) out of scope for this protocol?

If that's the case, then you’re not really ‘replacing’ RTP, but rather defining a new media transport protocol to be used in this one (restricted, but important) environment: Transport using reliable protocols via web server(s).  And if that’s the case, then I’m concerned that your SIP replacement (i.e., replacement of the one thing that’s truly broken, and needs replacing) might end up being too restrictive for more general media transport (datagrams and/or peer-to-peer).

I think I arrived at the same place as Ross, coming from the opposite direction. ("Thunk!")

ISTM that the proposal floating through here for a new media transport protocol, if it is successful, would be useful for non-RIPT applications as well, and ISTM that other proposals for RTP over QUIC (or whatever we're all muttering about privately), if one of them is successful, might be useful for RIPT applications as well.

So, the first suggestion I'd make at the BOF, if work on media transport of whatever flavor is still part of the proposed RIPT charter, is to split it off into a separate proposal, which I'd love to see go forward on its own, unless there are really strong reasons why RIPT signaling specification work and RIPT media transport work need to be coupled, need to fate-share, and need to compete for attention in the same working group.

I can say more about that at a mike in Vancouver, but let me start with this, on a mailing list ...

Spencer -

This time, I AM Spencer :-)

I agree that the signaling and media transport aspects are separable, but ultimately many applications will deploy them together, and perhaps multiplex them over the same HTTP transport. As such, there's definitely value in having a WG that considers the overall problem space and the various interactions between the layers (I think there are actually 3 layers - signaling, session descriptions, and media transport).

"Consider" is the key word, and I think that's an invitation to good systems engineering. No objection to that.

My suggestion is that the BOF proponents be really clear about what they expect to happen after the considering, and especially asking whether work on media relies on the same expertise as signaling, and (speaking as past AD for QUIC) whether you really need everyone in the same room at the same time, with no opportunity for parallel processing of separable topics.

At a minimum, I'd suggest adding AVTCORE, MMUSIC, and ICE to the list of working groups to coordinate with.

But do the right thing, of course :-)

Best,

Spencer

Certainly worth discussing further though.


Best,

Spencer

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
--
V3 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v3

________________________________

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.