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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Mar 2015 09:38:05 +0100

WG,

We have a milestone

Apr 2015 Submit Multiplexing Scheme Updates for SRTP for DTLS as
Proposed Standard

We have to my knowledge only one candidate document.

So unless someone protest before the WG session in Dallas (13:00 CDT the
24th of March), draft-petithuguenin-avtcore-rfc5764-mux-fixes will be
adopted as WG draft for the existing milestone.

Cheers

Magnus Westerlund
(As AVTCORE chair)

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Mar 2015 10:24:58 -0700

Yes, it should be adopted ASAP (it is needed). 

> Date: Wed, 11 Mar 2015 09:38:05 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: [AVTCORE] Adopt draft-petithuguenin-avtcore-rfc5764-mux-fixes as WG	draft?
> 
> WG,
> 
> We have a milestone
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Mar 2015 13:28:00 -0400

> Yes, it should be adopted ASAP (it is needed). 

+1

Simon

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 11 Mar 2015 14:27:58 -0700

+ 1

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Mar 2015 01:46:00 +0000

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Mar 2015 11:37:38 +0100

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)

-- 

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Thu, 12 Mar 2015 08:29:50 -0400

> Do we really need 16384 TURN channels per client?

Yes that's a discussion we need to have.

One thing to keep in mind is that the protocols individually define
ranges that are much larger than what was in RFC 5764, and they do
overlap in some cases. So we end up with codepoints that may be used on
a multiplexed connection and others that may not. IIRC a few
non-multiplexable codepoints have already been assigned. I wouldn't want
to have to define multiplexable and non-multiplexable versions of the
same codepoint because we decided to restrict the range of multiplexable
codepoints.

Summary:
- Ok in principle to restrict the multiplexable codepoint ranges.
- Need to carefully review already-allocated codepoints and ensure we're
not shooting ourselves in the collective foot.

Another thing is that we're currently doing STUN-bis and TURN-bis in
TRAM, so it is a great opportunity to fix this for STUN/TURN at the
source. That is, we could explicitly define multiplexable and
non-multiplexable ranges and sync with this draft.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 12 Mar 2015 11:39:43 -0600

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.

>> 64-79 = TURN (4096 channels)

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.

>> which is the ³DTLS-OK² column. That column should just be marked ³N² for

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.

>> multiplexing diagram, just use a simple list like above that will directly

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

Thanks.

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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Mar 2015 18:55:19 +0000

Thanks for the pointer. I will review and comment in tram, but also
quickly here.

This closes the door on any possibility of RTPv3 (maybe that door is
already closed), and burns 25% of the entire space, just to send big STUN
messages (>MTU). I suggest we leave 192-255 unallocated, and restrict the
SCTP port for STUN-over-SCTP-over-UDP in stunbis to be 0x1ff to replace
the end of the current STUN range (method 0x7f). It seems excessive to
allocate 16384 SCTP ports for STUN when only a single dummy port will be
used.

Cheers,
Mo

On 3/12/15, 1:39 PM, Marc Petit-Huguenin <[email-masked]> wrote:
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).

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 19 Mar 2015 05:40:51 -0600

> allocate 16384 SCTP ports for STUN when only a single dummy port will be

My personal preference would be to add a shim as proposed by Paul Jones (and so let SCTP use an unmodified standard stack) and stop using this one byte multiplexing scheme.

Please come to the design team meeting on Sunday evening so we can put together a proposal for the avtcore session.

Thanks.

- -- 
Marc Petit-Huguenin