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

Spencer Dawkins at IETF <> Mon, 24 February 2020 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8B9B3A0D8B; Mon, 24 Feb 2020 07:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mFsNSin3-JZh; Mon, 24 Feb 2020 07:48:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15B8C3A0D96; Mon, 24 Feb 2020 07:48:18 -0800 (PST)
Received: by with SMTP id l16so7147078lfg.2; Mon, 24 Feb 2020 07:48:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=di1QdoOEPHH1TttieGv1BXsEX9etvWRnwd/+2kLvGySPQn3Z+osnaesUVESY0XT631 0WYYvChLX6BiHw8CT+4/DgxfYoeGIj2ipv5UtwQHpzO732WCk/Q1lkxJUHeHI8UAfW2Z 2pAv/F9Xq3TUUW+xF/TfjkksEnTYEc6aPlwD9UV3wGlDGMDkTfQIYBfHWzFDhMxC5g7M DlNX9+8dkwMvnarLY06jo0JZqPhkQdI+SZPH9qfN2FKuZZL6Vd7Z73OO0k6G4LJTHPUj x2ZDPxIY9Qi00soblWQAjYVJuWdGixWpnrU0gumhcAzSLHnsQuccANEZCv0ySnAF1pIV /dqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=tvEA2ozTdHcBY1FfwffjSgktxkmmb/T8GspDY2RnnrdwJSCZckiRpF0PVN746F8PK4 pMsKVthMiO2HNPqp+1ewUaz65Nzq1rlfDCRncqLdBROZLw4Nm/J5CjU6uF8VE4olLzYn UgbMVi9uRmFlWy5a/ereqwCHpsSpM/jbKoY3HI8JS2hVqfauBB2d8r7nU0Cnz64pOBXl N4YUS81hMo1vuGzTyDO3RKFFBfLf5fxNumgX67FqgnyusqY73P9m0OxNONzWEMJyUMQr UktiwgQUxS9e8RqLRYA0OfFuIttY813SwPyzeWW8ShjK4Nn7gE6BlNen4sIqWIxffUVX xU3A==
X-Gm-Message-State: APjAAAUGBdINvraYQyML1IQb1KfauO2so7+vk1sUa6j/T+eO/IdXbVht ZY8GGxowJyA7P80qOlbCUKREWQleeeLSQ3oAVh7keogUXz4=
X-Google-Smtp-Source: APXvYqx+yCAAoz0pD33gMsfuYz8NyzxCPMPKTwrXJbKCc3tDH2gGFfVKbuOMaNs+W1xoJ8a/ecgw3b2MYN1hlJci42Q=
X-Received: by 2002:a19:ca59:: with SMTP id h25mr27858599lfj.27.1582559296182; Mon, 24 Feb 2020 07:48:16 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Mon, 24 Feb 2020 09:47:49 -0600
Message-ID: <>
To: Eric Rescorla <>
Cc: Jonathan Rosenberg <>,, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000af5c52059f544c1f"
Archived-At: <>
Subject: Re: [V3] New mailer and IETF107 BoF on RIPT - voice over httpbis/quic
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2020 15:48:28 -0000

Hi, Eric,

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

On Sat, Feb 22, 2020 at 4:00 PM Eric Rescorla <> wrote:

> 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.
> 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:
> .
> 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 (
> 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.

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

   - 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". :-)



> - 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.
> 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.
> 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.
> 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 <>
> wrote:
>> 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:
>> And you can read the core draft here:
>> 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.