Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 February 2018 14:54 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 5C6B712D7F2 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 06:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 3rvsvXOLrIBe for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 06:54:03 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 B28AC120454 for <quic@ietf.org>; Tue, 6 Feb 2018 06:54:03 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id n206so2735455itg.1 for <quic@ietf.org>; Tue, 06 Feb 2018 06:54:03 -0800 (PST)
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=tOjRN0MiG2OnY97f+WLPcRgbZc0icIGmfng7WCpSF88=; b=IrdBrTYGFCSKSHJ5y7UopbYJ0l/Gu+NIzpqLkM3NtMoYmzkkxKq9dXMVV5QINwA7J2 0iGnnrd8TT/YK4BDRkuziUFCzUuR+BjiBamXvQcneTB22UpsZQaAZEQHlwZTU8GR6oI8 arRVGFcf69utCKfn/rA2u9u+8yJb/EgyJFeaErCT92mt+kfMiqxeLECRxSDIwdN/jaqz 7bWq0rQcPLPjEB0dXGML0E7DdQAXS8JQw9CuW+2HcrybCtng9EFgz2MPxC3UiE5C7w7a Jd4uVai2EOYbyTUfLahSkq6P1TLNPU49FFfA/1zEE7FiN+ZBca1O3JP6ovrM1ZwRLJ23 ymRg==
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=tOjRN0MiG2OnY97f+WLPcRgbZc0icIGmfng7WCpSF88=; b=nW2YPUh68UdW/hPWvsxXnZba2wtYjaUj2PxdQqJIre7SM0dqD4LMMK9dt7ev+0lChi UC5VoVsuxECXoHKonhWdc6KDppndLObAhfuoxrkFLnXRDDTJ0/d5mOwXqEANDCe6XabI i43jmipq47TAXUJWJvBNf0XKwh7O15LD0aOa/hIug74xonm4V7oD6VVqclp/E3tuRETT 0IblzugdjR87QvcLkx88bb3gozDgvLwFRf/F8FptuMv12l8LV31/qtgudoJBt+2R8QRD XXLpjSTKOQuELWDrJs6nOvkraG/5aHpeaglMkdxSuFKzUJTjxNXiw9FPH69ouGGHMKFI +0gw==
X-Gm-Message-State: APf1xPBYRVgQIgWfupxaaVTnmwPo323mlAEw1/zNMyPxGHqUfwd5gSKV OzcRPZ8a2odMeqXnWUhc7u9XDQSFbimLLqBVtFhQZQbw
X-Google-Smtp-Source: AH8x227gm4m3LgZDSS2+uQGtVGCdTFE03NDGRwytgQ+NP227oCwOAfencb9QbkXImIKbBQP3qYAWPd5ixQ5oDCgxR+0=
X-Received: by 10.36.131.194 with SMTP id d185mr3545298ite.31.1517928843074; Tue, 06 Feb 2018 06:54:03 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 06:54:02 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com> <CAGD1bZab0GaZFsHwC+nw3AxxC4VusxMJ6oDanzk3dSDdWKAXdw@mail.gmail.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <BY2PR15MB07757473DB9788558B902EB5CDF80@BY2PR15MB0775.namprd15.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <e529144067624fcba636fc8c24ee3ff4@usma1ex-dag1mb5.msg.corp.akamai.com> <BY2PR15MB07754D83A1721F2BD742359BCDFE0@BY2PR15MB0775.namprd15.prod.outlook.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <CAGD1bZaUuNxqpDkn62B0wWcFD8=mCUWrAwWGG-rAOxH7Mf1=cQ@mail.gmail.com> <CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0@CY4PR21MB0133.namprd21.prod.outlook.com> <CAGD1bZaxrqzdkk0wxRaULwOTgg6wnrSrXNBK31s4uxdozaACBA@mail.gmail.com> <CAGD1bZbOAaSBcQw4nVtGuwRunaAW8MYHq9yPxNN6DdKHzt5HtQ@mail.gmail.com> <CANatvzx+uDHMV5XS=OuVYBqe_RYX=EmVWAmjuONS8BpNYCPweA@mail.gmail.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 06 Feb 2018 06:54:02 -0800
Message-ID: <CAN1APdcuKSLYw4Odyc4g=+4_+ojsNekeqmM9eYqxykkfxRx3Cg@mail.gmail.com>
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Kazuho Oku <kazuhooku@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0496527c626305648c59bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-UmJvnN4lEV-t69gx865bMyuh2k>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 06 Feb 2018 14:54:05 -0000

> Sender exposes one bit per packet that can be observed by on-path
> devices. The bit is flipped for every 256 packets that the sender
> sends. Observer records the bit of each packet as they pass by.



This is a pretty cool idea, but it doesn't provide enough information to
protect the spin bit from reordering. This could be easily fixed by moving
to a two-bit spin, as Gorry (I think) suggested. Among other things in this
space, Piet's also looking into how much reordering information could be
extracted from a two-bit spin itself.



This idea can be taken further: You can modulate the signal so you use
multiple packets to encode a zero or a one for half the wave duration. For
example 1 could be encoded as 0101 over four packets and zero could be
encoded as 0011 over four packets.
If there is any reordering, it would show up as an unexpected value in the
pulse.