Re: [quicwg/base-drafts] Reserve Long Header Packet Type for QUIC-LB (#1980)

Martin Thomson <notifications@github.com> Mon, 12 November 2018 01:14 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 09DED1271FF for <quic-issues@ietfa.amsl.com>; Sun, 11 Nov 2018 17:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 WBHEV1CHKVja for <quic-issues@ietfa.amsl.com>; Sun, 11 Nov 2018 17:14:00 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5001C126BED for <quic-issues@ietf.org>; Sun, 11 Nov 2018 17:14:00 -0800 (PST)
Date: Sun, 11 Nov 2018 17:13:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1541985237; bh=gS5aRCX7+4XKkQJuvtZM5kUWyiYma0hWBVA48+iynqA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=A2zZJ8lsgeleUnK2W9eW+E9mfkwed3IUFve0IOVMnMlTkvWi2DE4YQfN8QXX70EER GSint1t+/E8pVUEsvbkNLiIBr5IGSFb65sX+ZkFSWoHTUCT8YIIuD7Co0NZdiLyzj5 El9PK7mOo5Lme4b5EUlQ03N2ENloNPVtLlRD/Sl0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab076f4ac0728cd293e312ef1d08314e559af2e64892cf00000001180095d592a169ce168cd044@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1980/437724235@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1980@github.com>
References: <quicwg/base-drafts/issues/1980@github.com>
Subject: Re: [quicwg/base-drafts] Reserve Long Header Packet Type for QUIC-LB (#1980)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5be8d3d577a09_72773f9aa98d45b8485571"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/Amw8hVQNCF_4NlrkN45Q9Pbj0T4>
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: Mon, 12 Nov 2018 01:14:02 -0000

I think that we probably want to have a deeper conversation about this draft.  I look at it and ask why you need to create a bespoke protocol here at all.  If it is going to look like QUIC proper, why not make it be QUIC proper?

But even assuming that you do need that, why are you concerned about making this look like QUIC proper?  I can't see why you would need that for routing purposes, because it seems like you should be back to 5-tuples for routing on this bit.  I can't see why you would concern yourself with ossification on a link that you presumably have considerable influence over.  I can see why you might want to disambiguate this connection from "real" connections, but you could use a separate port, ALPN, or even a new QUIC version if it came to that (though I would advise against a version).

On response to @marten-seemann's comment, which I agree with, you might also like to consider the effect of having 5 types in the long header and what that does for protocol ossification.

-- 
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/1980#issuecomment-437724235