Re: Structuring the BKK spin bit discussion

Mikkel Fahnøe Jørgensen <> Sun, 04 November 2018 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66BD3130DD5 for <>; Sun, 4 Nov 2018 01:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.738
X-Spam-Status: No, score=-0.738 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8s-C9ImXReay for <>; Sun, 4 Nov 2018 01:24:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0885129C6A for <>; Sun, 4 Nov 2018 01:24:41 -0800 (PST)
Received: by with SMTP id y22-v6so4341315ioj.13 for <>; Sun, 04 Nov 2018 01:24:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=1K8650QEWXZt7Rs6J0/pICYemjfumbqlB9/IBbi88Is=; b=I2HHOrQaSHMz66KjFaOsXzIsqUBQohELCJUDA5x1cmIkl1Y8g4pL25kGdbPNe1ZV/c FZFsc3fjsqrEGw5HSi2obp9A1LbRtJ0V2nm4h30nBaDRj+gVzaQjRRIH4X/mWVX2orXD fldeCOl7sdjMMBCq9WkvCb4PmqITTQAK9NeUgJi6lh4UnHFQaV1X7D0l2LWsMnwh5xZ1 8YTna9ZsrRKRv+Np4tIxOpWyqGsBbSWElIDTuYy+p5OZ+be950Pu7LdIVeWQWGsZCVR5 M8+yiIo134bxeffkreOXFAuciG/bOU2qHxVxwhNSJqS0+UXmlt+8WVAu6cjRvEvPjmS/ Z2HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=1K8650QEWXZt7Rs6J0/pICYemjfumbqlB9/IBbi88Is=; b=VzZSQ7FZlez6M+QWJd62KYqSdZRCNl3vp/2otvxRdW/Z9VHiO/tI1TYfNlvmnGcfVh MtLbs74H8NIFgV8YnUS+gbFcrJvLRRgE7aCTW53gdUW4HMCz2P71mbh5ADcGM7HBXnUO NMyy1IFKsoo5TSb4xYP19j6xDGcOLJ/4Hjz3IWOC5ASStfZWaZ5hTzpFzLRe+VKqh077 MP/WdC9jOST2yrvuBMCgYChjAFPx+SUv91cOdxRZSwSXJJRCZCoeUq4m8PN1nvomx5qm tJW42XuRstKNEOc0GjMM5C6G7QCjUJerAdVdLg9LeV3evaMo2DFw6rmVrfvutzv2cPsq At0A==
X-Gm-Message-State: AGRZ1gLmfjIffUBqvO7KmaAesu+sHDb3UhQK2IrGvKmkP/C738t74KAt yv6AHsO9xS8RH2b+lVDVri3Xw/lKgX6iDgFBOQE=
X-Google-Smtp-Source: AJdET5d5mhL+ncr2xR0nyZPzP2crKbgmtIYt0Rzb1/BVma9TiVBE16eG0WVE3BvnmWXiawekaZHd8Blx1TKgHo7VsPY=
X-Received: by 2002:a6b:ed04:: with SMTP id n4-v6mr821771iog.106.1541323481129; Sun, 04 Nov 2018 01:24:41 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Sun, 4 Nov 2018 01:24:40 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <> <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 04 Nov 2018 01:24:40 -0800
Message-ID: <>
Subject: Re: Structuring the BKK spin bit discussion
To:, Kazuho Oku <>
Cc: Dmitri Tikhonov <>, IETF QUIC WG <>, Lars Eggert <>, Brian Trammell <>, Christian Huitema <>,
Content-Type: multipart/alternative; boundary="00000000000093abdd0579d35684"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Nov 2018 09:24:44 -0000

On 4 November 2018 at 02.52.44, Kazuho Oku ( wrote:

> Roni Even: In this case since there are large packets to one direction
and short to the other an observer can map the download file to its ack
message and calculate the RTT without the spin bit

My understanding is that you cannot.

Because the payload of the packets are encrypted, you cannot tell
which ACK packets sent by the client correspond to which packets sent
by the server. All you can observe is that something is flowing
steadily from the server to the client.

If there are timing gaps or traffic rate changes in the transmission, it is
not hard to associate packets with high probability. Gaps can occur due to
source task switching or when congestion control adapts the flow rate, or
when other connections appear or disappear. They can also appear due to
buffering in middle boxes.