Re: [quicwg/base-drafts] Spin per peer (#1982)

ianswett <notifications@github.com> Tue, 27 November 2018 17:06 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF05130934 for <quic-issues@ietfa.amsl.com>; Tue, 27 Nov 2018 09:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.46
X-Spam-Level:
X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 RS-k2IJ48-jp for <quic-issues@ietfa.amsl.com>; Tue, 27 Nov 2018 09:06:16 -0800 (PST)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 F0430126BED for <quic-issues@ietf.org>; Tue, 27 Nov 2018 09:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=0SUl9CkeZfljrsI9i+AagpEXGL8=; b=FY+B+R9lNdYW3FG6 Vazvr0EXNwdFo7qPzLkqaRkTeWp7TwJkIeQb3x90W7TkWCTNsvpNHJGRDOOAfUM7 szGHSWZmHHD3Q8iXKI8UXYf1jw+Kgt2Iudp5sRPVLIZI5Ysx+68UvcykZyt3Wwfj 573D3aoG7pYawKFdaHjakjhALrI=
Received: by filter0676p1las1.sendgrid.net with SMTP id filter0676p1las1-7726-5BFD7986-7 2018-11-27 17:06:14.44853664 +0000 UTC m=+1016887.709659298
Received: from github-lowworker-56a5eb2.cp1-iad.github.net (unknown [192.30.252.33]) by ismtpd0022p1iad2.sendgrid.net (SG) with ESMTP id TG7FbVf_Rsa35nrwtu2stw for <quic-issues@ietf.org>; Tue, 27 Nov 2018 17:06:14.291 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-56a5eb2.cp1-iad.github.net (Postfix) with ESMTP id 40BAAC127B for <quic-issues@ietf.org>; Tue, 27 Nov 2018 09:06:14 -0800 (PST)
Date: Tue, 27 Nov 2018 17:06:14 +0000
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab076f55fef05bd68d7d07bf312dced5b425c4f4ce92cf0000000118153b8692a169ce169265bd@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1982/review/178902140@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1982@github.com>
References: <quicwg/base-drafts/pull/1982@github.com>
Subject: Re: [quicwg/base-drafts] Spin per peer (#1982)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfd79863ef57_41223fc0d32d45b4297613"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak0wxtRcXVh5epAmTlKXbIG1+Gms/g/y+KM6PI BRrogWzvY/soktUh7u9tc6aiLDUfYLqq1fLUZl9U8GSQZLHJ37eMFNYouST0snEXITx9BN60YqFxJC DusNXJNMTLshtEmDRJeE2+dhNVLiNvseUCZcgktDe3XOj2RAnxAx12C4RkLbZn3jKAJl6SyVNvBLyk s=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/wFdruhMLrZaIMO6orSsw1hR31YA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 17:06:19 -0000

ianswett commented on this pull request.



> +
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least one eighth of network paths.
+The selection process SHOULD be externally unpredictable but consistent for
+any given combination of source and destination address/port. For instance,
+the implementation might have a static key which it uses to key a pseudorandom
+function over these values and use the output to determine whether to
+send the spin bit. The selection process performed at the beginning
+of the connection SHOULD be applied for all paths used by the connection.
+
+Note that where multiple connections use the same path,
+the use of the spin bit MAY be coordinated by endpoints,
+recognizing that this might not be possible in many cases.
+
+When the spin bit is disabled, endpoints MAY set the spin bit to any value,
+and MUST accept any incoming value.
 

Thanks for the summary.

My experience with ossification is that as long as it's not fixed across all connections, the likelihood of ossification is much lower.  But past experiences may not predict the future.  The 'QUIC bit' will likely be helpful as a single thing middleboxes can latch onto, possibly preventing more nefarious ossification.

I think leaving it completely unspecified has a cost.  Namely that I think either setting it randomly or setting a fixed value are safe, and other approaches could inadvertently leak information.  Previously I was concerned that setting it randomly could leak information, but people tell me that's not a real concern.  So if we're going to leave it flexible, I think we should add a SHOULD that if you're not going to spin, you should either randomize or pick a fixed value.  Martin made some clever suggestions previously that I was immediately able to infer loss and reordering from, so I think other options are prone to information leakage.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982#discussion_r236759398