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

Justin Uberti <juberti@google.com> Wed, 19 February 2020 19:33 UTC

Return-Path: <juberti@google.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9720E120103 for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 11:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XTUUY8zuy0f for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 11:33:00 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E2E120018 for <v3@ietf.org>; Wed, 19 Feb 2020 11:32:59 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id g13so655218uab.7 for <v3@ietf.org>; Wed, 19 Feb 2020 11:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pY1OGTjfXajxngGGiY+hTV5apN1jqTpPiE6Jl98kItc=; b=oeTL1fuzYG3kuNlaI2aGlM5uVC8SF9X7fLkZG9i9HB27ij4Da4P1lzFctfe7MWWBza PafTKZGw2uzmYg5k33bLUssBaFLJLxbM4rpnuLNFVsfESKAXyMM6lrsVm63QxL2P4SCv DNGaCrd2AU0NpkcHM+fCiVibxYqWkTabFfxlLMILStHwS0SnRenTmk4m2IDN8iepJFBz TMRrl9acnh+ZxXifwHDOgj4Cy4eSy2t1G80L/MEnJmU+xNr6sihEA18aVWfJ3k8rFmaG nNJth7wUemkXFRuKaZyu7DxaOBg6xgN79mcVaDiN91k8OF3NVAkP/enuo9cbj8yO//Hh /lEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pY1OGTjfXajxngGGiY+hTV5apN1jqTpPiE6Jl98kItc=; b=r6JIhuw6cgj7CiO2tnlfAVWzfP7GHTh8qztA34JLphjtLLNdtXBtwUX8b2vz+mNdIM OHiM3baWTL+bLJbHQYyxOptlvjBysq4HJm8ne3xOfNT2+czYRVZKIXNZ77FPSmkSd+bV M8FN3mZV8zYJ51ELZuizwVNcY/ty+HpWwOSfa4O+f6Oc8oZb/Pu6UEY18Xc3HujjV9uy XC/79LVp5t7rUP7Zv/Y7jMyj50rxmYpKk6HdCQWEaOvDtCIOjRrCsnS1FgjNITZZAC5e tSpW6eVoczljg5eeq+/yB+ByDwT+iiaiUoM22gWu7LCK7H0b+/Zolc87oBvnFBTgoC78 e5hA==
X-Gm-Message-State: APjAAAWggb1oJSNQ2b3tqMqou/fzFog+1pvyr8/MHg+hKo/1xgWD+jWm Y+xK+lLeNAoDrX+ZUyvoWzr3y//MIxEZiISJUF8tpw==
X-Google-Smtp-Source: APXvYqw8WlbMGy0NbELm1lF0k7ATDnKO3yRvgGDN5r3Q3CHwSnXE57gwbTzMTVR3Wba0FgZLM/w2caV4hfI/mEYEAK4=
X-Received: by 2002:ab0:2ea8:: with SMTP id y8mr13869039uay.23.1582140778511; Wed, 19 Feb 2020 11:32:58 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR06MB43914433BF91CE216E6123A6FB150@BYAPR06MB4391.namprd06.prod.outlook.com> <CAKKJt-eKB4wxqK8Xiho2tYaqpM3_fjQYsjJh5-cf_RWd6iR8sQ@mail.gmail.com> <CA+23+fGNO86ii6q0hd3aiSdib2AT-iu3O+DmgGJXTFbFkGxLnQ@mail.gmail.com> <F72DFB60-1BA3-4CD3-9DB2-DF986F3729DE@live555.com> <DF3A5713-AF43-4399-B464-76E48AABF6E7@cisco.com> <fa6980b4-f21a-95c9-9269-aea144da0ab3@in.tum.de>
In-Reply-To: <fa6980b4-f21a-95c9-9269-aea144da0ab3@in.tum.de>
From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Feb 2020 11:32:47 -0800
Message-ID: <CAOJ7v-1NK48+8bPB_63WxRA-oFeBv0Y=+t8hj-KZcFHU80GCTQ@mail.gmail.com>
To: Joerg Ott <ott@in.tum.de>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Ross Finlayson <finlayson@live555.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, Jonathan Rosenberg <jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary="00000000000017176d059ef2dbe5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/9SozVf4VmH3G_LfwTJ6yynIwU6U>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 19:33:03 -0000

Thanks for this paper, I think this is a good exploration of the space,
especially the table on page 4.

Generally I think the substrate protocol gives us datagrams (or a suitable
alternative), encryption, a global sequence number, and some parts of the
necessary congestion control machinery, and the rest needs to be layered on
top.

On Wed, Feb 19, 2020 at 8:03 AM Joerg Ott <ott@in.tum.de> wrote:

> Let me just point out here that there is still a dangling question
> if one could leverage more state from QUIC than just offering a
> datagram service.
>
> Colin and I went through some thought exercise to this end, but we
> don't have an integrated implementation within QUIC for some RTP
> features yet.  Still, our little analysis may turn out to be useful:
> http://www.netlab.tkk.fi/~jo/papers/2018-12-epiq-quic-rtp.pdf
>
> Jörg
>
> On 19.02.20 16:57, Cullen Jennings (fluffy) wrote:
> >
> >
> >> On Feb 14, 2020, at 10:00 PM, Ross Finlayson <finlayson@live555.com>
> wrote:
> >>
> >> If we want to get something standardized/working quickly, then this is
> a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets
> directly in QUIC datagrams - in such a way that the existing RTP payload
> format defined for each media type could map directly (i.e., with no more
> media-specific IETF standardization work required).  Even if this means
> that there's some duplication of functionality between RTP and QUIC
> (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)
> >>
> >> While - at some point in the future - it may be worthwhile defining a
> new version (v3?) of RTP that works more efficiently with QUIC, this should
> not be something that we require before we define/standardize a replacement
> for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to
> show its age, but it’s not broken, and has lots of existing deployment that
> could, ideally, be leveraged quickly within a SIP replacement.
> >
> > Almost no modern RTP implementation actually does the full RTP spec so
> at the very least we need some serious subsetting of what part of RTP would
> be mapped to QUIC. The RTP extension mechanism is badly broken particularly
> for low bandwidth satellite links. And if you look at what RTP clients do
> with the RTCP sent to them, well, I think there is some house cleaning
> needed here to be able to actually use RTP /RTCP.
> >
>
> --
> V3 mailing list
> V3@ietf.org
> https://www.ietf.org/mailman/listinfo/v3
>