Re: Multipath Milestones

Mikkel Fahnøe Jørgensen <> Fri, 16 February 2018 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16E9C127023 for <>; Fri, 16 Feb 2018 05:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oly_U0f8_l_7 for <>; Fri, 16 Feb 2018 05:30:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E27F120047 for <>; Fri, 16 Feb 2018 05:30:16 -0800 (PST)
Received: by with SMTP id m11so4115196iob.2 for <>; Fri, 16 Feb 2018 05:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+bA5gd8xki+ddvFtAQOmQNOpMgeg3myQoyYMkCd1+z0=; b=XPHK5QDnqr9K5+iOvuQ31oRFIdGzKfkZZMpDGjyJt18dDPyJOPcCS3VKbNTVjoGurm rh6dIl1zTr8C+H5nkIlu3Z5+gPqaykEeLmkuGdgtt+xrfzwRXNQQ+33sdMFVp0z8ldnI Kgp11C29slBUlOd27H1IGCm6+xCKr6ZTSXyl0l3aboY1T1ctcqySWJ/guop6vYa7x2GZ bhBGycTFCmKy1rR33vbu9pGy6JkZYh6oZrBm1vzDxcUJ6QDYdRu30u0qdFBQsRSUImFi IrYD2u2swyY9efJ7/7Bi3P+y+a6aSb3mOniISHMOO3Z8aO+VF3CzfXeB2nFGgaeC82I5 w47g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+bA5gd8xki+ddvFtAQOmQNOpMgeg3myQoyYMkCd1+z0=; b=DCSQKbkWSDgRFdlhJ5Gk4OgYm5hm7qN7vpqjd/mHRwSeWkuJ92qK6Zu/1YmPUSNP3t Cx9rM+DoR6wAir1+k87rKkXpAWQvnr1i7k+2WqmFSwmwP5trQ9emthr9JrRUFCSo2fGH x9y2250dBTYZ9OKXXXlGjwXxMD+KAnCz7QmSFnjCxtRvPLKxFAD1U4bEWhF96clIi2c6 K86Ue87jrXIJe27lJ6oXRPaFXle30rX5qaEtZxKwYxaVGpjnYNy0BTzzVihSLWM0D3dn 2mYQifzdmn1RSKlpZIyn1e6Rgim+zXZ9t0aqnY3d92qy7F+/YMe+qYm13krGHoG+ncR0 7SyA==
X-Gm-Message-State: APf1xPCL+iLaOzwX74loewxABQuJpgLTSPZR4X1hpI/mAB2Bpx1xC9Cl qkfPdlPrFF4UqOxn73t3I5vOE++Ny9lSvqjAskE=
X-Google-Smtp-Source: AH8x227mxvMUtN2nlPTcVa0a9OYWbgN2pSGOwZIYUvzxMhkmEOM3CI/uwFZzqgG+YRvntNAA7dK12C5q645xNWx4ZjE=
X-Received: by with SMTP id y18mr7903477iod.70.1518787815939; Fri, 16 Feb 2018 05:30:15 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 16 Feb 2018 13:30:15 +0000
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 16 Feb 2018 13:30:15 +0000
Message-ID: <>
Subject: Re: Multipath Milestones
To: "Eggert, Lars" <>, Quentin De Coninck <>, Ian Swett <>
Cc: Lucas Pardue <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="001a114043bc422d620565545847"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Feb 2018 13:30:19 -0000

I briefly skimmed the multi path proposal and one thing that comes to mind
is the limit of 256 paths.
I think there could be much more than 256 paths and that path ID’s could be
varint encoded. A single address could have multiple paths over time, key
migration could be tied to paths, although two paths may still share a key.
Path swapping could potentially be used to protect against optimistic ACK
attack. I wrote an issue on segmented packet numbers: here the objective is to
avoid the packet number encryption and to provide simpler per path loss
management, but it overlaps with multi-path. I wonder how much the current
design actually needs to change in order to support multi-path if using
segmented packet numbers. There is already PATH_CHALLENGE.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 16 February 2018 at 14.11.17, Quentin De Coninck ( wrote:


Le 14/02/18 à 20:22, Ian Swett a écrit :

I think the right path forward is for those particularly interested in
multipath to experiment with QUIC extensions inside v1, once the extension
mechanism is defined.  Once some experimentation has happened, we'll be in
a better place to have an informed discussion about some of the points
Christian raised in his multipath requirements draft:

I totally agree that experimenting is key. That's why we implemented the
multipath extensions that we proposed last year in

This document has evolved and we'll release a new version before the London
IETF to take into account various comments received. In parallel with that,
we are finalizing an iOS application that uses multipath QUIC to evaluate
how this works in the wild. This application will perform various
measurements to analyze the benefits of multipath. If you have ideas, feel
free to contact me offline. If there is interest, I might be able to report
some results with multipath QUIC in the wild at the London IETF.