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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Feb 2020 10:45:39 -0500

There is a new work effort underway to standardize an application protocol
on top of httpbis for real-time voice and video, basically replacing SIP,
RTP and SDP. This takes advantage of the usage of QUIC and UDP-based
transport, that makes httpbis more amenable to real-time. The current draft
also makes use of webtransport.

We've got a mailer set up:
https://www.ietf.org/mailman/listinfo/v3

And you can read the core draft here:
https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1

We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering a
working group.

It would be great to get participation and support from the experts in the
quic community.

Thx,
Jonathan R.

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Feb 2020 14:00:08 -0800

Jonathan,

Thanks for sending this.

While I think it's interesting to explore the question of how
to reinvent the real-time comms infrastructure using modern
Web-style technologies. I have a number of concerns with
the design and assumptions embodied in this draft.

WEB ARCHITECTURE
This document talks multiple times about how it's designed to work
with existing HTTP infrastructure and there are a number of features
of this design that seem to be dictated by that. However, it seems to
me that you are making a number of surprising (and perhaps incorrect)
assumptions about architecture and in general this seems misguided.

- Transport Connections and HTTP Requests Need Not Fate Share There
seems to be an implicit assumption in this design that HTTP LBs have
semi-persistent routing, such that if request 1 and request 2 go to
different servers this is a "migration" event (S 8.9). This may be the
case in some architectures but it's not by any means guaranteed. The
LB is free to send every request to a different server, and Web
applications need to be designed to accommodate this.
(see, for instance:
https://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.html
.
section The Runtime Environment).

While this might in principle be compatible with RIPT as designed, it seems
unlikely to work well if each byway goes to a different server.

- Use Datagrams, not Raw H3
Relatedly, trying to simulate an unreliable channel by round-robining
a reliable set of streams is clumsy at best. For instance, in cases
where you are transmitting too quickly, you now build up a backlog
of HTTP requests which must still be (re)transmitted even though they
out of date -- and they may even be transmitted before the timely
ones.

We already have a technology designed to provide unreliable messaging
for QUIC (https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/).
As far as I can tell, the only reason not to use it is that you
are trying to avoid making any new requirements on the server,
but I think that is a mistake because (1) as noted above, you
already are making non-standard assumptions and (2) the future
is bigger than the past, especially given the state of QUIC deployment.

- H3 Is Not Guaranteed
Conversely, you can't assume that H3 will be available. A significant
fraction of networks already do not pass QUIC, so if you want a
viable system it has to gracefully fall back to H2. I would deal with
this and the previous point by just pointing at WebTransport, which
already is expected to provide both unreliable service and fallback.

CALLING MODEL
Assuming I am understanding this draft correctly, it does not
meaingfully support incoming calls to end-user devices because you
have to run a server (which end-user devices will not and generally
cannot). I see you have some notion of having an extension for this,
but that should be provided from the first. This seems like an odd
omission to say the least.

LACK OF E2E SECURITY
Your charter specifies e2e security, but AFAICT, this is not
provided by this specification, nor is it obvious how to enhance
it to provide it. Indeed, it seems like there's not any support
for a disjoint media path. You may recall that I made similar
comments at the DISPATCH session in SIN, and I had understood
that it was your intention to accommodate these cases, but
I don't see anything here, which is somewhat disappointing.

I see that the charter says

"The protocol uses HTTP techniques for authentication and authorization
(notably OAuth), and requires hop by hop encryption (i.e., https). The
protocol will also allow for e2e media encryption, although keying is
out of scope, and is expected to be handled by other protocols such as
MLS."

I can't agree with this. If you're going to have STIR, then
you have what you need to provide for E2E media encryption,
and it's a regression from WebRTC not to provide it.

DETAILED COMMENTS
I also noted some more detailed issues, as noted below.

S 3.
   REQ4: The solution should hide the number of servers behind the load
   balancer, allow the addition or removal of servers from the cluster
   at will, and not expose any of this information to the peer

This seems like an odd requirement. I'm not sure how one would even
analyze this. What about timing side channels, host-ids in cookies, etc.?

S 6.
   To ensure authenticated caller ID everywhere, the TG specifies the
   set of allowed caller IDs through an [RFC8226] certificate.  This not
   only informs the client about what numbers it can originate with, it
   also proves to the client that it is capable of vouching for those
   numbers.

In what way does it prove to the client that it is capable of vouching?
Certificates are public information. Is this tied to the TLS connection
in some way?

S 8.4.
   The customer TG URI has to be reachable by the server in order for
   the it to receive calls, and for security purposes it must also
   support TLS and present a valid domain certificate using the same
   trust chains configured into browsers.

1. There is no real IETF normative definition for the trust anchors
for browsers. This is a local (And browser-specific matter)

2. It's worth noting that in this design it's not clear that you
would need to have a WebPKI valid ceritifcae.

S 8.5.
I'm really not a fan of the handler syntax, which seems not
very finished and kind of unspecified. For instance:

   "clientDirectives": "1 to 1: opus;
                                 2 to 2:
 H264,max-width=1280,max-height=720",

Why are you using JSON and then requiring me to parse a string?

S 9.7.
Why are you inventing your own cert enrollment protocol as opposed
to using ACME? Now we have to analyze this protocol too.

On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg <[email-masked]>
wrote:

> We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering
> a working group.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Feb 2020 09:47:49 -0600

Hi, Eric,

I'm not Jonathan, or any of the proponents, but ...

On Sat, Feb 22, 2020 at 4:00 PM Eric Rescorla <[email-masked]> wrote:

> applications need to be designed to accommodate this..
> (see, for instance:

I asked about this, too, in a different thread. The two things that came up
were

   - They really do want to fate-share everything over HTTP (although
   you've added concerns about why that might not be a good thing), and
   - QUIC's recharter to include datagram support was only approved last
   Thursday, so there was a race condition between QUIC being chartered to do
   datagrams and other proposed charters that might make use of QUIC datagrams.

I am hoping for continued discussion about the media story on list before
the BOF, because I'd expect having this discussion during the BOF would be
"more robust than we would hope". :-)

Best,

Spencer

>> There is a new work effort underway to standardize an application
>> protocol on top of httpbis for real-time voice and video, basically
>> replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and
>> UDP-based transport, that makes httpbis more amenable to real-time. The
>> current draft also makes use of webtransport.
>>
>> It would be great to get participation and support from the experts in
>> the quic community.
>>
>> Thx,
>> Jonathan R.
>>
>> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Feb 2020 12:33:25 -0500

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.