Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

Mikkel Fahnøe Jørgensen <> Tue, 15 December 2020 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0313A3A0EBF for <>; Mon, 14 Dec 2020 16:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.803
X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WFnSHPH8i4WY for <>; Mon, 14 Dec 2020 16:08:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A96DC3A06E7 for <>; Mon, 14 Dec 2020 16:08:18 -0800 (PST)
Received: by with SMTP id w135so17198536ybg.13 for <>; Mon, 14 Dec 2020 16:08:18 -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=dTWlkwfTmMTb+nBsP+yRD5gG1EsGvLfjNdeaA5AydxQ=; b=taq4YnxpHwqCKlihAHtKMHx3hFSuIL3Z4ZEQ45G/jNc1ZWVf/uFfx4P9ZFw1r7tvJd sSq5/Irh7/tYzYrGzvGyeNo1XO48X7n+XCy6Js2NFfRCpFIHuTxbZNGxBbCFoZOMDxnt l6B3ldllf/PyPjLXS88RplWrkdOWQ9x+yAA+t/P+mXx+m1hlEbxx5wiG/+ULjFfodXNY 31StGRWBP0OYoJSR0d8mwzLnF709y2R6j26dNtl8Hvo0DRP7kRkEq3ctAshy5BUlLYMD 16eT55OdzkNrqEILenmA4ItKfO3//iftaqRoHYZonnpr3TpCgoeP5aQjKv+c35zhagWi GkNQ==
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=dTWlkwfTmMTb+nBsP+yRD5gG1EsGvLfjNdeaA5AydxQ=; b=q6fVq3j2qHx0Cbc84oQXbqXVmXIC601+JSXV3FSNTaAEg78eDQ6fQp91/gnC4Jr108 lG5eu4TK338MRH3946HbjwbIQEA0RWMBltdXg9B5gDt6ngnTVvSmYi3XvWQRaz2euGro c+rM2cy2hgiDLL69E+nsL2KVneyyq3TrmS7qVCZ5lkSJtmRvVN66oJSBkILZHiLbAT7A dju4/sOyWR0buuEPVC02VEoOC/+2xUikSdtvkYcNwA5+69MkE48QN4NeuE0zJHbQMdS1 Xfs2yrk7pwTR4AVCOpUbXyNnupV/CJlMLLi8onRO7lf/yENVDGM4SeMK3zCRA6WMUOKi H9zA==
X-Gm-Message-State: AOAM533GKWnZ9ZQwfSyk0JpD57UHfiLga8CbMXxI0j0bYGsZDDJ+t29Z OEBrg4rJvnNnBdUSXwtNOLv6UwREhwEMofZJehA=
X-Google-Smtp-Source: ABdhPJw48qom9t2/6QpZAfYsfw21ZHtYF4i94A6oxlZ4hXYl/h/EHF/8KDYKCRHjcmnPC600W7yFcbCKBafp0LS+c0I=
X-Received: by 2002:a25:9a48:: with SMTP id r8mr35713956ybo.294.1607990897883; Mon, 14 Dec 2020 16:08:17 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 14 Dec 2020 16:08:17 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Date: Mon, 14 Dec 2020 16:08:17 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Yunfei Ma <>
Cc: 李振宇 <>, quic <>, "安勍(莳逸)" <>, Yanmei Liu <>, Christian Huitema <>, "Ma, Yunfei" <>
Content-Type: multipart/alternative; boundary="000000000000453fd905b6758e8c"
Archived-At: <>
X-Mailman-Version: 2.1.29
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: Tue, 15 Dec 2020 00:08:20 -0000

I am indeed working with a STUN WebRTC use case which could benefit from a
QUIC MP replacement of WebRTC. A problem here is that it is often necessary
to use WebRTC over TLS/TURN because of firewall policies. Hopefully a
future QUIC version could both provide multipath and avoid TURN overhead
provided QUIC gains enough traction to slip through firewalls by default.

But in this discussion I’m more thinking about possible server
configurations either server to server or client to server. A server might
implement itself on multiple hardware nodes, for resilience, load
balancing, or locality of reference, or a server might have access to
multiple network cards with different IP addresses.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 15 December 2020 at 00.27.13, Yunfei Ma ( wrote:

Hi Mikkel,

I think this current protocol does not prevent you from doing that as it is
designed as a minimally-scoped extension of QUIC-v1. The goal is to make it
easier for people to try different things with multi-path. As pointed out
by Christian, announcing address/port/QoE does have some complexity. One
way is to let the client server cooperate, but you may also want to use a
STUN server to help you achieve that which is similar to the case of RTC.
We would appreciate it if you could try and let us know your experience.


On Mon, Dec 14, 2020 at 2:56 PM Mikkel Fahnøe Jørgensen <>

> These are good problems to address, but I would rather address them in a
> targeted effort than as part of the multipath design.
> Good point and interesting description on VPN case.
> I think it would be helpful for multipath to still consider this at an
> abstract level such that it can be plugged in at a later point without
> deciding on the exact details up front, if for no other reason than to
> avoid hardcoding things that don’t have to be.