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

Spencer Dawkins at IETF <> Wed, 19 February 2020 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B23E612003F for <>; Wed, 19 Feb 2020 04:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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] 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 U0L0FFjkP3sx for <>; Wed, 19 Feb 2020 04:41:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E82D120019 for <>; Wed, 19 Feb 2020 04:41:14 -0800 (PST)
Received: by with SMTP id z5so2264944lfd.12 for <>; Wed, 19 Feb 2020 04:41:14 -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=Po0YWjEjaoMa6fqsLcanq0Isr28A/8myjcDbR/9ek74=; b=ScIY1HIJuAUJ1rNcr/RUm//fzSBTIbVpqHt4LUhFc0gAh/gyTvfPbXY9BmTNSxnjRd EOaVbkXooA2tvSJzVfgYlLuMdGBCKvq2vIvT6+t+SKLEvfwMXn3tRS3/j7bq9ffcam9k mcB4H1+hZkrOY23LgGA5PLQN4YV2JsM72GUBQBqXizzfro3MggXLM7Ntqny2HJhw9C9r Vp2sQPYH+nwyHfsaKfN+kiNphW9D2kmep0RwAGaEsZbB4z9gVKUY5M6DKT2GiFsKBLwH uZ4RSupPvKOVnIieaoD6CI/c9bEDQE7RV2h+4X3caTfU1frVq2i202xPeDGx93lCCVF9 mEYA==
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=Po0YWjEjaoMa6fqsLcanq0Isr28A/8myjcDbR/9ek74=; b=JGDHcER8iuP2oVB0pWmp+47nIhrVOS7ZCkxm1LCBdONSBfL8BX8cjL0oDSqH/PsOuO 2hewveiGfoYkLZLZ8lU1GeYXDTngDl8K2W6KnuAjrxMCGgMKVxiiGOfcRWuYmtDqDrfS SIfAmMXBL/RojxVCOGww2OdRMReTuztHZ6yxQ9mIxCndBza28Zv2kPGnw+TfB9Eafeev +Gqbwwq+YemD3GOsv5Zeo6xCzT8BdGqQ9gnZkGEigC2NrDKGdEmas9b+u9Re5/+QRodj CN+ZV2w1AMJHEpELnANv2pK7hWwZb61bfbITdqsmQxQ0A2G6pJMSWZB7pmhZmw8Goflu mthw==
X-Gm-Message-State: APjAAAUMbKTGKpzapVe61ooI9zBoqCt6pgYjQqzO/sVBevSN2hlswFnK TpCaaNeuNsla39g3KbjU6GG3hLmLYf3Z00mevNc=
X-Google-Smtp-Source: APXvYqw8nXphVp0Hf//4QkGhsegEW6WKvmpq1wTNANxat4+oTj63N0DxSLXqM0QW203V0s73b/uiiclgz5rU+H06U7M=
X-Received: by 2002:a19:c82:: with SMTP id 124mr13197549lfm.152.1582116072725; Wed, 19 Feb 2020 04:41:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Wed, 19 Feb 2020 06:40:45 -0600
Message-ID: <>
To: Justin Uberti <>
Cc: Ross Finlayson <>, "Cullen Jennings (fluffy)" <>, Jonathan Rosenberg <>, Jonathan Rosenberg <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008220d3059eed1a68"
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: Wed, 19 Feb 2020 12:41:18 -0000

Hi, Justin,

On Tue, Feb 18, 2020 at 10:01 PM Justin Uberti <> wrote:

> On Tue, Feb 18, 2020 at 2:47 PM Spencer Dawkins at IETF <
>> wrote:
>> I am also hoping for clarity here, or at least clue.
>> On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <>
>> wrote:
>>> > 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 ...
> 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 :-)



> Certainly worth discussing further though.
>> Best,
>> Spencer
>>> Ross Finlayson
>>> Live Networks, Inc.
>>> --
>> V3 mailing list