Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)

mirjak <notifications@github.com> Mon, 23 January 2017 20:21 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 BDB50129862 for <quic-issues@ietfa.amsl.com>; Mon, 23 Jan 2017 12:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.156
X-Spam-Level:
X-Spam-Status: No, score=-8.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 kLohn6qTMFbZ for <quic-issues@ietfa.amsl.com>; Mon, 23 Jan 2017 12:21:54 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1865B129872 for <quic-issues@ietf.org>; Mon, 23 Jan 2017 12:21:53 -0800 (PST)
Date: Mon, 23 Jan 2017 12:21:52 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1485202912; bh=qimvVbb8CgT4zbyh0lfSOCT4RbN4YVpuFCX37XaFFpE=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=o4XoyFmWKGANesOD14zABCCz6bM3L3yHGiODDukcRzrLG8N3yPP346nOrGrD9r3Rs nrAO8HCnk1BOamV9fuAoNXzSI8Z4U9wMsEOUc5hyUMoE4UnUaw4R+YY3xGdw8HZMVU J+KcxrkDNOQKaxvllhf49Whn58ruCJDaDwJ32jiw=
From: mirjak <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/203/274605397@github.com>
In-Reply-To: <quicwg/base-drafts/issues/203@github.com>
References: <quicwg/base-drafts/issues/203@github.com>
Subject: Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_588665e0239dd_1713f7fb0e3d1301017cd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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/SgFba2rICCseGvf6rAxS6ICfxn8>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
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: Mon, 23 Jan 2017 20:21:56 -0000

I really don't support this solution because faking something to the network is unnecessary complex and therefore error prone (I think we can only do this wrong because it's fake) and probably also not really feasible given that the sender might not know that anything changed in the network. 

My solution would be the other way around: Don't make the handshake look special and try to make  all packets look the same for the network as much as possible. This goes back to the idea of "don't expose any data that you don't what the network to use because those will be ossified"and I think we should really follow this principle here as much as possible. (As a side note, this also means that there are cases where it is useful to expose information to the network and ossify this information and its representation such that it can be used for e.g.network diagnosability without changing all network devices for each version of quic.)

-- 
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/203#issuecomment-274605397