Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
Kazuho Oku <kazuhooku@gmail.com> Wed, 07 February 2018 13:13 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 572CE127058 for <quic@ietfa.amsl.com>; Wed, 7 Feb 2018 05:13:29 -0800 (PST)
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 DXTyQyzDEtt2 for <quic@ietfa.amsl.com>; Wed, 7 Feb 2018 05:13:27 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 5ED3B1205F0 for <quic@ietf.org>; Wed, 7 Feb 2018 05:13:27 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id w83so286565pfi.12 for <quic@ietf.org>; Wed, 07 Feb 2018 05:13:27 -0800 (PST)
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:content-transfer-encoding; bh=WCXG6+FTNz9dju2TChyew10lYir3DcQnhCRrvUVquuw=; b=hiAwocXSPUyihU+jAVS/JADGM9BIsLeh/n8aTF3yUf7PLSNy7/i5rwgDx5A5oGWD+O v2E+C3/veyJhei44zdbXakWVcydUzNZDPq7W5KkBmnzTi7U2odm+rlcEHpHi60FKuJn8 Kp3UJhMgbvYtEaYtkIvnN0Ff1TVY1zO6JSvLu59Q+0QxO7UUVOwiKuMydfBV8O2CrfM2 Kf2x7AsHLAIJmzuQaSk84zW/HtGQC1alTvRbALefTa79m6Xsc/M+fQSUOydBzvBU83PB yD6Fe2v+UtQFLV9AYcKWjxvD9bTRDVut9Z2kq+doG0artur0WSJ9pHeQ92ybtV6KcwVd Um5g==
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:content-transfer-encoding; bh=WCXG6+FTNz9dju2TChyew10lYir3DcQnhCRrvUVquuw=; b=Fz8Sz0zemf2bMFgKyGhWQ8E6qn9rk01BK/v/TpKxKc869Te/mMBmUSfD6IAMmuzGf5 xyibW4OFtHaZQJ6U9RQEyMV9UzsEjfkB3n6S9ErriCM4yJWqkP5dUlDXwi4VqjIGQrle 21F8urPiHWMuWbejkFOqy8gc8yUqEpCxi6VVkskDt69zhEKpbjrXhcKKtR8Oi8UjdkZm rZzGQsXrea+So0sTtDvUciEIi7VGeo/lHv9nx1zcmHcnBPd3ey5HWZNe5NvKDcEw5Fkz zgNr4SyEz0cdYgIAaSU3w0uTsPSSPNXztYsL1TCT++hq9Fyof37borJfU4mgU53U6TCO B4gQ==
X-Gm-Message-State: APf1xPDvcfRFL4cr+oGN07cTCO3kQQYZob4G2HxEwzG7Ud5nvFYWof5X T8I6VgjKjMwMs65Ua/0TyITB72y1cgJLOY/0WaI=
X-Google-Smtp-Source: AH8x226izCWj1I3foLx0abdeb1PDI5uO/iBCIoPK2kPuR1biXES62kEyi8nSyxBymz//GB0LjXgDBjOFMxxLstR1quw=
X-Received: by 10.98.25.207 with SMTP id 198mr6032068pfz.83.1518009206923; Wed, 07 Feb 2018 05:13:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 05:13:26 -0800 (PST)
In-Reply-To: <CAN1APdcjQ7GChp+yWD6yMPw=XXT-XXmspSK-D=iT4Wcj-c47tw@mail.gmail.com>
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> <CAN1APdcuKSLYw4Odyc4g=+4_+ojsNekeqmM9eYqxykkfxRx3Cg@mail.gmail.com> <CANatvzz3rmGPRgu1Z5+bAHhgjiN3L5OVTDhb4fmpPX+M8o4z3w@mail.gmail.com> <DB6PR10MB17661B9957DF90733FA28EC5ACFD0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <DB6PR10MB176682C63A91007574BBEAECACFC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CAN1APddkFxLFREQQe+0Kqqi+zJeU20ALjzN4R0Muf9FD1BzZUg@mail.gmail.com> <CANatvzw3RFekoHx_MJWkDY0Q+G2gUNshpocozwkQWpH8sqnnTA@mail.gmail.com> <CAN1APdegDghGnw64XLhc25YaeV9uuVwRmquB8037SULDdrZC+g@mail.gmail.com> <CAN1APdcjQ7GChp+yWD6yMPw=XXT-XXmspSK-D=iT4Wcj-c47tw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 07 Feb 2018 22:13:26 +0900
Message-ID: <CANatvzwczerPd7cx1mo1-Pni2PL04VohZYSPW=ObMNQAgO5vMA@mail.gmail.com>
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: "Brian Trammell (IETF)" <ietf@trammell.ch>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pbKpD8UDflHjGheRZwKZiZXJ1Ik>
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: Wed, 07 Feb 2018 13:13:29 -0000
2018-02-07 21:21 GMT+09:00 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>: > Hmm a periodic truly white noise random signal ought to have an evenly > distributed power spectrum meaning it contains all frequencies up to half > its cycle length. At least there is a lot of solid communications theory on > random signals that could be applied, e.g. > > https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-011-introduction-to-communication-control-and-signal-processing-spring-2010/readings/MIT6_011S10_chap09.pdf > > http://bme.elektro.dtu.dk/31610/notes/chap_8.pdf > > Thus limiting the signal to a square or a sine is effectively wasting a lot > of bandwidth, even if naive hash based signal processing is insufficient to > deal with a proper random signal. I mostly disagree. The reason I am suggesting to use square or sin wave is because it has a base frequency (i.e. wavelength) that can be used to calculate the loss rate. White noise does not have a "base frequency." Therefore, it becomes harder to observe the metrics when the loss / reorder rate becomes high. Going back to the discussion of the approaches, I am not against mixing in some random signals so that pattern matching can be applied when the error rate is low. But such "mix" should be mild enough that it would not disturb the observation of the base frequency under high error rate. And in fact, you do not even need to mix randomly flipping bits if you select a sin wave, since a sin wave quantized to 1-bit will contain many flipping bits. You can use those bits for pattern matching. OTOH, if we select square wave, it might make sense to apply some bit flipping so that we can apply pattern matching. There are other possibilities as well. However, with that said, I believe that the design decisions need to depend on the actual use-case. What are the loss rates that we need to work on? What are the reorder patterns that we would observe? IMO this is the tricky part of the 1-bit approach. > Of course there is the argument of > simplicity, but long term I believe more information in the signal is more > valuable. > -- Kazuho Oku
- Packet number encryption Martin Thomson
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eggert, Lars
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Duke
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Dmitri Tikhonov
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Piotr Galecki
- Re: Re: Packet number encryption alexandre.ferrieux
- Re: Packet number encryption Patrick McManus
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Roberto Peon
- RE: Packet number encryption Piotr Galecki
- RE: Packet number encryption Roni Even (A)
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Lubashev, Igor
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Willy Tarreau
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Reducing ossification through protocol design (wa… Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Roberto Peon
- Re: Reducing ossification through protocol design… Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- RE: Packet number encryption Roni Even (A)
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- Re: Reducing ossification through protocol design… Salz, Rich
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Reducing ossification through protocol design… Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Marten Seemann
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Gorry Fairhurst
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- RE: Explicit measurability in the QUIC wire image… Roni Even (A)
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Stephen Farrell
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Martin Thomson
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Martin Thomson
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption David Benjamin
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Deval, Manasi
- RE: Packet number encryption Deval, Manasi
- Re: Packet number encryption Victor Vasiliev
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Ian Swett
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: hardware offload (was: Packet number encrypti… Christian Huitema
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Eggert, Lars
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen