Re: [AVTCORE] Adopt draft-petithuguenin-avtcore-rfc5764-mux-fixes as WG draft?

["Mo Zanaty (mzanaty)" <[e-mail]>]

Agree this is needed and should be adopted as a basis.

During the last presentation on this, concerns were raised (which I share)
about expanding the ranges allocated to existing protocols. The first UDP
byte is precious real estate for future protocols that may want to be
multiplexed with existing ones. Allocation of code points should be the
minimum necessary for each protocol, existing or new.

RFC 5764:
0-1 = STUN (128 methods, 13 currently defined)
2-19 = undefined
20-63 = DTLS (44 content types, 5 currently defined)
64-127 = undefined
128-191 = RTP
192-255 = undefined

This draft:
0-19 = STUN (1280 methods, 13 currently defined)
20-63 = DTLS (44 content types, 5 currently defined)
64-127 = TURN (16384 channels)
128-191 = RTP
192-255 = undefined

Do we really need 1280 STUN methods when only 13 are currently defined?
Do we really need 44 DTLS content types when only 5 are currently defined?
Do we really need 16384 TURN channels per client?

Suggestion:
0-1 = STUN (128 methods, 13 currently defined)
2-19 = undefined
20-63 = DTLS (44 content types, 5 currently defined)
64-79 = TURN (4096 channels)
80-127 = undefined
128-191 = RTP
192-255 = undefined

This allows ~10x growth in STUN methods and DTLS content types before
needing further allocations, and over 100x more TURN channels than current
clients typically need. And it frees up 66 code points (over 25% of the
space) for future allocations.

In the IANA Considerations, I think it is inappropriate to reserve values
in the TLS ContentType registry. The tail should not wag the dog. TLS
should be free to grow if willing to break DTLS/STUN/TURN multiplexing,
which is the ³DTLS-OK² column. That column should just be marked ³N² for
0-19 and 64-255.

Also, please don¹t repeat the confusing range format in the RFC 5764
multiplexing diagram, just use a simple list like above that will directly
match the registry.

Cheers,
Mo