Re: Spin bit decision
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 02 October 2018 12:59 UTC
Return-Path: <mikkelfj@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 63080127598 for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 05:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pLCNY2KM1pI3 for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 05:59:40 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 5AC3F124D68 for <quic@ietf.org>; Tue, 2 Oct 2018 05:59:40 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id c18-v6so1760047otm.3 for <quic@ietf.org>; Tue, 02 Oct 2018 05:59:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=w7TWozWdoZV412F0h66SXvxq7iy0XLoFf7Y41FWdlAM=; b=Y50gpFkgpBzee1NArGRkObIdYb4KPRvX2kiFxo0xxK38omgh/H5oAvxeAKqQR/w70w jUXjgc/7p5A9PhEr2QBZLCnu1ftNCLi6rQhey0CsNAiCsYTtEVfp5UrYkZV5hsAXWKcb gyDYlAJyUb10o5WJNyP1PTHtFq9OBvvvrBjxjjc3MRq4K8VDgKNT7P2eWyXJ3tkLaO1S X6Em0ewMIvDyxlWrdb+hbwnPpOSBPnce9zDvfROdzEoT+K44EbjMpKAdB8/VpdWH6IiP DxV/EeuwqJb95lIOH6r9D7Q5eQUPvfmMDQg3M0sXmbdIRbMSKThvRqs+O37YzYGlGenm oCbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=w7TWozWdoZV412F0h66SXvxq7iy0XLoFf7Y41FWdlAM=; b=FTOzO7Rhzx/jwq2qC8PgZj6WQYr5At1ayCuFrMKZGF5atSovS8Cb2cMvF8f7S2jA/q 92ErQG34KgHdhrU6/svHrmt9tEV7gK2q6vRgwgPhLnaZDxmhosxWgG+EyeBfKr+Do8lN yaRoMY62fNAAA7gmnQgew7Rlp3VzNDsgHaK/5Dkg4zoejzsn750muWe6UeGDRSlpxm2W ChodD4Dqiv0xGcWYbfH1pxT/tEx0hYNYP5nycCfjmgZPtzUS35cFQA7xT5G5wt3SUXgJ FdQ8p8AhwY6QqSl8axXB92YgyDxybanjyg/2BMhmnKwsYqnSH6xCO4Ubs2izWw9cYmMN TE3g==
X-Gm-Message-State: ABuFfoiRkiq2IxmgA2AAnGNtaD8r3Wx29nw9UMpbvQLmQbEcBxaxrmo/ BtxuqBfWsUcB+ocnr11F7f5GcsawlG0sDn8Jmhc=
X-Google-Smtp-Source: ACcGV60wZMa+lKEy+rV0rsPH7xCE31uOH4BqPJEqQV7gGC7PKNop7KR3iCCkV8nomLnEKezG2074CIlkpT88FqiJok0=
X-Received: by 2002:a9d:429a:: with SMTP id r26mr3527035ote.337.1538485179703; Tue, 02 Oct 2018 05:59:39 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 2 Oct 2018 05:59:39 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org> <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 02 Oct 2018 05:59:38 -0700
Message-ID: <CAN1APdcn8Fjbz7XGT4mkCaS503fFCPXaz0X6Qem6eFY4LtD4rg@mail.gmail.com>
Subject: Re: Spin bit decision
To: Lars Eggert <lars@eggert.org>, "<alexandre.ferrieux@orange.com>" <alexandre.ferrieux@orange.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0e55905773e7e51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SxFnmuqbQUKo5G5acebNrSBLTzw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 02 Oct 2018 12:59:43 -0000
Are there any concerns about impact and how to handle or ignore malicious manipulation of the spin either by endpoint or a middlebox? On 2 October 2018 at 14.56.16, Lars Eggert (lars@eggert.org) wrote: Hi, again, as an individual: On 2018-10-2, at 15:41, <alexandre.ferrieux@orange.com> < alexandre.ferrieux@orange.com> wrote: > Well, if the spec says that en endpoint MUST copy of flip a bit, an implementor would be fairly ill-advised not do comply. sure, it may be "ill-advised", but in practice, it won't affect interop at all. > And nothing prevents from adding a "does it spin ?" criterion to the interop test suite. We can certainly consider this - it may give us some data about the current capabilities and configurations of the participating stacks. > Clearly you now have this degree of freedom: weaken that MUST into a MAY or a SHOULD, separately for each role. But for what purpose ? The point I'm trying to make is that it in practice doesn't matter if the spec says "MUST", "SHOULD" or "MAY", since it doesn't affect interop, and doesn't affect performance. Essentially, each stack can decide in isolation whether to spin, echo, do nothing, grease the bits, etc., no matter what language we put in the spec. Lars
- Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Marcus Ihlar
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision Mikkel Fahnøe Jørgensen
- Re: Spin bit decision Brian Trammell (IETF)
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Nick Banks
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Brian Trammell (IETF)
- RE: Spin bit decision Lucas Pardue
- Re: Spin bit decision alexandre.ferrieux
- RE: Spin bit decision Lucas Pardue
- Re: Spin bit decision Benjamin Kaduk
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Mike Bishop
- Re: Spin bit decision Ted Hardie
- Re: Spin bit decision Ian Swett
- RE: Spin bit decision Mike Bishop
- Re: Spin bit decision Marten Seemann
- signaling that QUIC is QUIC was Re: Spin bit deci… Brian Trammell (IETF)
- a proposed way forward was Re: Spin bit decision Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Marten Seemann
- Re: Spin bit decision alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- Re: Spin bit decision Kazuho Oku
- Re: a proposed way forward was Re: Spin bit decis… alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Mikkel Fahnøe Jørgensen
- Re: a proposed way forward was Re: Spin bit decis… Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Mikkel Fahnøe Jørgensen
- RE: a proposed way forward was Re: Spin bit decis… Lucas Pardue
- Spin bit as a negotiated option alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- RE: Spin bit decision Mike Bishop
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- RE: Spin bit decision Gabriel Montenegro
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- RE: Spin bit as a negotiated option Mike Bishop
- RE: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option Marten Seemann
- Re: Spin bit as a negotiated option alexandre.ferrieux
- RE: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- SV: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku