Re: reserved bits for spin bit, etc.

[Ian Swett <[e-mail]>]

Sorry to go off-topic, but...

I strongly agree with Martin that we want to use connection ID for routing,
and not add a path ID.  An explicit goal of QUIC multipath should be to
look as similar(or ideally be indistinguishable) from single path QUIC.
Adding a path ID makes it trivial to link paths, which creates a known
privacy issue and I believe is much more risky than any measurement bits
we've ever discussed exposing.

The details of how to divide up the packet number space can be discussed
later, but it's clear to me that's a viable solution, and QUIC already has
mechanisms for changing the connection ID mid-connection, so building upon
them is the right approach.

On Mon, Nov 27, 2017 at 2:37 AM, Olivier Bonaventure <
[e-mail]> wrote:

> Martin,
>
>>
>>> We cannot quite agree on the spin bit, let alone further management
>>>> bits. On the other hand, we see that there is clear interest from
>>>> something like that with at least part of the WG, we want to see some
>>>> experimentation, and we understand that the specification can proceed
>>>> independently from the base protocol development. Hence, I would like to
>>>> make a modest proposal.
>>>>
>>>> Can we mark one or possibly two bits as reserved in the first byte of
>>>> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be
>>>> ignored when receiving, MAY be used for experiments between consenting
>>>> nodes?
>>>>
>>>
>>>
>>> Having some spare bits in the base header will clearly be useful. In
>>> addition to the discussion on the spin bit, let me also point that a
>>> proposed design for multipath quic also uses one of the spare bits in the
>>> public header
>>>
>>> https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
>>>
>>
>> I don't think that this is a good design.  I think that we definitely
>> need to discuss the separation of the packet number space when it
>> comes to multipath, using the connection ID is superior to adding
>> another byte to the header.  For one, it's something we want to change
>> anyway.
>>
>> The important point is to have different packet number spaces on the
> different paths. There are different ways to signal those number spaces.
>
> The draft proposes an explicit signal which is present in the publich
> header of each packet. One benefit of this approach is that a
> load-balancing router could use this information to forward the packets
> belonging to different paths of a single QUIC session over different paths.
>
> Using the connection id is a different way to distinguish different packet
> number spaces. In this case, there is no need for using space in the public
> header but we need to define QUIC frames to associate different connection
> ids to the same QUIC session. This seems possible as well, but in contrast
> with the above approach, a load-balancing router would not be able to
> easily load-balance the packets of a single QUIC session to different paths
> since there is no structure in the connection id.
>
> There are tradeoffs in any multipath design. I'd suggest that when the WG
> starts to work on multipath we look at detailed proposals.
>
>
>
> Olivier
>
>
> --
>
> ------------------------------
> DISCLAIMER.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>
>