Subject: [AVTCORE] RFC 7983 and multiplex principles

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Nov 2017 08:47:28 -0800

At IETF 100, we had a discussion about the extensibility of RFC 7983 in the
context of QUIC multiplexing.

Martin has put together some thoughts on multiplexing principles:
https://martinthomson.github.io/mux-principles/draft-
thomson-mux-principles.html

One of the points made in this document is the potential impact of
multiplexing on protocol evolution.  For example, with respect to DTLS:

"For instance, DTLS 1.3 [DTLS13]
<https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html#DTLS13>
defines
a record layout that uses the first octet in a very different fashion to
earlier versions; this design is constrained by the need to remain
compatible with the scheme in RFC 7983"

Maintaining compatibility of DTLS with RFC 7983 does seem to be important,
since non-backward compatible changes could leave existing RFC 7983
implementations unable to upgrade. But is this binding, or merely a "nice
to have"?

To the extent that there is one, the "contract" entered into by protocols
mentioned in RFC 7983 is contained in Section 9 (IANA considerations),
which covers:

    Section 9.1:  STUN Methods
    Section 9.2: TLS ContentType (see:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5
)
    Section 9.3: TURN Channel Numbers

It is interesting to note that RTP/RTCP and ZRTP are not included in the
IANA considerations section, so that there is no "requires coordination"
applying to RTP version allocation, as there is to TLS ContentType.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Nov 2017 17:01:43 +1100

The principle I propose in the draft of a draft says that a general
purpose protocol should not consider the multiplexing use to be
binding.  DTLS is often used with 7983, but not exclusively.

I would say that it's not a guarantee that new versions of DTLS stay
in the 20-63 range.  Obviously, we will try - and we have done so with
the latest changes to the DTLS record layer - but that is not an
ironclad guarantee.

You could say that 7983 imposed that contract on DTLS, but that wasn't
entirely consensual.  If DTLS identifies a need to break this contract
that is stronger than its desire to remain compatible with 7983, then
I think that is a decision that will be made on the strength of the
need.

On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba <[email-masked]> wrote:
> https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html
>
> "For instance, DTLS 1.3 [DTLS13] defines a record layout that uses the first
> octet in a very different fashion to earlier versions; this design is
> constrained by the need to remain compatible with the scheme in RFC 7983"
>
> implementations unable to upgrade. But is this binding, or merely a "nice to
> have"?
>
> mentioned in RFC 7983 is contained in Section 9 (IANA considerations), which
> covers:
>
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5)
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Nov 2017 15:36:43 -0800

Martin said:

"The principle I propose in the draft of a draft says that a general
purpose protocol should not consider the multiplexing use to be
binding.  DTLS is often used with 7983, but not exclusively."

[BA] No RFC is "binding" in perpetuity, since with appropriate consensus,
another RFC can always be produced to update or obsolete it.  Also, RFC
7983 is conservative in its IANA Considerations section, which only
mentions allocation policies for STUN Methods (Section 9.1), TLS
ContentType (Section 9.2) and TURN Channel Numbers (Section 9.3).  Since
Section 9 doesn't mention anything about RTP/RTCP allocation policies, it
can't even be said to "bind" RTP/RTCP, let alone other general purpose
protocols.

"I would say that it's not a guarantee that new versions of DTLS stay
in the 20-63 range.  Obviously, we will try - and we have done so with
the latest changes to the DTLS record layer - but that is not an
ironclad guarantee."

[BA] That is entirely consistent with the IANA allocation policy for TLS
ContentType, which is "Coordination Required".

"You could say that 7983 imposed that contract on DTLS, but that
wasn't entirely
consensual.   If DTLS identifies a need to break this contract
that is stronger than its desire to remain compatible with 7983, then I
think that is a decision that will be made on the strength of the
need."

[BA] I think that is implied by the "Coordination Required" policy, is it
not?

The more complicated question relates to the practicalities of opting out
of RFC 7983.  That seems somewhat akin to Brexit in that we may not know
how hard it will be until we look into the details...

For example, we talked about how a future version of QUIC might make at
least portions of RFC 7983 unnecessary by potentially transporting media
over QUIC (making it unnecessary to multiplex RTP/RTCP with QUIC) or by
supporting QUIC-SRTP and replacing the SCTP data channel (making it
unnecessary to multiplex DTLS with QUIC).

On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson <[email-masked]>
wrote:

> which

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2017 20:43:40 -0500

Doing the multiplexing this way was always a devil's bargain.
It is just a matter of when the bill comes due.

On 11/28/17 6:36 PM, Bernard Aboba wrote:
> [BA] No RFC is "binding" in perpetuity, since with appropriate 
> consensus, another RFC can always be produced to update or obsolete it.  
> Also, RFC 7983 is conservative in its IANA Considerations section, which 
> only mentions allocation policies for STUN Methods (Section 9.1), TLS 
> Section 9 doesn't mention anything about RTP/RTCP allocation policies, 
> it can't even be said to "bind" RTP/RTCP, let alone other general 
> purpose protocols.
> 
> "You could say that 7983 imposed that contract on DTLS, but that wasn't 
> [BA] I think that is implied by the "Coordination Required" policy, is 
> it not?
> 
> The more complicated question relates to the practicalities of opting 
> out of RFC 7983.  That seems somewhat akin to Brexit in that we may not 
> know how hard it will be until we look into the details...
> 
> On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     <https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html>
>      >
>     <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5>)
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/avt>
>      >
> 
> 
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 14:10:48 +1100

I've gotta say, the Brexit analogy is somewhat appealing, if not
entirely accurate.

On Wed, Nov 29, 2017 at 12:43 PM, Paul Kyzivat <[email-masked]> wrote:
>> another RFC can always be produced to update or obsolete it.  Also, RFC 7983
>> is conservative in its IANA Considerations section, which only mentions
>> allocation policies for STUN Methods (Section 9.1), TLS ContentType (Section
>> 9.2) and TURN Channel Numbers (Section 9.3).  Since Section 9 doesn't
>> mention anything about RTP/RTCP allocation policies, it can't even be said
>> to "bind" RTP/RTCP, let alone other general purpose protocols.
>>
>> of RFC 7983.  That seems somewhat akin to Brexit in that we may not know how
>> hard it will be until we look into the details...
>>
>> On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>