IETF Logo Mail Archive

RE: Call for Adoption: Invariants

Praveen Balasubramanian <pravb@microsoft.com> Tue, 06 February 2018 20:48 UTC

Return-Path: <pravb@microsoft.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE3F12D945 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 12:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 uc6SbTQtyrtc for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 12:48:11 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B9312D940 for <quic@ietf.org>; Tue, 6 Feb 2018 12:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SwDR8zkZDJ8QkaC/GxJsdQPsY8aOh3TEzCzvDM9bo+g=; b=XB/OfLHohoC+NfbEBT8JCzGpAdKmZ8ONMOs+6jy0aXVkhq3iPwYEuSgReEXGwjQpfaDZZimOFwXfqHW4fAJmPrbrPkOG5nB9t+iXZlMh1+s+OkTAiwMR6hLp2zDg+P0xI6DSUsxjobgoUUTUr+JC+VfEsdt+6X8BOh4HSyDsLHM=
Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.485.2; Tue, 6 Feb 2018 20:48:08 +0000
Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Tue, 6 Feb 2018 20:48:08 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Jana Iyengar <jri@google.com>, Mike Bishop <mbishop@evequefou.be>
CC: Ted Hardie <ted.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Lars Eggert <lars@eggert.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>
Subject: RE: Call for Adoption: Invariants
Thread-Topic: Call for Adoption: Invariants
Thread-Index: AQHTnketpPPeU/jidk6aOHbvjAdkY6OVb7kAgAALu4CAAK9GgIABTZeAgABDrICAAAOdgIAABIKAgAAWxJA=
Date: Tue, 06 Feb 2018 20:48:08 +0000
Message-ID: <CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <C35C3AB6-F0FC-4D83-9C97-DD0B605A863F@mnot.net> <DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <FDFA0988-1FB4-4AFC-8958-1A6B16068FE5@trammell.ch> <MWHPR08MB2432F1CB1FBAFACD611D3913DAFE0@MWHPR08MB2432.namprd08.prod.outlook.com> <CAKKJt-cJs8Ms62tBjxGTXBZ6GeD0+VgdWzG7zYf8Yui=a4HPvg@mail.gmail.com> <CA+9kkMChFQ3aYBcsdtFOD18CytjhqYE-pWqd6JCUPuD5vwFE6g@mail.gmail.com> <MWHPR08MB2432E39B469653DB35C02D8EDAFD0@MWHPR08MB2432.namprd08.prod.outlook.com> <CAGD1bZZZ4OHtBpEdZ_XqU6g9sa9xSf2xEOpwpBYzEC61PxzDWg@mail.gmail.com>
In-Reply-To: <CAGD1bZZZ4OHtBpEdZ_XqU6g9sa9xSf2xEOpwpBYzEC61PxzDWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:PZ0Oa51qmok0j7P4u+RcJWVP1FutDO83ODzGEIYZGizkE9YA01wFMYcZY8T4LtgQN23ZJbPKs1bzjBzrnCi1CgVha45Jnq3etyFmX+cVN+AA3KQdrJrcuzpGNK51Gt1kKW3LoOBL9Zlm7m1G0wA73QKCIj/tKqrP6qQUnO9x9obG8+6RziV80A7UXwlVK0LOpvC3ybEaV4KwnAkkG3AahLChEp5PxU+mxv9sPMK1bEX/ApjJs2RI2LCuLZdW8OB0
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ef23515c-fabd-4f50-593e-08d56da2ee11
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0119;
x-ms-traffictypediagnostic: CY4PR21MB0119:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <CY4PR21MB0119A2843E08D6251F15947AB6FD0@CY4PR21MB0119.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(189930954265078)(85827821059158)(100405760836317)(219752817060721)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0119;
x-forefront-prvs: 0575F81B58
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(376002)(396003)(366004)(189003)(51444003)(199004)(74316002)(19609705001)(68736007)(236005)(7696005)(53546011)(8990500004)(7736002)(478600001)(33656002)(3280700002)(14454004)(8936002)(99286004)(10290500003)(8676002)(55016002)(5660300001)(10090500001)(2906002)(97736004)(606006)(81166006)(4326008)(81156014)(110136005)(54906003)(2950100002)(186003)(6436002)(93886005)(106356001)(76176011)(86612001)(22452003)(3660700001)(6116002)(86362001)(229853002)(105586002)(316002)(25786009)(6306002)(9686003)(39060400002)(77096007)(790700001)(54896002)(102836004)(6246003)(2900100001)(53936002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gc+0x4BHoqWuaC3aDagBKq62R2ICnE+WOeENmFwfzp47qR2Gk+2T4J6UgtYMlJEujMsfT3+QqWOce2RAGljTCA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0CY4PR21MB0133namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef23515c-fabd-4f50-593e-08d56da2ee11
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 20:48:08.7445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rHs8AtpqCD9J1P1KyWbKFoENZvU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 20:48:15 -0000

+1 on “The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.”

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Tuesday, February 6, 2018 11:26 AM
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ted Hardie <ted.ietf@gmail.com>; Mark Nottingham <mnot@mnot.net>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Lars Eggert <lars@eggert.org>; Brian Trammell (IETF) <ietf@trammell.ch>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>
Subject: Re: Call for Adoption: Invariants

What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not required for HTTP/QUIC. The HTTP mapping document currently says (in Section 2.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.github.io%2Fbase-drafts%2Fdraft-ietf-quic-http.html%23rfc.section.2.1&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805671598&sdata=%2B0h%2B1meATs8rcF%2F66Tb%2BvxshTFFULLfwqwoHxuy6Cb0%3D&reserved=0>) "Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but let's move that discussion to where it belongs, on #495<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F495&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=ams4Bh5t3rldzh4uok6YJvGlnx8o0R7ELAogQ8iIK54%3D&reserved=0>.

The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.


On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>> wrote:
Two notes, one against interest:  That PR is old and currently parked, because we don’t have consensus and it’s less urgent.  And secondly, UDP/443 is already allocated by IANA for HTTP over UDP.

From: Ted Hardie [mailto:ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>]
Sent: Tuesday, February 6, 2018 10:57 AM
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>
Cc: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; Brian Trammell (IETF) <ietf@trammell.ch<mailto:ietf@trammell.ch>>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>; Lars Eggert <lars@eggert.org<mailto:lars@eggert.org>>
Subject: Re: Call for Adoption: Invariants

On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> wrote:
Asking with no hat, but ...

On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>> wrote:
I support adoption.  The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC.  If it happens to be startlingly similar, all well and good.

If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443?


Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/base-drafts/pull/348<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F348&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=wTDG5fmupXJRRSFroNyBRpcbuwjQzz5fXs%2B41F6DheA%3D&reserved=0>) defines UDP 443 as the default for httpq.  I think that pretty much asserts that UDP/443 is QUIC, not a forked variant.

I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question.


Yes.  That may cause us to consider carefully whether UDP/443 ought to be defined for QUIC more rather than HTTP over QUIC, or even more generally.
Ted


Thanks,

Spencer

v2.23.0 | Report a Bug | By Email