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

[Magnus Westerlund <[e-mail]>]

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


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------