IETF Logo Mail Archive

RE: Invariants draft

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Mon, 04 December 2017 10:06 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 86B40126E7A for <quic@ietfa.amsl.com>; Mon, 4 Dec 2017 02:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Gb4-a5TeCvxu for <quic@ietfa.amsl.com>; Mon, 4 Dec 2017 02:06:51 -0800 (PST)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9832127005 for <quic@ietf.org>; Mon, 4 Dec 2017 02:06:50 -0800 (PST)
Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB4A6esY021394; Mon, 4 Dec 2017 10:06:41 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 10:06:40 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>, Christian Huitema <huitema@huitema.net>
Subject: RE: Invariants draft
Thread-Topic: Invariants draft
Thread-Index: AQHTalo6yBpldn/AqUWlcXfXOwAsJaMt6heAgAAb24CABFncAIAAfEQAgAAbp8A=
Date: Mon, 04 Dec 2017 10:06:39 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAA094E@bgb01xud1012>
References: <CABkgnnVr7jQ2=fFM+OOgk0-=Fseze8fT3xwWBOj-4CWTOtbq1Q@mail.gmail.com> <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> <DB6PR10MB17668967F2AA27987B47F437AC390@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CABkgnnVLa0Tcs6=YDqx5WN8Fw3-Z4m+SowBcvVJaUJqUKkdP6Q@mail.gmail.com> <CAN1APdefT1oLiNnjXSYsR2DqqKnxXn_Oc0fx=w-be+E=DtLvAA@mail.gmail.com>
In-Reply-To: <CAN1APdefT1oLiNnjXSYsR2DqqKnxXn_Oc0fx=w-be+E=DtLvAA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23508.006
x-tm-as-result: No--17.423700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAA094Ebgb01xud1012_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rAX4ildwXExR1-ljEAsBrkm4lzQ>
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: Mon, 04 Dec 2017 10:06:52 -0000

Well, the Transport doc is titled “QUIC: A UDP-Based Multiplexed and Secure Transport” but QUIC isn’t an anagram for Quick UDP Internet Connections anymore right? It’s more of an all-caps identifier like KFC.


From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: 04 December 2017 08:18
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org; Christian Huitema <huitema@huitema.net>
Subject: Re: Invariants draft

> More generally: I find it unfortunate that UDP is made an invariant, anf
> possibly even IP.

That's intentional. For instance, QUIC over DCCP would be something
else entirely and not covered by this promise. The same applies to
layering QUIC directly on top of IP, or any imaginable substrate (like
your embedded device bus example). Nothing we do here would prevent
those things. Though each - as an entirely new thing - would have to
overcome its own challenges.



That is a fair point. For example it might make sense to remove UDP but extend the type field with a routing class identifier for some networks or use cases and such a change could still build on the UDP invariants by stating where it differs. The same could be said about multiplexing. Perhaps my concern is more monopolising QUIC, the name, for UDP. Thus one could say QUIC/UDP invariants. But I also see you have to make some boundaries for a protocol.

v2.23.0 | Report a Bug | By Email