RE: Multipath (was: Re: Re-chartering for extension work)
<tim.costello@bt.com> Wed, 08 January 2020 11:56 UTC
Return-Path: <tim.costello@bt.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 19D711201CE for <quic@ietfa.amsl.com>; Wed, 8 Jan 2020 03:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=bt.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 0LXtB11rg_2L for <quic@ietfa.amsl.com>; Wed, 8 Jan 2020 03:55:59 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE2812085A for <quic@ietf.org>; Wed, 8 Jan 2020 03:55:58 -0800 (PST)
Received: from tpw09926dag15f.domain1.systemhost.net (10.9.212.23) by RDW083A012ED68.bt.com (10.187.98.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 11:53:49 +0000
Received: from tpw09926dag10g.domain1.systemhost.net (10.9.202.45) by tpw09926dag15f.domain1.systemhost.net (10.9.212.23) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 Jan 2020 11:55:53 +0000
Received: from bwp09926082.bt.com (10.36.82.113) by tpw09926dag10g.domain1.systemhost.net (10.9.202.45) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 8 Jan 2020 11:55:53 +0000
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.55) by smtpe1.intersmtp.com (10.36.82.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 8 Jan 2020 11:55:52 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bC9h6DLoG9L77dqIu3WTK64DDOjRoiJsISmgDf5GQuPE4iVY+F76x6pEncAZHfUPzpJSEWWOnKXag32JCrI5tBKZfOHaBpyg01Tme0THAIw0+CnZEGIyElB2fPagS892tWGRP8bK7QFmwRa87UgQ8a0tPScCxx6mvJRTymrVoyvyRpW1fK5ToDIes242sJOCkivoHESGS8i+tgn9zPmEtWJqj9tumFHzX7SushnmKFPcG0ohJKfT7Oy0huHXkGWw4tPmE7SJUkPDlfdONeX9VCOA+/23higE+DyNBF+xU5HQtNL8bWAoMufrepORATtBlN+W/p1kFKM0qSRNekiQbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yC9Ga/nVEfXj/1mdNNzN9noyH2JS1ul9AtYytJdzi3I=; b=Ao3RufiVsTArtyrrl0j2T8HKBVyWXx5YH1eDfAyAMoUpo8DaeX62km/ZOO1PTWwevM5OGcluK6+QNYo3pEaEPlQKvNIAWxT6ALWYM+mlxAkEh+NI3ybQvCY/VsarHMeiRUuda3Mcm2xhEp8Ar9EmP7m5eipQ5KMg3DHhnFStkIekJ2CCTFL86K4+ffMTOrgudSy1EvcSpTE8GYdNlgXDG9MJD7dLRE6Y3MaridVEARQehA7RFfcp1YUk8W7M8kGwiQLr8X/R6EcoH1SOtamDc6hKNSND7ZJcEp7ZaNJS+rg68k46sXOEWxr1scgw2UfOh6hXJc3U4PZw7Ehe9MRyhQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yC9Ga/nVEfXj/1mdNNzN9noyH2JS1ul9AtYytJdzi3I=; b=tYy9RNINsHYgainL7gQ3Iv6IHnQRVsfxUxoUM2Qc75OaZ/PbdREB+at2Xvt9bwQiBxtuMCAiUlhJFiqQoMsCUJwTO6vKor0GwN8vGncVRUY8VEONjaTDl9WhN/o/KJ8JxJObc0pFUx/fQQGrtd2qxD/Nrr2MvjcV8Y86DnI+2UE=
Received: from LNXP123MB2492.GBRP123.PROD.OUTLOOK.COM (20.179.131.75) by LNXP123MB1865.GBRP123.PROD.OUTLOOK.COM (20.179.131.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Wed, 8 Jan 2020 11:55:52 +0000
Received: from LNXP123MB2492.GBRP123.PROD.OUTLOOK.COM ([fe80::ac93:d0ca:40a8:612c]) by LNXP123MB2492.GBRP123.PROD.OUTLOOK.COM ([fe80::ac93:d0ca:40a8:612c%5]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 11:55:52 +0000
From: tim.costello@bt.com
To: florin.baboescu=40broadcom.com@dmarc.ietf.org, jri.ietf@gmail.com, huitema@huitema.net
CC: olivier.bonaventure@tessares.net, quentin.deconinck@uclouvain.be, lionel.morand@orange.com, mnot@mnot.net, lars@eggert.org, mikkelfj@gmail.com, quic@ietf.org
Subject: RE: Multipath (was: Re: Re-chartering for extension work)
Thread-Topic: Multipath (was: Re: Re-chartering for extension work)
Thread-Index: AQHVs+EhGheNXXTEbUq0lH+f/A0Cxqe8rLQAgAA6W4CAAB3oAIAAHvmAgAAZyoCAAjKXAIAAwJYAgCCZpmA=
Date: Wed, 08 Jan 2020 11:55:52 +0000
Message-ID: <LNXP123MB24923CCECD99AA1C33191459FC3E0@LNXP123MB2492.GBRP123.PROD.OUTLOOK.COM>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <1E872371-F543-4822-8C11-05601913A72E@tessares.net> <752D0B90-8B29-4DBC-9B2F-09E834335598@eggert.org> <49366B32-6425-486C-9453-96D27E2E8EAE@tessares.net> <CAN1APdfNyMBzeWKVRQojo4W_mgxXSSwj4X4EvFC9Pfz4bZ+Pdg@mail.gmail.com> <DF4E42C3-3D90-4C68-989C-6B11833005F9@tessares.net> <CAN1APddWow_QBs+_6GRLyauWFrLVvcr7LA9Mjqdgw-Bcp0d=tQ@mail.gmail.com> <9bc43313-7a06-8b01-75ef-ff1c3925a6cc@huitema.net> <CACpbDccdpKHygp87Be-ytC7juYZmUrfh-3a=4ESLCWMfE-t6Ww@mail.gmail.com> <e561bc9c2b7c9265af9c3f1ba6358c31@mail.gmail.com>
In-Reply-To: <e561bc9c2b7c9265af9c3f1ba6358c31@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.costello@bt.com;
x-originating-ip: [193.113.37.7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d59f36d-e4ef-4e96-a36f-08d79431b645
x-ms-traffictypediagnostic: LNXP123MB1865:
x-microsoft-antispam-prvs: <LNXP123MB186548314FED605D739A9B37FC3E0@LNXP123MB1865.GBRP123.PROD.OUTLOOK.COM>
x-antispam-2: 1
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02760F0D1C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(51444003)(189003)(199004)(2906002)(8676002)(8936002)(33656002)(81156014)(71200400001)(81166006)(9686003)(86362001)(4326008)(7416002)(6506007)(53546011)(54906003)(52536014)(7696005)(26005)(186003)(110136005)(316002)(5660300002)(55016002)(478600001)(66446008)(66556008)(76116006)(66476007)(66946007)(66574012)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1865; H:LNXP123MB2492.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pIkIH/v7RjF0TESGQl2DKr70ffP2FRgbah92pR3PoSDb8jTFU/VXfk8qqQUwDc100i3upnq0N2377Wb1qtl34etfVooXGAAnCzOkpHWNeqerfTn0L49pJyigypC6V014WUPv0e+p8LkXkSfVzSFRekb8NZQqmASd3ZQ88/kmJVIV9PocYpaYsC44+WY6niAIOkc7Vu7dkvO4tXmBFfiRqXwE+T2y488nFYKt7zrn3k1lPBRAGzJZvYZ7wJphQ+qLXYS05UkxU0apnRZBEMv9bP74Wcl9/izxi2tGp7J7/GKEqlSoUSgKsPRKTKtJ8R5wk3gI02jBa3sOBltxctXK+4lMc9PWD24s5S/hxhExyWJl4zcBPGTTe38G2sowuCW+4mGrgSe3lLMAGD9rvlGIz9mB5q9vBm5DMCoIOJuakhJc/3qRCTlhVEk9b1zSoODfdVjBEClxQpCfMEGo++YPbrW43exXrwKI64kmEylA6678GKhYPanSBiOUgLvBJgnq
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LNXP123MB24923CCECD99AA1C33191459FC3E0LNXP123MB2492GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d59f36d-e4ef-4e96-a36f-08d79431b645
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 11:55:52.7290 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kf16nlgu/b6Xno5/OwKs9BnlNhD57lBbpPH6C3PxD+9wIC3Px6eMGXYWZiei8lvcoCdLD5qxnOSIPUYV6hu7jA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1865
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YuCeNUWutVQIu0lUVivsHIYigEg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 Jan 2020 11:56:02 -0000
I am also in support of developing MP-QUIC. 5G network standards are keen to expand beyond MPTCP for multipath connections over cellular and Wifi. QUIC is an obvious candidate for applications that don’t work well over TCP, but we need multipath support for QUIC if the underlying network is to support multipath connections over 5G and WiFi. Regards Tim From: QUIC <quic-bounces@ietf.org> On Behalf Of Florin Baboescu Sent: 18 December 2019 17:55 To: Jana Iyengar <jri.ietf@gmail.com>; Christian Huitema <huitema@huitema.net> Cc: Olivier Bonaventure <olivier.bonaventure@tessares.net>; Quentin De Coninck <quentin.deconinck@uclouvain.be>; lionel.morand@orange.com; Mark Nottingham <mnot@mnot.net>; Lars Eggert <lars@eggert.org>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <quic@ietf.org> Subject: RE: Multipath (was: Re: Re-chartering for extension work) Dear all, I would like to support Olivier’s request that “as QUICv1 is now getting stable, it makes sense for the working group to adopt an initial design for multipath QUIC and then improve it”. While it is easy to agree with Jana’s comment that “There will be quite some heavy lifting to do if we go down the path of designing a multipath extension for QUIC” one can definitely not ignore 1) the experience gained through the MPTCP work as well as 2) the fact that QUIC simplifies the design and makes it more flexible than in the case of MPTCP. With regard to Jana’s comment that “I would also like to see implementations that are keen to build it if an extension were to be developed, and applications that will use it” I would like to point out the followings: 1. In 3GPP Release 16, MPTCP has been adopted as a solution for Access Traffic Steering, Switching and Splitting(ATSSS) support in the 5G System architecture. 2. In 3GPP Release 17 (to be completed by December 2020) a large number of companies would like to be able to complement the solutions adopted in Release 16 with a MPQUIC based solution if available. These companies represent handset vendors, operators and network vendors. This is why it is easy to say that we do see a very strong need and interest in this work and we would like to support it. Thank you. -Florin From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>] On Behalf Of Jana Iyengar Sent: Tuesday, December 17, 2019 10:26 PM To: Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> Cc: Olivier Bonaventure <olivier.bonaventure@tessares.net<mailto:olivier.bonaventure@tessares.net>>; Quentin De Coninck <quentin.deconinck@uclouvain.be<mailto:quentin.deconinck@uclouvain.be>>; Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>; Lars Eggert <lars@eggert.org<mailto:lars@eggert.org>>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>> Subject: Re: Multipath (was: Re: Re-chartering for extension work) I'm not sure that this is the time for this conversation, but I'll share my thoughts since the question has been raised. There will be quite some heavy lifting to do if we go down the path of designing a multipath extension for QUIC. We've seen this before. I worked on multipath for SCTP, which was quite some work. I remember when we started work on MPTCP at the IETF in 2009, and it was a lot more effort than most people anticipated. When we started work on connection migration for QUIC, we thought it might get done relatively quickly, but it was a feature that kept on giving. None of this is to say that we shouldn't take on a hard problem, but before we start sliding into it, I would like to be convinced of its importance. We already have connection migration in the core drafts, and I'd like to see an articulation of the problems that multipath would solve in addition to basic migration. I would also like to see implementations that are keen to build it if an extension were to be developed, and applications that will use it. Without those, we would be putting the cart before the horse. - jana On Mon, Dec 16, 2019 at 12:52 PM Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> wrote: On 12/16/2019 9:20 AM, Mikkel Fahnøe Jørgensen wrote: If you can observe encrypted traffic on both paths you have an opportunity to correlate traffic if an endpoint consistently acks on one path and sends on another. On path has small packets a fixed interval after larger packets on the other paths. That could happen in a migration scenario where one path is not yet fully committed so ACKs stay on the main path. I don’t recall how it works today with single path migration, but I think that it is required that ACKs happen on the same path as the packets on which they are sent. No, that's not required. In fact it cannot be required, because one of the scenarios is "transmit some data on path X, then migrate to path Y". If you don't ack on path Y for packets sent on path X, you end up having to repeat these packets on path Y. But your general point is correct, Mikkel. If application traffic is spread over multiple paths, it is probably hard to hide the correlation between these multiple paths. Not necessarily impossible, but if this is a goal we have better design for it. -- Christian Huitema
- Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Jana Iyengar
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Salz, Rich
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Multipath (was: Re: Re-chartering for extension w… Lars Eggert
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Christian Huitema
- RE: Re-chartering for extension work Mike Bishop
- RE: Re-chartering for extension work Kuhn Nicolas
- Re: Re-chartering for extension work Ian Swett
- Re: [EToSat] Re-chartering for extension work Christian Huitema
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Multipath (was: Re: Re-chartering for extensi… Florin Baboescu
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Multipath (was: Re: Re-chartering for extensi… Ryan Hamilton
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Jana Iyengar
- RE:(2) Multipath (was: Re: Re-chartering for exte… Madhan Raj Kanagarathinam
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Lars Eggert
- RE: Re-chartering for extension work Roni Even (A)
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Kuhn Nicolas
- RE: [EToSat] Re-chartering for extension work Kuhn Nicolas
- Re: Multipath Gorry Fairhurst
- Re: Re-chartering for extension work Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Tommy Pauly
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- RE: Multipath (was: Re: Re-chartering for extensi… tim.costello
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Lucas Pardue
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Tommy Pauly
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Eric Rescorla
- Re: QUIC re-chartering: include DNS-over-QUIC? Ted Hardie
- Re: QUIC re-chartering: include DNS-over-QUIC? Jari Arkko
- Re: QUIC re-chartering: include DNS-over-QUIC? Magnus Westerlund
- Re: QUIC re-chartering: include DNS-over-QUIC? Stephen Farrell
- Re: QUIC re-chartering: include DNS-over-QUIC? Christian Huitema
- Re: QUIC re-chartering: include DNS-over-QUIC? Daniel Migault
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Christopher Wood
- Re: QUIC re-chartering: include DNS-over-QUIC? Ian Swett
- Re: QUIC re-chartering: include DNS-over-QUIC? Vidhi Goel
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Duke
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Mikkel Fahnøe Jørgensen
- Re: QUIC re-chartering: include DNS-over-QUIC? Lucas Pardue
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Thomson
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie