Re: More on demultiplexing

[Ian Swett <[e-mail]>]

I was thinking along those lines as well, Jana, since I think we have a
pretty general problem here, and if we grease the type byte, I think we can
create a fairly simple solution.

As you mentioned, the WebRTC over QUIC mapping would have to specify which
QUIC codepoints could not be used in the short and long header.  As a
slight tweak on your idea, I think that only the application should specify
what codepoints cannot be greased for the long header, but the transport
params can contain additional codepoints which are to be avoided by the
peer in the short header.  So the list of codepoints to avoid are not
negotiated, but communicated.(ie: the client might be fine with anything
and the server might exclude DTLS codepoints).  And any codepoints the
application mapping specifies should be avoided do not need to be
communicated in transport params.

As an example, this means that even if the types are 0 through 3, those
codepoints may be excluded and never sent on the wire and in reality,
numbers more similar to the submitted PR#956 may be sent on wire.

This means there may be conflicts between the long header and a different
application that happens to be running on a given port, but those can be
handled by looking for long headers and checking the version before doing
any more expensive processing.

Cases like WebRTC should be easy to handle by excluding the problematic
codepoints in the WebRTC over QUIC mapping.

The only(obvious) rule is that you can't exclude all ways to express a
given type, but that's dependent upon the exact type byte greasing
approach, which hopefully we can separate from the multiplexing approach.

On Thu, Dec 7, 2017 at 3:00 PM, Jana Iyengar <[e-mail]> wrote:

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