Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)

MikkelFJ <notifications@github.com> Fri, 31 May 2019 13:56 UTC

Return-Path: <noreply@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 B880812009C for <quic-issues@ietfa.amsl.com>; Fri, 31 May 2019 06:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.605
X-Spam-Level:
X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 1bC2__HKs1S2 for <quic-issues@ietfa.amsl.com>; Fri, 31 May 2019 06:56:49 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47867120025 for <quic-issues@ietf.org>; Fri, 31 May 2019 06:56:49 -0700 (PDT)
Date: Fri, 31 May 2019 06:56:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1559311007; bh=ewDrQPFtGiZxL1TkA4p9DzwitSFuE6ayyjofuzLoY3U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uhyaaSCstcXTKkv4xjQ3c++SqjxKrtRNvISykKaBpAdIxv0FvrwcG+9yBUwNnG9Cr RCBPe4uOhYWGbjC7faG5ZSsvOm7gVYEtaJlqHdX3Q9JEjeUv/awzd/tocOe3s6/umI vE5hrQvYKxg+5rdyYtojcVCGbZYjOw3/l1xFbLQM=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZJZKJKKC3DXPWXX2F27ZSR7EVBNHHBVVRQLI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2760/497717983@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2760@github.com>
References: <quicwg/base-drafts/issues/2760@github.com>
Subject: Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf1329fa5043_69be3fb64a6cd96020861a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/uTc3QIChNH-xi3HnVBEIJYhzjKA>
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: Fri, 31 May 2019 13:56:51 -0000

I believe the server p2p case is important and a lot of work has been put into making QUIC symmetric.

Background: Symmetry breaks down naturally in the handshake where one is the initiator, and later in migration where only the client can migrate. The handshake is natural, and migration is simply cost-benefit. There are use cases for server migration in ICE client p2p configuration. For server p2p migration is not important which is probably why it was easily agreed to move that to v2.

Conclusion: symmetry is desirable when feasible, but not at all cost.

So, is the token symmetry worthwhile? In the sense that server p2p is, then maybe. In this configuration peers are expected to be fairly static, so an initial extra roundtrip is probably not that big of a deal when roles reverse. But for v2 it certainly makes sense to include.

There are other case like mesh networking where configuration is much more dynamic and is neither cilent p2p nor server p2p. Here saving a roundtrip could be valuable but it might not matter because when it becomes relevant to use such a token, the configuration might have moved on to new pairs of peers.

-- 
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/issues/2760#issuecomment-497717983