Re: The first octet

Kazuho Oku <kazuhooku@gmail.com> Wed, 08 August 2018 14:25 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B16130E23 for <quic@ietfa.amsl.com>; Wed, 8 Aug 2018 07:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z6Y8XWq7Juo for <quic@ietfa.amsl.com>; Wed, 8 Aug 2018 07:25:12 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373AE130E21 for <quic@ietf.org>; Wed, 8 Aug 2018 07:25:12 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id p6-v6so1874383ljc.5 for <quic@ietf.org>; Wed, 08 Aug 2018 07:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hcPDZ75BPzCaF4imKHW1LoXyBWjzasL+DYCYDSK8A+c=; b=dd6HbQqXdkMS20EUtS/qY76X/XyhH87tvy7V2OiM7ZW4ebac7hF77MsjQdo4ER/Rju mKT7IZt47Jq78d/K2QXikvlbVb7U94CyKkA88V8DHoDp1y14p1fIrlZrxT7+85c8eLfr DlJRjYbt+s43s7w4J/Tsj7Ih3ViZYS5bUv5gSE9KiLSBh7hZIZWxrEogVHhQvyRageoD DhwsROAm4aeEjh3aYP7FXMqapSCQxWzWAYmgDvFggXd/6WMzZcojSrV2kDnb5McQC8PX Byrf8IVxSuvJtU/AsotLHT1KpQFX46iFaGeukc6jSatEDuordvMUQJpbFaciG2r3hlOP upzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hcPDZ75BPzCaF4imKHW1LoXyBWjzasL+DYCYDSK8A+c=; b=efZALDJV5uPiQQVGAMzkS/DNU+4nQG0QrPS0IyQjUWZXgbzTQXbmvnFEJPrwE7JhJl lmH6Z/HLHbKSgxLpOo/TAMkgWdCs8TjXBZdN8RVwTF9aOOaY7ka81qPczN2HWQWomiqf 8nbCPKxH0wJqikA4Ks6rU8Le8KlmayEtblVWYkg/NTDWfTI+IzNVBVfZs5T9FUtDM4IX DVSFxOXmCafRL+NMhkIeP2I0DNDvq3mG5SfzXjHJkD2g2XJasodo/Bgr1btQiONVUL3P BkioBpEF72G7nYuLiqWDxmNX3M3wBasZmK1w8lZXXIu1kvV6C0IpBgHH5LWiwj02iBgN p9JA==
X-Gm-Message-State: AOUpUlG7HYDq9UJrJ7NintpLMp2weUb3bXm0b0jUDmRA1sm+aKUdtyIV dwx1FGcch2MxDpQmOoxg5g2iag8EUwuyhc2nxAw=
X-Google-Smtp-Source: AA+uWPwJRPmkGxDnxrBMpSvPcdwQx7gy/a8ONQ30/NpIx/rjjPro0psfRBqrLm7F7xF1S7j5o49u3ZarR8sBPMpW8R4=
X-Received: by 2002:a2e:40c:: with SMTP id 12-v6mr2363363lje.146.1533738310389; Wed, 08 Aug 2018 07:25:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 07:25:09 -0700 (PDT)
In-Reply-To: <CABkgnnWXQPi0fSy-66dOT9cEZk1xomb1rM-6=T21mMKhgvyHVw@mail.gmail.com>
References: <CABkgnnVFYMjWDk6zEEA8T_6qg+6qO9yAwVF70foMj4bXEdBaqQ@mail.gmail.com> <CANatvzwRcaE48mXpjTbeUtA4QLG-iJtXnDqjP5BjBm-RMPWodQ@mail.gmail.com> <CABkgnnUegjp1r6iRMRRqYretRFZBjHHdkiCxaLi56ywpkogufA@mail.gmail.com> <CANatvzw6Sfa56O01Vxf7pKGaVCQAGrpzAe_njOKuywbeQJow8g@mail.gmail.com> <CABkgnnWXQPi0fSy-66dOT9cEZk1xomb1rM-6=T21mMKhgvyHVw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 08 Aug 2018 23:25:09 +0900
Message-ID: <CANatvzzUu59kcv_eWTAPU=an_pdBVZykH8PQnnEHHH=UG9+S-w@mail.gmail.com>
Subject: Re: The first octet
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZH2oag9iRber8Tt4kjWpSzbxgtc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2018 14:25:14 -0000

Hi Martin,

Thank you for the clarifications.

I now better understand the intent of your proposal. I think I'm fine
with providing a way to demux the protocols without making that an
invariant.

I tend to agree with Colin that it is a good idea to have some form of
randomization / greasing for endpoints that do not need to demux. We
could potentially send a signal that instructs the peer to grease the
demux bits by using TP. Or, a server could send a signal that tells
the client it is free to grease the bits when it resumes a connection.

But that is a slight preference. What is at stake here is just few
bits. They do not expose the state of the connection, so the risk of
ossification is simply that we might not be able to use the bits in
the future. Considering how few the number of bits on the table are, I
do not care much.

2018-08-08 18:51 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On Wed, Aug 8, 2018 at 5:41 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>> My understanding is that we do not avoid conflict in the invariants,
>> but you suggest to avoid them in v2.
>
> v1.
>
> Yes, that was the idea.  The protocols we're talking about could have
> the luxury of being able to negotiate versions carefully, and avoid
> any version that doesn't suit.
>
>> For example, is it the case that you think avoiding conflict in the
>> short term is worthwhile, at the same time keeping the possibility to
>> change the decision in the future versions of QUIC?
>
> That is certainly true.  See Colin's response too.  He managed to
> summarize the thinking here fairly well.
>
>> Honestly, I do not have a strong opinion here, although I worry about
>> ossification when we decide not to grease the bits. Therefore, I would
>> like to understand why you think avoiding conflict in v2 but not in
>> invariant is worth considering.
>
> Yes, the risk exists.  We could, for example decide to try to mitigate
> this risk by choosing something maximally bad for 7983 demux and force
> folks who want to do that to define a new version, thereby generating
> two variants in relatively quick succession and pinning our hopes on
> that helping.  I tend to think that things ossify on longer timescales
> than that and so am willing to risk those bits sticking for this gain.
> For the short header, it would be exactly one bit.
>
> Invariants is part of our protection here.  It might turn out to be
> futile, I don't know.  But I would be very happy to define a new
> variant that set that bit to zero.



-- 
Kazuho Oku