[AVTCORE] Design meeting [was Re: draft-petithuguenin-avtcore-rfc5764-mux-fixes: How to do the IANA allocations]

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

When Gonzalo and I talked about the modifications to make to draft-petithuguenin-avtcore-rfc5764-mux-fixes, we realized that we were really confused by some the proposals, so we did the minimal set of modifications that made sense.

This said we really would like to come to the AVTCore session on Tuesday with a proposal that most people could agree with, without having to loose another 4 months.  That's why we are proposing to have a short face-to-face meeting on Sunday 22 after Dinner (9pm) with people who care about these issues, and to present the results of this discussion on Tuesday for consideration for the revision of the (hopefully to-be-WG-adopted) draft.

Some answers below.

On 03/12/2015 04:37 AM, Magnus Westerlund wrote:
> Mo,
> 
> I think this is a great question and clearly an issue that needs to be
> discussed. However, can we please have this discussion under another
> subject line, like this one?
> 
> I would also like to note that we need to ensure that the DTLS/TLS
> community don't have issues with this as we are narrowing in the space
> also for them.
> 
> Cheers
> 
> Magnus
> (As WG chair)
> 
> On 2015-03-12 02:46, Mo Zanaty (mzanaty) wrote:
>> 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

We are also proposing STUN over SCTP over UDP in draft-ietf-tram-stunbis which will use 192-255 (2 MSB of both SCTP ports set to 1).

Another proposal that I like is the shim proposal by Paul Jones.  Maybe we should also use that and perhaps integrate the best parts of draft-westerlund-avtcore-transport-multiplexing.

I did not yet read the latest version of BUNDLE, but maybe BUNDLE could also benefit from a common mux/demux framework.

>>
>> 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.

I would prefer to add an explicit column that says "Can be used for multiplexing".  This way proposals for new TLS ContentType have to think about the mux case.

>>
>> 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.

Right.  I also loose 1d100 neurons each time I look at this thing.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVAc9fAAoJECnERZXWan7EkFsQALwY5gzJPQHWZjgYRjHsrRZC
0n9JTyDTgNa/Xc5/6w193oTl/nFpEG0t0D/lgGbpQQrjFce0r+OMj8F+bpSNtacW
JYoz2xIuPs78gBoOxnQ9QWYT3lHI8mG9DF2ciEQW+IqTP/qtjVS1wYi4cG86/Nvf
LaVwyssXI4UhXT7tfpywFLQJDrUDHi6+7OSpD72S71ih6tm1EDz4aBNmjV2cC9c5
MO93sVYzjwVavpdw9t3ej/navr5qHfKcQq+r1+2FH/aQXHdAUP9QWDH59/byCPPN
pCoNlecYjH8BidblO+Jlb1xQK5sPGcjngxLyHm124aJHeoJea7CYY+sVut1kdkxd
Z2t3mIF5U3QT5Q9L5Lmloy3k70wfAkXNNrWdglMX5ak+qezj7JDRCiH4O+GwIpXz
K1dl+PgwYIbMeOo8ONoUSrX++cOEtsV8Cp0CdqFKJyv8SG/13/Y91FO+L6qtL6rG
YQ613vyjHba2lQP5w0KQvMKX5hC3/BvdUch2foY4xIAyzJCc4+UDBrurxdeLXkqB
NtOG8t0QvYWSLxk2n/BMYE7m/emNSnnAXSURgBbMoXihtQusYY33vJLgxKo+PYCm
khxHdqFeppx6gFP3npyc/pe4Eulx39GG74mCpJUp51t4uHXH43Cz5o0MWPHeZvjy
5XZeFuuthSSBVoY/ClFP
=qTv/
-----END PGP SIGNATURE-----