Re: New mailer and IETF107 BoF on RIPT - voice over httpbis/quic

[Phillip Hallam-Baker <[e-mail]>]

Stepping back a bit, I think one of the reasons for the focus on HTTP is to
be found in the current state of Voice/Video codecs on at the platform
level.

Apple, Microsoft and Google have different models which makes supporting a
voice or video app on multiple platforms 'challenging' to say the least.
And so if you search for information on how to code such an app, you get
back a dozen hits for middleware libraries that promise to provide
multi-platform support.

The cause of the Iowa caucus meltdown in the US was an app provider used
one of the middleware layers to build the app. The free level proved
sufficient for testing but couldn't support demand on the day.

IETF doesn't do APIs of course. Only that is exactly what a Web service
interface is just passing parameters over wires instead of via the stack.

If there is successful IETF activity in this space supported by the major
platform providers, there will be a dialectic interaction with the platform
APIs resulting in the emergence of a common intersection.

The difference between the Web Service approach and QUIC datagram approach
is the first is a reliable transport, the second is not. And that is very
important when the data in a packet is time sensitive. No point in
resending a lost audio packet after the listener has heard that bit. If we
know the transport is lossy, we may design our compression system
differently.

So while I see great value in pursuing both approaches, it is clear that we
want to do the lossy datagram model in the near future and that it is the
harder case. Given that the real payoff here is the constraints on the
APIs, I think we need to make the QUIC approach the lead.

The problem here is that we are talking about 'protocol' but our
negotiations are actually causing a chain of interactions with the CODEC
and API people at the end of them. I think we owe it to the people at the
other end of that communication to tell them the full set of what we want
up front rather than in two separate stages.

>