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

Spencer Dawkins at IETF <> Tue, 18 February 2020 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A776120811 for <>; Tue, 18 Feb 2020 14:47:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UGoHJFN0Pjf2 for <>; Tue, 18 Feb 2020 14:47:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61A1C120145 for <>; Tue, 18 Feb 2020 14:47:41 -0800 (PST)
Received: by with SMTP id e18so24826026ljn.12 for <>; Tue, 18 Feb 2020 14:47:41 -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=HSYo/X0vcklSQ3QLdAd3BPwlQ8tkCLol/X1qysjRh5Q=; b=tcD4RX664i0HddX11XEQOQj8xLeaJ5M5iTnrY+x5cQpibKW1NWduZ0zKVHZSabIyAw Sy+0vqZv/BBMMaD1/zsI5NmiRJYEUfKOTtFy5gY1tyicopPflAfTlXoshzgbY8FUH82w gmzlJYdJRBx6XjugtE7P+3uVARYuo9Rxjm7J5Rcz7J1qD2/H48zXhJyNPXJH/dIHpmKb L7t9NzJbyj3b6005vCj2Kg1z/8UATkTZKXqEXYbxCj1AbdvbvDuF204zwRhMIEpoW799 l+HWFBj10IwZxr/Z0rFP1j0vPH3oJK6NW8vrKAuRE/jYEso/peR6S4VtM/Zmpckb3bfP koBQ==
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=HSYo/X0vcklSQ3QLdAd3BPwlQ8tkCLol/X1qysjRh5Q=; b=tIME7oi0lua3mgkFCegrHDj05my4sIS26edhdfC3Bpn7VglakHXHoX4lj24XlFfmEk NmE4oN0ptNe0TI4pgld20pEjyGBLhECHnZcfl2u59mGnEse97B4UK6Cl+4KvqBOJmoDW HgfLeyFmv5SwunR/kUVaIuzLjL2gi6nmg4JRiSKcr2jjHrvKc7auCA7q1h+X2Ty0RQ/6 07S/FhNP4Wg4ZsENwe430hVpiXoGiO9neT5+wM9P/M9lZLG8SwEtPbxBEmxs+T7aaIzV klbzd3/OEkpUFt9fBf4EnAu3rLYsNjo+VOptr3djkFHSb0xx46ZYljaU1M2mWyEclYLK /JlA==
X-Gm-Message-State: APjAAAX89sciMTaToBUVauim//7Qx96ETEZt3U5P5lU/UgZmGzFNZyWO dMhMLz5Y6NLxksZWEVcPqdirkj/FL1kQj6aqGx0=
X-Google-Smtp-Source: APXvYqwJXSaDaTuKbFVipblMv5ACNn4L4qr317Tocf/2r8xI7BUX8qQeWIH8NKjW3ZrAjjIylP9o63WzuNkfUmsU1sU=
X-Received: by 2002:a2e:9d3:: with SMTP id 202mr14370475ljj.60.1582066059573; Tue, 18 Feb 2020 14:47:39 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 18 Feb 2020 16:47:12 -0600
Message-ID: <>
To: Ross Finlayson <>
Cc: Jonathan Rosenberg <>, "" <>, "Cullen Jennings (fluffy)" <>, Jonathan Rosenberg <>
Content-Type: multipart/alternative; boundary="0000000000007dfea0059ee17526"
Archived-At: <>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Feb 2020 22:47:44 -0000

I am also hoping for clarity here, or at least clue.

On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <>

> > On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <>
> 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 ...



> Ross Finlayson
> Live Networks, Inc.