Re: [AVTCORE] Call for Adoption: Multiplexing Scheme Updates for QUIC

Justin Uberti <> Fri, 31 July 2020 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2604D3A0F43 for <>; Fri, 31 Jul 2020 10:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 jgElOLtpzCE0 for <>; Fri, 31 Jul 2020 10:44:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62F953A0EB3 for <>; Fri, 31 Jul 2020 10:43:19 -0700 (PDT)
Received: by with SMTP id l17so32445999iok.7 for <>; Fri, 31 Jul 2020 10:43:19 -0700 (PDT)
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=64ILb3VYeJxoEVb5GGskJdXMmSNhIhJ1CCaTShEQ63g=; b=ZLoJpiaKE4U3f+CDtbg5yLqBqccIaFz1o0CiLRnYf6Ql70QtpJus34Z4AHiQyKAVLx tdPnYicbf/YeZ19vWFfuJr+fZAH5x+JZlOAEzxrlTRgPT1gfgWcvFp8c0+6ZdtbCVLB8 ldO6HCtL6Udw0aXlcGbAoCkxlaUKJohel5viE19t50Tur9xsGuYTL9c2Cv0RZU1WezMB JZAJc9FkxyAb46DTkAhRnhn9o1As2i7IrvrX8NZgv5ESuVdT2aF5fNITGgnrRbIGJ5Q5 ki74UUXVHbjICep3estfLoSr1x4CpGDlf4JY9RV9/EQoPyO5tLlMyGK5IUVs7LrpdvDH lQfw==
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=64ILb3VYeJxoEVb5GGskJdXMmSNhIhJ1CCaTShEQ63g=; b=e8031HqQNUudJCMxkTNe2SeQCZM+nVCxOVvZAtSnx7xYLmjw+87l12dTYdLfdqyouZ PUQnupM6Y/UgcUzeEVJIyqFyZjkLD9mczQTJWo6xpCOZE7pArlKk6GSy+l95hZuWqWBg AGlG1zNPgqP70T3pNhzq9XYI1zrmwATNw7EQ435VK/zydDYewpPXa/4ELtIjxrrgcCkL dNVMN5N54bo6+vwre8W+bbHjRtwXih7bvfHG4iAH3nQImv3u2zVf3e+RTLwuOwonTdD1 O2OBz7IqmTDPcx70kf3SJTHrFqB9B4+CGUL/Ybh5QDct8O1itQl/k0nHzki9qw5Ab5OE 0vLQ==
X-Gm-Message-State: AOAM5332K+zRO8xCYSWC+qFqUv5CfDTHIkW3BWUmJYZVsTZkfEwO/GyV Jj9VY10EbrP4zqXcHVuhKgrUbCjMm7MvYuZgeom+9FdQEOs=
X-Google-Smtp-Source: ABdhPJygRic6WlERWOOC0TdpPVN1vU3Zve5mRhG78TQYBNrhZ15Ck4SuvW33kHvu8KppiERFQqm+f2ZmCpfpm+NBmtE=
X-Received: by 2002:a05:6638:2601:: with SMTP id m1mr6271169jat.141.1596217398065; Fri, 31 Jul 2020 10:43:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Fri, 31 Jul 2020 10:43:06 -0700
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000ff5ea005abc052f2"
Archived-At: <>
Subject: Re: [AVTCORE] Call for Adoption: Multiplexing Scheme Updates for QUIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 17:44:09 -0000

On Thu, Jul 30, 2020 at 9:49 PM Martin Thomson <> wrote:

> Hi Jonathan,
> The draft makes some claims that are not clearly true about QUIC.  In
> particular:
>    As noted in [I-D.aboba-avtcore-quic-multiplexing], the first octet of
>    a QUIC short header packet falls in the range 64 to 127, thereby
>    overlapping with the allocated range for TURN channels of 64 to 79.
> It's important to distinguish between QUIC as defined in
> draft-ietf-quic-transport and QUIC as defined in
> draft-ietf-quic-invariants.  The draft is correct in that it cites the
> former and relies on properties of the former.  However, it is very easy to
> misinterpret this statement as applying more broadly.
> To add spice to this, the claims here are invalid if you consider
> draft-thomson-quic-bit-grease, which allows long and short headers to take
> 128-255 and 0-127 respectively.
> It would be most unfortunate if an IETF RFC were to so directly encourage
> protocol ossification.  This draft needs a more careful treatment of this
> problem.
> Other than that fairly serious shortcoming, this is a worthwhile update
> that is worth doing.
> p.s., I don't know if the approach suggested for TURN channels is
> appropriate, but I trust that AVTCore are competent to decide that.

TBH, I'm not sure whether TURN demux is a real-world problem. You only need
to handle TURN channels if you are talking to a TURN server, and in that
case, you should not be receiving unencapsulated RTP or QUIC traffic on the
same 5-tuple.

If the goal is to be able to mux QUIC and TURN channels on the same
5-tuple, I imagine that we'd probably want to first design some sort of new
QTURN that uses QUIC to address TURN's many shortcomings (e.g., TURN