Re: More on demultiplexing

[Jana Iyengar <[e-mail]>]

On Thu, Dec 7, 2017 at 11:51 AM, Christian Huitema <[e-mail]>
wrote:

> On 12/7/2017 10:59 AM, Cullen Jennings wrote:
>
> >> On Dec 6, 2017, at 12:15 PM, Ted Hardie <[e-mail]> wrote:
> >>
> >> I think if you bundled all the media on one 5-tuple and had QUIC on
> another, the core NAT exhaustion problem would not be that bad.
> > It would be twice as bad :-) When creating the offer, the device that
> creates it does not know if it will be getting QUIC based stuff or not so
> you want to include both in the offer. For the same reason we don't want to
> gather two ports for RTC and RTCP, I think we will want to run both on same
> port. I think google's data showed that nat traversal success rates were
> worse when using two ports instead of one.
> >
> > So my preference would be to be able to multiplex WebRTC using QUIC and
> and WebRTC not using QUIC on the same port.
> >
> +1. When dealing with NAT, there is a cost per port to "opening a hole
> for the port", in terms of messages to open the port, risks to cause
> resource exhaustion in a local NAT, and requirement to keep the port
> alive. Everything on one port is nice.
>

I agree on this point. It's more than just nice -- it avoids strange
partial failures when one part of the communication works (over one port)
but the other part (over the other port) doesn't.


> By the way, how strongly do we feel about making decisions based on
> first byte alone? In the case of QUIC, the connection ID provides a
> pretty big clue. If we use that, demux becomes significantly simpler.
> There are still issues during the connection phase, as the first message
> from the peer carries an unknown connection ID, but that could be
> handled with special logic. Also, don't STUN messages carry a magic
> number precisely to help demuxing?
>

Why have the same conversation once in one place when we can have it twice
in two places :-) I raised this  point in #426
<https://github.com/quicwg/base-drafts/issues/426>, and Colin responded
there, you may want to take a look. He does suggest using connection ID,
but it's not yet clear to me that the C bit needs to be changed in that
case.